rsnapshot

What this appliance does and does not do

Read this section before you deploy, so you know exactly what the appliance does.

What rsnapshot is good at. rsnapshot gives you a versioned history of files, so you can roll any of them back to how they were hours, days or weeks ago. It suits configuration under /etc, user home directories, web roots, mail spools and other file trees where you want point-in-time history without the storage cost of many full copies.

What rsnapshot is not. rsnapshot is a file-level backup tool. This image does not include, and rsnapshot itself is not:

• a block-level or bare-metal imaging tool: it snapshots files and directories, not whole disks or live databases mid-write,
• a continuous or real-time replicator: it runs on a schedule, so your recovery point is the last scheduled run,
• a consistent database backup on its own: dump a database to a file first, then let rsnapshot version the dump,
• a web interface or a central console of any kind.

rsnapshot gives you a clean, deduplicated history of files. You decide what to back up. For live databases, pair rsnapshot with an application-aware dump. This guide shows you the mechanics.

What makes this image different

Backups land on a dedicated data volume, not the OS disk. The image attaches a separate data disk, formatted and mounted at /srv/rsnapshot, and points snapshot_root there. Your backup history stays off the operating system disk, on root-only storage, so a full backup volume can never fill the OS disk.

A schedule is already wired. Three systemd timers drive the classic rsnapshot intervals out of the box: alpha every four hours, beta daily and gamma weekly, each rotating the one below it. You get a working backup regime with nothing to configure.

Hard-link deduplication is verifiable. Section 6 runs a second snapshot and shows that an unchanged file shares one inode across two snapshots, so the second copy costs no extra space. A built-in self-test checks the same property automatically.

The image fails closed. Scheduled backups do not run before first boot has finished, and never run if the dedicated volume is not mounted. A snapshot therefore cannot silently land on the wrong disk.

There is no login and no password. rsnapshot has no user database, no daemon and no network port, so there is nothing to rotate and nothing to leak. You administer the machine over SSH with your own key. For the optional task of pulling backups from other hosts, a unique SSH key is generated on this machine at first boot and is never baked into the image.

1. Deploy the virtual machine

Deploy the image from the Azure Marketplace. This guide assumes the following defaults:

• Size: Standard_B2s (2 vCPU, 4 GB) is sufficient and is what this image is validated on. rsnapshot is lightweight, so size the data disk, not the VM, for larger backup sets.
• Data disk: the image provisions a dedicated 64 GB data disk for snapshot_root. Grow or replace it to fit your retained history.
• Inbound ports: SSH (22) only. rsnapshot opens no network port of its own.
• Authentication: your own SSH public key.

2. Connect to the virtual machine

ssh azureuser@<vm-ip>

On first boot, the machine prepares its backup volume and generates its own SSH key for optional remote pulls. This takes only a moment. If you connect immediately, section 9 shows how to confirm that first boot has finished.

3. Confirm rsnapshot is installed and the backup volume is ready

rsnapshot version
sudo rsnapshot -c /etc/rsnapshot.conf configtest mountpoint /srv/rsnapshot && df -h /srv/rsnapshot
sudo test -f /var/lib/sac/data/rsnapshot-firstboot.done && echo "firstboot complete"

You should see the rsnapshot version, the configuration reporting Syntax OK, the dedicated volume mounted at /srv/rsnapshot and the first-boot sentinel present.

4. See what is being backed up and how long it is kept

The appliance ships a working default configuration. It backs up /etc, /home, /root, /var/log and the cron spool to snapshot_root on the dedicated volume. It keeps three rotating intervals.

grep -vE '^\s*#|^\s*$' /etc/rsnapshot.conf

The retain lines set the history you keep: alpha 6 (six four-hourly snapshots, about a day), beta 7 (seven daily snapshots, about a week) and gamma 4 (four weekly snapshots, about a month). Each interval promotes the oldest snapshot of the interval below it, so you can recover a file from any of those points in time. The backup lines list the sources. Add your own the same way.

5. Run a backup now and look at the snapshot

You do not have to wait for the timer. Run the most frequent interval by hand and look at what it produced:

sudo rsnapshot -c /etc/rsnapshot.conf alpha || [ $? -le 2 ]
sudo ls -1 /srv/rsnapshot/snapshots/
sudo find /srv/rsnapshot/snapshots/alpha.0/localhost/etc -maxdepth 1 | sed -n '1,12p'

The first run creates alpha.0, a complete snapshot of the backup sources under snapshot_root/alpha.0/localhost/. rsnapshot mirrors the full source path, so /etc/hosts lands at alpha.0/localhost/etc/hosts.

rsnapshot exits 0 on success. It exits 2 if a live file such as a log changed while it was being copied. This is a benign warning and the snapshot is still valid, which is why the command above tolerates exit 2.

