rsnapshot on Ubuntu 24.04 LTS on Azure

This image ships rsnapshot on Ubuntu 24.04 LTS, ready to take scheduled, versioned backups from the first boot of every deployed virtual machine. rsnapshot is installed unmodified from Ubuntu's own archive, so it stays patchable through the normal apt path for the life of the release.

rsnapshot is an open source filesystem snapshot and backup utility built on rsync and hard links. It keeps rotating snapshots of the paths it is told to watch, and because files that have not changed between one snapshot and the next are hard linked rather than copied again, keeping a long history of backups costs little more than one full copy plus the changes. Restoring a file is a plain copy out of the snapshot for the point in time you want.

What this appliance does and does not do

Read this section before you deploy. It is the difference between an appliance that does what you think it does and one that quietly does not.

What rsnapshot is good at. rsnapshot answers one question well: give me a versioned history of these files so I can roll any of them back to how they were hours, days or weeks ago. It is ideal for backing up 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 keeping 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. Deciding what to back up, and pairing it with an application aware dump for live databases, is your design choice, and 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 is kept off the operating system disk, on root only storage, so filling the 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 real and you can prove it. 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 proves the same property automatically.

The image fails closed. The scheduled backups will not run before first boot has finished, and never if the dedicated volume is not mounted, so a snapshot can never silently land on the wrong disk.

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

1. Deploy the virtual machine

Deploy the image from the Azure Marketplace. The defaults in this guide assume:

• Size: Standard_B2s (2 vCPU, 4 GB) is sufficient and is what this image is validated on. rsnapshot is lightweight; 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 size 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. That takes only a moment. If you connect immediately, section 9 shows how to confirm 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/cloudimg/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 sane default configuration. It backs up /etc, /home, /root, /var/log and the cron spool to snapshot_root on the dedicated volume, and 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 a file is recoverable 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, or 2 if a live file such as a log changed while it was being copied — that is a benign warning, the snapshot is still valid, which is why the command above tolerates exit 2.

6. Prove the hard link deduplication

Do not take "it made a backup" as proof that history is cheap. Prove 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. That is rsnapshot's whole value: weeks of history for barely more than one copy.

7. Restore a file

Restoring is just copying 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. Because snapshots are ordinary files on the dedicated volume, 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. rsnapshot-alpha runs every four hours, beta daily and gamma weekly, each rotating the interval below it.

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

To run an interval immediately rather than waiting for its timer:

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 next boot.

9. First boot and troubleshooting

First boot prepares the backup volume and generates the per machine SSH key. To confirm it:

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

The scheduled backups refuse to run until first boot has finished and the dedicated volume is mounted, so a snapshot can never 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; its public half is printed in the instance note. Authorise that public key on the host you want to back up, then add a remote backup line to /etc/rsnapshot.conf. This is illustrative and is not run by this guide:

# 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

Because the key is unique to this virtual machine and never shipped in the image, 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 it remains patchable 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, and a written offer for the source is shipped on the image at /usr/share/doc/cloudimg/RSNAPSHOT-GPL-2-WRITTEN-OFFER.txt.

Support

Every cloudimg deployment is backed by 24/7 support. If you have any questions about this image, contact us at support@cloudimg.co.uk.