If you're running production workloads on a VPS, your backup strategy is probably broken.
Most people rely on daily cron jobs that rsync files to a remote server, or database dumps uploaded to S3. These approaches work — until they don't. Full recovery from an rsync backup can take hours. Database dumps lose configuration, logs, and application state. And none of them protect against logical corruption that propagates to your backup before you notice the problem.
There's a better way: ZFS snapshots.
At Hostingowy, every VPS runs on ZFS-backed NVMe storage. Our provisioning system creates snapshots by default, and we've built our entire disaster recovery strategy around ZFS's native capabilities. Here's how we use it — and how you can leverage it for your production workloads.
---
Part 1: What ZFS Snapshots Actually Are
A ZFS snapshot is a point-in-time read-only copy of a filesystem. Unlike traditional backups that copy data, ZFS snapshots work at the block level using copy-on-write (CoW) semantics:
- Initial state: ZFS tracks all blocks in the filesystem
- Snapshot taken: ZFS records the current block reference — no data is copied
- Data changes: As blocks are modified, ZFS writes new blocks to new locations; the old blocks remain referenced by the snapshot
- Space used: Only the blocks that changed since the snapshot consume additional space
This means: - Snapshots are instant — they complete in milliseconds regardless of dataset size - Snapshots are space-efficient — a snapshot of a 100GB dataset might consume only a few MB if little has changed - Snapshots have zero performance impact — no I/O during creation - Snapshots are consistent — they capture a precise point-in-time state
Why This Matters for Your VPS
Traditional backup approaches require: - Downtime — or at least a pause in writes - Bandwidth — transferring full data sets - Storage — duplicating data that hasn't changed - Time — hours for full backups of large datasets
ZFS snapshots eliminate all four constraints.
---
Part 2: Our Production VPS Snapshot Strategy
2.1 Snapshot Schedule
We default every VPS to the following snapshot schedule, configurable from the control panel:
| Schedule | Retention | Purpose |
|---|---|---|
| Every 4 hours | 6 snapshots (24 hours) | Granular recovery for recent issues |
| Daily (02:00 UTC) | 7 snapshots (7 days) | Standard rollback window |
| Weekly (Sunday 03:00 UTC) | 4 snapshots (28 days) | Extended recovery window |
| Monthly (1st, 02:00 UTC) | 3 snapshots (90 days) | Compliance and audit trails |
Total storage overhead: Typically 5–15% of dataset size, depending on churn rate.
2.2 Snapshot Naming Convention
vmpool/vms/{vps-id}@auto-{type}-{timestamp}
Examples:
vmpool/vms/a1b2c3@auto-hourly-20260720-0600
vmpool/vms/a1b2c3@auto-daily-20260719
vmpool/vms/a1b2c3@auto-weekly-20260718
vmpool/vms/a1b2c3@auto-monthly-20260601
Manual snapshots (user-initiated) use:
vmpool/vms/a1b2c3@manual-before-upgrade-20260720
2.3 Retention Pruning
We automatically prune snapshots based on retention policy:
#!/bin/bash
Prune ZFS snapshots by retention policy
POOL="vmpool"
Remove hourly snapshots older than 24 hours
zfs list -H -o name -t snapshot -r $POOL | grep 'auto-hourly' | \
while read snap; do
timestamp=$(echo $snap | grep -oP '\d{8}-\d{4}')
if [[ $(date -d "$(echo $timestamp | sed 's/\(....\)\(..\)\(..\)-\(..\)\(..\)/\1-\2-\3 \4:\5/')" +%s) -lt $(date -d '24 hours ago' +%s) ]]; then
zfs destroy "$snap"
fi
done
This runs as a cron job every hour, ensuring we never exceed our retention targets.
---
Part 3: Fast Restores — The Killer Feature
The real power of ZFS snapshots isn't the backup — it's the restore.
Scenario 1: Accidental File Deletion
A developer runs rm -rf /var/www/html on production. With ZFS:
# Find the snapshot taken before the deletion
zfs list -t snapshot -r vmpool/vms/a1b2c3
Roll back to that snapshot
zfs rollback -r vmpool/vms/a1b2c3@auto-hourly-20260720-0600
Restore time: < 1 second, regardless of dataset size.
Scenario 2: Logical Corruption or Ransomware
Your application gets compromised and data is encrypted. With ZFS:
# Clone the pre-corruption snapshot to a new dataset
zfs clone vmpool/vms/a1b2c3@auto-daily-20260719 vmpool/vms/a1b2c3-restore
Mount the clone, extract clean data
mkdir /mnt/restore
mount -t zfs vmpool/vms/a1b2c3-restore /mnt/restore
Copy clean data back
rsync -av /mnt/restore/var/www/ /var/www/
Clean up
umount /mnt/restore
zfs destroy vmpool/vms/a1b2c3-restore
Restore time: Minutes (depends on data volume, not dataset size).
Scenario 3: Full VPS Recovery After Catastrophic Failure
Physical host dies. Your VPS is re-provisioned on a new host:
# On the new host, receive the ZFS send stream
zfs receive -F vmpool/vms/a1b2c3 < /backups/a1b2c3-latest.zfs
Boot the VM
virsh start a1b2c3
Restore time: Limited by network transfer speed of the ZFS send stream. A 50GB dataset with only daily changes typically transfers in 2-5 minutes.
---
Part 4: Zero-Downtime Cloning for Development
One of the most underutilized ZFS features is cloning. A ZFS clone is a writable copy of a snapshot that consumes no additional space initially.
Use Case: Production-Matching Staging Environments
# Create a snapshot of production
zfs snapshot vmpool/vms/a1b2c3@for-staging
Clone it as a writable staging environment
zfs clone vmpool/vms/a1b2c3@for-staging vmpool/vms/staging-a1b2c3
The clone is now a full writable copy of production
Create a VM config pointing to the cloned volume
virsh create staging-a1b2c3-config.xml
Time to create a production-matching staging environment: ~2 seconds.
Use Case: Testing Migrations
Before a major upgrade, snapshot the production VPS and clone it:
zfs snapshot vmpool/vms/a1b2c3@pre-upgrade
zfs clone vmpool/vms/a1b2c3@pre-upgrade vmpool/vms/a1b2c3-test
Run the upgrade on the clone
ssh test-server 'apt upgrade && systemctl restart app'
Test thoroughly. If something breaks, production is untouched.
If the upgrade works, repeat on production with confidence.
---
Part 5: Offsite Backup with ZFS Send/Receive
ZFS snapshots aren't just for local recovery. The zfs send and zfs receive commands enable efficient incremental replication to offsite storage.
Incremental Replication
# Initial full send
zfs send vmpool/vms/a1b2c3@auto-daily-20260701 | \
ssh backup-server 'zfs receive backup-pool/vms/a1b2c3'
Next day: incremental send (only changed blocks)
zfs send -i vmpool/vms/a1b2c3@auto-daily-20260701 \
vmpool/vms/a1b2c3@auto-daily-20260702 | \
ssh backup-server 'zfs receive backup-pool/vms/a1b2c3'
Bandwidth savings: Incremental sends typically transfer only 0.5–5% of the dataset size per day for a production web application.
Offsite Strategy at Hostingowy
| Tier | Target | Frequency | Retention |
|---|---|---|---|
| Local snapshots | Same host | Every 4 hours | 24 hours |
| Local snapshots | Same host | Daily | 7 days |
| Offsite replication | UK data centre (geo-redundant) | Daily | 30 days |
| Offsite archive | Separate UK DC | Weekly | 90 days |
Every Hostingowy VPS includes local snapshots at no additional cost. Offsite replication is available as an add-on for $2/month per VPS.
---
Part 6: ZFS vs Traditional Backup Methods
| Feature | ZFS Snapshots | rsync Backup | Database Dump + File Copy |
|---|---|---|---|
| Backup time | Milliseconds | Hours (large datasets) | Variable |
| Restore time | Seconds | Hours | Hours |
| Space overhead | 5–15% (changes only) | 100% (full copy) | Variable |
| Bandwidth (offsite) | Incremental (0.5–5% daily) | Full transfer each time | Full transfer |
| Crash consistency | ✅ Yes | ❌ Unlikely (files change during copy) | ⚠️ Depends on method |
| Ransomware protection | ✅ Clone and recover | ⚠️ Only if backup system is isolated | ⚠️ Same |
| Dev/Staging cloning | ✅ Instant | ❌ Requires full copy | ❌ Full copy needed |
| Granular file restore | ✅ Mount snapshot | ✅ Direct file access | ⚠️ Requires extraction |
| Automation | ✅ Built-in | ⚠️ Script required | ⚠️ Script required |
---
Part 7: Common Pitfalls and How to Avoid Them
Pitfall 1: Not Monitoring Snapshot Space
ZFS snapshots consume space as data changes. A high-churn database can cause snapshots to balloon.
Solution: Set a reservation and warning thresholds:
zfs set reservation=10G vmpool/vms/a1b2c3
zfs set refreservation=5G vmpool/vms/a1b2c3
Monitor with:
zfs list -o name,used,referenced,usedsnap
Pitfall 2: Holding Snapshots Too Long
Old snapshots prevent ZFS from freeing blocks. If a file is deleted but referenced by a 90-day-old snapshot, the space isn't reclaimed.
Solution: Follow our retention schedule above. Don't keep hourly snapshots for more than 24 hours unless you have a specific compliance requirement.
Pitfall 3: Not Testing Restores
A snapshot you've never restored from is not a backup — it's a hope.
Solution: Monthly automated restore testing. We run a script that: 1. Selects a random snapshot from 7+ days ago 2. Clones it to a test VM 3. Verifies data integrity 4. Reports results 5. Destroys the clone
#!/bin/bash
Monthly restore test (automated)
RANDOM_SNAP=$(zfs list -H -o name -t snapshot -r vmpool/vms | \
grep 'auto-daily' | shuf -n 1)
CLONE_NAME="${RANDOM_SNAP%%@*}-test-$(date +%s)"
zfs clone "$RANDOM_SNAP" "$CLONE_NAME"
Verify data integrity
zfs scrub "$CLONE_NAME"
Report
zpool status vmpool
Destroy
zfs destroy "$CLONE_NAME"
---
Summary: Why We Built on ZFS
ZFS snapshots aren't just a backup tool — they're a fundamental infrastructure primitive that changes how you operate:
- Backups that complete in milliseconds instead of hours
- Restores that take seconds instead of days
- Cloning that enables production-matching staging environments instantly
- Replication that transfers only changed blocks
At Hostingowy, every VPS runs on NVMe-backed ZFS storage with automatic snapshots. It's not an add-on or a premium feature — it's how the platform works.
---
Every Hostingowy VPS includes automatic ZFS snapshots, instant restore, and the ability to clone your environment for staging and testing. Deploy a VPS in under 60 seconds and get ZFS protection from day one.