VPS Snapshots and Disaster Recovery Strategies

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–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:

lsblk -f

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]

Or this:

vda
 └─vda1 LVM2_member
   ├─vg0-root ext4 /
   └─vg0-swap swap [SWAP]

Then, check for the LVM with the commands below:

vgs
lvs -a -o +devices

In your output, you should see something similar to this:

  VG         #PV #LV #SN Attr   VSize   VFree
  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–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:

lvs -a

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:

# Compare current and snapshot version
diff -u /etc/nginx/nginx.conf "${MOUNT_POINT}/etc/nginx/nginx.conf" || true

# Restore from snapshot
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:

umount "${MOUNT_POINT}"

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:

reboot

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:

lvs -a

Build an Automated VPS Snapshot to Remote Backup Script

At this point, you can easily combine all the previous concepts into a single and 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 "" backup
mkdir -p /data/backups/vps1
chown -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 ba****@************le.com

Test the user with the command below, and you should see OK:

ssh -i /root/.ssh/vps_backup_key ba****@************le.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:

#!/usr/bin/env bash
set -euo pipefail

# LVM settings
VG_NAME="ubuntu-vg"          # change to your VG name
LV_NAME="ubuntu-lv"          # change to your root LV name
SNAP_SIZE="5G"               # snapshot LV size

# Local mount
MOUNT_BASE="/mnt/lvm_snaps"

# Remote backup server
REMOTE_USER="backup"
REMOTE_HOST="backup.example.com"
REMOTE_DIR="/data/backups/vps1"
SSH_KEY="/root/.ssh/vps_backup_key"
RETENTION_DAYS=7             # keep remote backups for 7 days

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}"

# Optional: briefly stop or flush critical services (database etc.)
# systemctl stop mysql

# 1. Create snapshot
echo "[*] Creating snapshot LV ${SNAP_NAME} ..."
lvcreate -L "${SNAP_SIZE}" -s -n "${SNAP_NAME}" "/dev/${VG_NAME}/${LV_NAME}"

# 2. Mount snapshot read only
mkdir -p "${MOUNT_POINT}"
mount -o ro "${SNAP_DEV}" "${MOUNT_POINT}"

# Optional: start services again if you stopped them earlier
# systemctl start mysql

# 3. Rsync snapshot to remote backup server
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}/"

# 4. Unmount and remove snapshot
echo "[*] Cleaning up local snapshot ..."
umount "${MOUNT_POINT}"
lvremove -f "${SNAP_DEV}"
rmdir "${MOUNT_POINT}" || true

# 5. Remove old backups on remote side
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/vps1
ls -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:

crontab -e

For example, add the following script:

# Snapshot + remote backup every 6 hours
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 ba****@************le.com 'ls -1 /data/backups/vps1'

Restore the file with the command below:

LATEST="20251114-1630"   # replace with real directory
scp -i /root/.ssh/vps_backup_key \
  ba****@************le.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, 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/newroot
mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt/newroot   # example

rsync -aHAX --numeric-ids \
  ba****@************le.com:/data/backups/vps1/${LATEST}/ /mnt/newroot/

• Reinstall the bootloader if needed with the following commands:

mount --bind /dev /mnt/newroot/dev
mount --bind /proc /mnt/newroot/proc
mount --bind /sys /mnt/newroot/sys

chroot /mnt/newroot bash
grub-install /dev/sda        # adjust disk
update-grub
exit

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.

FAQs

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