6. Prove the hard link deduplication

A successful backup does not by itself show that history is cheap, so check it. Run a second snapshot. rsnapshot rotates the first to alpha.1 and creates a new alpha.0, hard-linking every file that has not changed. An unchanged file therefore has the same inode in both snapshots, so the second copy uses no extra space.

sudo rsnapshot -c /etc/rsnapshot.conf alpha || [ $? -le 2 ]
sudo ls -1 /srv/rsnapshot/snapshots/ echo "inode of /etc/hostname in each snapshot (identical = hard linked, no extra space):"
sudo stat -c '%i %n' /srv/rsnapshot/snapshots/alpha.0/localhost/etc/hostname /srv/rsnapshot/snapshots/alpha.1/localhost/etc/hostname echo "disk used by ALL snapshots vs a single snapshot (nearly equal = deduplicated):"
sudo du -sh /srv/rsnapshot/snapshots/ ; sudo du -sh /srv/rsnapshot/snapshots/alpha.0/

You should see both snapshots present, the same inode number printed for the unchanged file in alpha.0 and alpha.1, and the total size of all snapshots close to the size of one. This is the core value of rsnapshot: weeks of history for barely more than one copy.

7. Restore a file

To restore, copy a file out of the snapshot for the point in time you want. There is no special restore tool to learn.

sudo cp /srv/rsnapshot/snapshots/alpha.0/localhost/etc/hostname /tmp/restored-hostname cat /tmp/restored-hostname

To restore a whole directory, copy the tree from the snapshot back into place with cp -a. Snapshots are ordinary files on the dedicated volume, so you can also browse them directly or copy them off the machine with rsync or scp.

8. The backup schedule

Three systemd timers drive the intervals. The rsnapshot-alpha timer runs every four hours, beta runs daily and gamma runs weekly, each rotating the interval below it. Check the timers and the log:

systemctl list-timers 'rsnapshot-*' --no-pager sudo tail -n 5 /var/log/rsnapshot.log

To run an interval immediately instead of waiting for its timer, run:

sudo systemctl start rsnapshot-alpha.service

The beta and gamma intervals promote snapshots from the interval below, so let alpha accumulate before you expect beta and gamma to have content. All three timers are Persistent, so a machine that was deallocated over a scheduled window catches up at the next boot.

9. First boot and troubleshooting

First boot prepares the backup volume and generates the per-machine SSH key. To confirm that it finished, run:

systemctl is-enabled rsnapshot-firstboot.service
systemctl is-active rsnapshot-firstboot.service
sudo sed -n '1,12p' /root/rsnapshot-instance.txt

The unit is a one-shot. Once it has prepared the volume and key, it stays active, which is the healthy resting state. The instance note at /root/rsnapshot-instance.txt records that there is no login on this machine and prints the public SSH key for optional remote pulls.

If first boot did not complete, for example because the data disk was not yet attached, re-run it:

# Re-run first boot if it did not complete.
sudo systemctl restart rsnapshot-firstboot.service

Scheduled backups refuse to run until first boot has finished and the dedicated volume is mounted, so a snapshot cannot silently land on the OS disk.

10. Optional: back up other hosts over SSH

rsnapshot can pull backups from other machines over rsync-over-SSH. A unique SSH key was generated on this machine at first boot at /root/.ssh/id_rsnapshot, and its public half is printed in the instance note. Authorize that public key on the host you want to back up. Then add a remote backup line to /etc/rsnapshot.conf. The example below is for illustration and this guide does not run it:

# On the machine to be backed up, authorise this appliance's per-VM public key: # (paste the key from /root/rsnapshot-instance.txt into that host's authorized_keys)
#
# Then add a remote backup point to /etc/rsnapshot.conf (fields are TAB separated): backup root@backup-source:/etc/ backup-source/ +rsync_long_args=-e "ssh -i /root/.ssh/id_rsnapshot"
#
# Validate and run:
sudo rsnapshot -c /etc/rsnapshot.conf configtest
sudo rsnapshot -c /etc/rsnapshot.conf alpha

The key is unique to this virtual machine and is never shipped in the image, so no two deployments share a key.

11. Licensing

rsnapshot is licensed under the GNU General Public License, version 2. It is installed unmodified from Ubuntu's public apt archive, so you can patch it through the normal unattended-upgrades path for the life of the release. The complete corresponding source for the exact binary installed is available from that same archive with apt-get source rsnapshot. A written offer for the source ships on the image at /usr/share/doc/sac/RSNAPSHOT-GPL-2-WRITTEN-OFFER.txt.

Support

Every SecureAnyCloud deployment is backed by 24/7 support. If you have questions about this image, contact us at sales@secureanycloud.com.

Deploy on Azure

Launch rsnapshot on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com