VPS Snapshots for Disaster Recovery means using snapshots, which are instant copies of your Virtual Private Server, to protect your website or application in the event of an issue.
A snapshot is like taking a quick photo of your entire server at a specific moment, and if the server crashes, gets hacked, or breaks because of a bad update, you can restore the snapshot. This brings your server back to the exact state it was in when the snapshot was taken, so you can recover quickly.
In simple words, it is a safety backup system for your VPS that helps you recover fast after a disaster by restoring a saved copy of your server.
Whether you’re managing your VPS through PerLod Hosting or any other provider, creating a powerful backup and recovery strategy is essential. This guide will show you how to create a robust snapshot-based backup plan, roll back changes quickly, back up to a remote server, restore files or the entire system, and automate the process with cron.
Prerequisites: VPS Snapshots for Disaster Recovery
To set up VPS Snapshots for Disaster Recovery, you need root SSH access to your VPS, which should be running Ubuntu or Debian with an LVM-based root filesystem.
Also, you need a remote backup server, like another VPS or storage box with SSH access.
Note: Before running any commands, decide on two things:
- RPO (Recovery Point Objective): How much data can you afford to lose? For example, if you take snapshots every 6 hours, you might lose up to 6 hours of changes.
- RTO (Recovery Time Objective): How quickly you need to recover. LVM snapshot rollback is very fast, while a full restore from a remote backup depends on your data size and network speed.
A common VPS backup plan is:
- Keep 2 to 3 local LVM snapshots for quick rollback.
- Use rsync to make remote backups daily or every 12 hours for disaster recovery.
Check VPS Storage for Snapshot Preparation
The first step is to inspect your VPS's storage layout to confirm it uses LVM and identify the specific names of your storage volumes.
Check the block devices in your VPS with the command below:
You must look for something similar to this:
sda ├─sda1 ext4 /boot └─sda2 LVM2_member ├─ubuntu-vg-ubuntu-lv ext4 / └─ubuntu-vg-swap_1 swap [SWAP]
vda └─vda1 LVM2_member ├─vg0-root ext4 / └─vg0-swap swap [SWAP]
Then, check for the LVM with the commands below:
In your output, you should see something similar to this:
VG ubuntu-vg 1 2 0 wz--n- <80.00g 10.00g LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices ubuntu-lv ubuntu-vg -wi-ao---- 70.00g /dev/sda2(0) swap_1 ubuntu-vg -wi-ao---- <4.00g /dev/sda2(17920)
Key things to know:
- VG name: Your volume group name, such as ubuntu-vg or vg0.
- Root LV name: Your root logical volume, such as ubuntu-lv or root.
- Free space (VFree): You need enough free space in the volume group to create snapshots, usually 5 to 20 GB.
Write down the following metrics:
- VG_NAME: Your volume group.
- LV_NAME: Your root logical volume.
Plan Your VPS Snapshot Strategy
Now that you understand your storage layout, it's time to plan the snapshot's size and behavior. Unlike a simple copy, an LVM snapshot uses a clever copy-on-write mechanism that requires careful sizing. You must choose an appropriate size to ensure it remains valid throughout your maintenance window.
For light to moderate changes on a web server, 5 to 10 GB is often enough. We will use 5G, which you can adjust, and name it root_snap_YYYYMMDD-HHMM.
Create and Mount VPS LVM Snapshot
At this point, you can create the snapshot using the names and size you've prepared.
To create the snapshot, you can use the command below with your own names:
DATE_TAG="$(date +%Y%m%d-%H%M)"VG_NAME="ubuntu-vg"LV_NAME="ubuntu-lv"SNAP_NAME="${LV_NAME}_snap_${DATE_TAG}" lvcreate -L 5G -s -n "${SNAP_NAME}" "/dev/${VG_NAME}/${LV_NAME}"
Then, verify it with the command below:
In your output, you should see something like this:
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ubuntu-lv ubuntu-vg -wi-ao---- 70.00g ubuntu-lv_snap_20251114-1605 ubuntu-vg Swi-a-s--- 5.00g ubuntu-lv 0.01
The Swi-a-s indicates a snapshot.
Next, you need to mount it as a read-only filesystem to prove it works and to provide a way to access the backed-up data if needed. To do this, you can run the commands below:
MOUNT_POINT="/mnt/${SNAP_NAME}"mkdir -p "${MOUNT_POINT}" mount -o ro "/dev/${VG_NAME}/${SNAP_NAME}" "${MOUNT_POINT}"
To verify it, run the following command:
df -h | grep "${SNAP_NAME}"
You must see a consistent copy of your root filesystem at the moment the snapshot was created.
Testing Recovery from VPS Snapshot: File-Level and Full System Rollback
In this step, you can use the snapshot to fix problems, including how to copy a single file back from the snapshot and, if needed, how to revert the entire system to its snapshot state, which requires a reboot.
For example, to restore a single file like /etc/nginx/nginx.conf, you can use the following commands:
diff -u /etc/nginx/nginx.conf "${MOUNT_POINT}/etc/nginx/nginx.conf" || true cp "${MOUNT_POINT}/etc/nginx/nginx.conf" /etc/nginx/nginx.conf systemctl restart nginx
This is a fast file-level recovery.
If you made big changes and want to revert the system to exactly the snapshot state, you must know that all changes made after the snapshot will be lost.
You do not need the snapshot mounted. If it is mounted, unmount it with the command below:
Merge the snapshot back into the origin by using the command below:
lvconvert --merge "/dev/${VG_NAME}/${SNAP_NAME}"
For a root filesystem, LVM usually schedules the merge for the next activation of the LV, which happens at the next boot. Reboot your system with the command below:
After reboot, the root filesystem will be exactly as it was at snapshot time.
Clean Up and Remove VPS Snapshot
After testing and recovery, it is important to clean up the snapshot, which frees up the space and prevents any performance overload.
Make sure the snapshot is unmounted with the command below:
umount "/mnt/${SNAP_NAME}" 2>/dev/null || true
Use the command below to remove the LV:
lvremove "/dev/${VG_NAME}/${SNAP_NAME}"
Confirm it is removed with the following command:
Build an Automated VPS Snapshot to Remote Backup Script
At this point, you can easily combine all the previous concepts into a single automated script. You can create a powerful script that integrates LVM snapshots with rsync over SSH and stores it securely on a separate backup server.
First, prepare a backup user on your backup server with the commands below:
adduser --disabled-password --gecos "" backupmkdir -p /data/backups/vps1chown -R backup:backup /data/backups
On your VPS, generate an SSH key and copy it with the commands below:
ssh-keygen -t ed25519 -f /root/.ssh/vps_backup_key -N ""ssh-copy-id -i /root/.ssh/vps_backup_key.pub backup@backup.example.com
Test the user with the command below, and you should see OK:
ssh -i /root/.ssh/vps_backup_key backup@backup.example.com 'echo ok'
Then, create the backup file with the command below:
nano /usr/local/sbin/vps_snapshot_backup.sh
Add the following script to the file:
set -euo pipefail VG_NAME="ubuntu-vg" LV_NAME="ubuntu-lv" SNAP_SIZE="5G" MOUNT_BASE="/mnt/lvm_snaps" REMOTE_USER="backup"REMOTE_HOST="backup.example.com"REMOTE_DIR="/data/backups/vps1"SSH_KEY="/root/.ssh/vps_backup_key"RETENTION_DAYS=7 DATE_TAG="$(date +%Y%m%d-%H%M)"SNAP_NAME="${LV_NAME}_snap_${DATE_TAG}"SNAP_DEV="/dev/${VG_NAME}/${SNAP_NAME}"MOUNT_POINT="${MOUNT_BASE}/${SNAP_NAME}" echo "[*] $(date) - Starting snapshot backup: ${SNAP_NAME}" echo "[*] Creating snapshot LV ${SNAP_NAME} ..."lvcreate -L "${SNAP_SIZE}" -s -n "${SNAP_NAME}" "/dev/${VG_NAME}/${LV_NAME}" mkdir -p "${MOUNT_POINT}"mount -o ro "${SNAP_DEV}" "${MOUNT_POINT}" echo "[*] Syncing data to remote backup server ..."rsync -aHAX --numeric-ids --delete \ --exclude="/proc/*" \ --exclude="/sys/*" \ --exclude="/dev/*" \ --exclude="/run/*" \ --exclude="/tmp/*" \ --exclude="/mnt/*" \ -e "ssh -i ${SSH_KEY}" \ "${MOUNT_POINT}/" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/${DATE_TAG}/" echo "[*] Cleaning up local snapshot ..."umount "${MOUNT_POINT}"lvremove -f "${SNAP_DEV}"rmdir "${MOUNT_POINT}" || true echo "[*] Removing remote backups older than ${RETENTION_DAYS} days ..."ssh -i "${SSH_KEY}" "${REMOTE_USER}@${REMOTE_HOST}" \ "find '${REMOTE_DIR}' -maxdepth 1 -mindepth 1 -type d -mtime +${RETENTION_DAYS} -print -exec rm -rf {} +" echo "[*] $(date) - Snapshot backup completed successfully."
Once you are done, make the file executable with the following command:
chmod +x /usr/local/sbin/vps_snapshot_backup.sh
You can test your script manually with the following command:
/usr/local/sbin/vps_snapshot_backup.sh
Watch the output, and from the backup server run the command below:
ls -1 /data/backups/vps1ls -lh /data/backups/vps1/
You must see a directory such as 20251114-1630 with a full copy of your filesystem.
Implement Scheduled Backups with Cron
This final step is to set up a cron job to run your backup script automatically. You can add the backup script to the root user's crontab, enabling it to run every 6 hours, or on a schedule of your choice, and log its output for later review.
Edit root’s crontab with the command below:
For example, add the following script:
0 */6 * * * /usr/local/sbin/vps_snapshot_backup.sh >> /var/log/vps_snapshot_backup.log 2>&1
After it runs, you can check for logs with the command below:
tail -n 50 /var/log/vps_snapshot_backup.log
How to Restore From VPS Snapshots?
In this step, you will learn how to use your backups and snapshots to recover your system with three common scenarios, including getting back a single deleted file, undoing all changes on a broken system, and rebuilding your VPS from scratch using the remote backup.
Scenario A: Small issue. For example, you deleted /var/www/html/config.php accidentally.
Find the latest backup directory on the remote server with the command below:
ssh -i /root/.ssh/vps_backup_key backup@backup.example.com 'ls -1 /data/backups/vps1'
Restore the file with the command below:
LATEST="20251114-1630" scp -i /root/.ssh/vps_backup_key \ backup@backup.example.com:/data/backups/vps1/${LATEST}/var/www/html/config.php \ /var/www/html/config.php
Adjust permissions if needed and reload the service.
Scenario B: System broken, but disk is fine. If you know you broke the system after the last snapshot, for example, by misconfigured packages:
If it is possible, stop the essential services and merge the last snapshot into the root with the commands below:
VG_NAME="ubuntu-vg"LAST_SNAP="$(lvs --noheadings -o lv_name | awk '/ubuntu-lv_snap_/ {print $1}' | sort | tail -n1)" lvconvert --merge "/dev/${VG_NAME}/${LAST_SNAP}" reboot
After reboot, you are exactly at snapshot time.
Scenario C: VPS disk destroyed or reinstalled. If the VPS is lost but you still have remote backups:
- Create a new VPS with a similar size and OS.
- Partition and create LVM similar to the original, or use a simple filesystem if you want.
- Boot into rescue or normal mode and mount the new root under /mnt/newroot.
- From the new VPS, pull the backup from the remote with the commands below:
LATEST="20251114-1630"mkdir -p /mnt/newrootmount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt/newroot rsync -aHAX --numeric-ids \ backup@backup.example.com:/data/backups/vps1/${LATEST}/ /mnt/newroot/
- Reinstall the bootloader if needed with the following commands:
mount --bind /dev /mnt/newroot/devmount --bind /proc /mnt/newroot/procmount --bind /sys /mnt/newroot/sys chroot /mnt/newroot bashgrub-install /dev/sda update-grubexit umount /mnt/newroot/{dev,proc,sys}reboot
Now you boot into the restored system.
That's it, you are done with setting up VPS Snapshots for Disaster Recovery.
Conclusion
Creating VPS Snapshots for Disaster Recovery is one of the most important steps in securing your server and ensuring service continuity. By combining LVM snapshots for instant rollback with remote rsync backups for disaster recovery, you achieve a strategy that protects you from configuration errors, software updates gone wrong, accidental file deletions, and even complete server loss.
If you need a VPS provider that supports flexible configurations and strong data protection, feel free to explore our VPS hosting solutions.
We hope you enjoy this guide. Subscribe to our X and Facebook channels to get the latest updates and articles on VPS hosting.
For further reading:
Set up an Isolated Multi-User VPS Architecture for Agencies
Automate WordPress Deployments with Git
Set up the Auto Scaling Script in Dedicated Servers
