rsnapshot is well suited to keeping directly browsable historical versions on a Linux backup server. It synchronizes data with rsync and reuses unchanged files through hard links.
As a result, daily.0, daily.1, and weekly.0 each look like complete backups, while unchanged files normally consume storage only once. Recovery requires no proprietary database: locate the required snapshot and copy the files.
This article is organized into four categories of sources:
- Linux native directory;
- Remote Linux directory accessed via SSH;
- Windows or Samba share;
- NAS serving files via SMB/CIFS or NFS.
All examples write snapshots to:
|
|
Before you begin, replace the example IP addresses, usernames, share names, and directories with values from your environment.
rsnapshot Features and Essential Commands
How rsnapshot Moves Data
The most common deployment method is to have a Linux machine act as a backup server:
|
|
The backup server reads source data, writes snapshots, runs scheduled jobs, and records logs. For remote Linux systems, rsnapshot actively pulls data over SSH. Windows and NAS shares are usually mounted on Linux first and then backed up as local directories.
rsnapshot is not a real-time synchronization tool, nor is it an off-site backup strategy itself. It can reduce the cost of recovery by accidental deletion, accidental modification, and when historical versions are needed, but it cannot replace offline copies, off-site copies, and recovery drills.
Install the Required Packages
Ubuntu or Debian can install:
|
|
Each package has a specific role:
rsnapshot: manages synchronization and snapshot rotation;rsync: copies changed data;openssh-client: connect to remote Linux;cifs-utils: mounts SMB shares from Windows, Samba, and common NAS systems;nfs-common: mounts NFS exports from a NAS.
Confirm command location:
|
|
The examples in this article use /usr/bin/rsnapshot, /usr/bin/rsync, and /usr/bin/ssh. If your system reports different paths, use the paths it returns.
Verify the Backup Disk First
Create the snapshot root directory:
|
|
The snapshot root should be on a Linux file system that supports hard links, such as ext4 or XFS. Do not put it directly into file systems such as FAT, exFAT, etc. that do not support Unix hard links.
If /mnt/backup is an independent hard disk, also confirm that it is indeed mounted. Otherwise, after the disk mounting fails, the task may write the backup into an empty directory with the same name on the system disk.
You can do a hard link test first:
|
|
Both test files should have the same inode number.
Core Configuration File Structure
The main configuration is usually /etc/rsnapshot.conf:
|
|
The Tab character must be used between configuration items and parameters. The code block display width may differ from the editor, the actual characters should be checked after pasting, and a string of ordinary spaces should not be used instead of Tab.
This set of retention policies represents:
- Save 7 daily snapshots;
- Save 4 weekly snapshots;
- Save 6 monthly snapshots.
In the default mode, the most frequent level, daily, performs the actual rsync transfer and rotates daily snapshots. weekly and monthly primarily promote older snapshots from lower levels. Enabling sync_first 1 changes this behavior, so the schedule shown here no longer applies unchanged.
Essential Commands
Check the configuration syntax:
|
|
Normal results should contain:
|
|
Preview the command without actually backing up:
|
|
To perform a daily sync:
|
|
View snapshot disk usage:
|
|
Use a custom configuration file:
|
|
If the job runs as the unprivileged user test, the checks, SSH keys, and directory permissions must all use that same account:
|
|
Back Up Linux Directories
Back Up Local Directories
Assume that the following directories are backed up:
|
|
Add in /etc/rsnapshot.conf:
|
|
When global rsync_long_args contains --relative, the source’s directory hierarchy is preserved and the result is usually similar to:
|
|
Execute first:
|
|
Carefully check the source path and target path in the dry-run output to confirm that the wrong location is not written before officially executing:
|
|
Back Up Remote Linux Systems over SSH
The hypothetical environment is as follows:
|
|
The remote machine usually does not have to have rsnapshot installed, but it must have an SSH service running and rsync in the remote environment.
First confirm on the remote machine:
|
|
If rsnapshot is run by root’s cron, configure SSH keys for root:
|
|
The last command must enable direct login and cannot require a password or host key confirmation.
If the task is run by user test:
|
|
Configure backup point:
|
|
Then verify in sequence:
|
|
If --relative is used, the data/files layer may be retained in the snapshot. This is not a duplicate backup, but rsync’s relative path behavior.
Control the Remote Directory Layout in Snapshots
If you want the content in /data/files/ to appear directly under remote-linux/, you can use /./ to mark the relative path starting point:
|
|
The backup result will be closer to:
|
|
Path semantics are easily affected by trailing slashes and --relative, so don’t rely solely on expectations. rsnapshot -t daily should be run first, and then rsync dry-run directly if necessary.
Use a Nonstandard SSH Port
When the remote SSH port is 2222, you can write in the global configuration:
|
|
Test manually first:
|
|
If only one server uses a special port, it is recommended to use ~/.ssh/config instead to avoid global ssh_args affecting other backup points:
|
|
The corresponding configuration is:
|
|
Back Up Multiple Linux Hosts
Use separate target names for each source:
|
|
In this way, you can immediately see which machine the data came from during recovery, and can also prevent different sources from writing to the same directory.
Back Up Only Bare .git Repositories at the Source Root
Assume the directory on the NAS is:
|
|
Only keep the directories ending with .git in the root directory and their entire contents:
|
|
Use Tabs for the first three separators, and use normal spaces for the rsync parameters in the fourth column. +rsync_long_args= means appending to global parameters instead of replacing them as a whole.
The order of filter rules cannot be reversed. rsync determines whether to include the object based on the first matching rule, so --include=/*.git/*** must be in front of --exclude=*.
First test rsync directly:
|
|
The .git directory and its contents should appear in the output; website/, test/, or README.txt should not appear.
If the rule is later changed from “Backup All” to “Backup Only .git”, other content in the old snapshot will not disappear from the historical snapshot. For the new daily.0 to clean excluded objects, the impact of --delete-excluded needs to be understood and tested; it may delete data in the target that no longer matches filtering rules and cannot be enabled directly without dry-run verification.
Back Up Remote Windows Shares, NAS, and Samba Directories
Choose Between SMB, NFS, and SSH
You can choose according to source capabilities:
- Windows file sharing: typically uses SMB/CIFS;
- Samba server: usually uses SMB/CIFS, or directly via SSH + rsync;
- NAS such as Synology and QNAP: You can use SMB/CIFS, NFS, or SSH + rsync in a controlled environment;
- Remote Windows with OpenSSH and WSL rsync configured: Pulling via SSH is possible, but deployment and path handling are more complex.
For ordinary Windows shares, the easiest way to maintain is to mount them read-only on Linux first, and then let rsnapshot backup the mount point.
Create an SMB Credentials File
Do not write the password directly in /etc/fstab or in the command history. Create a credentials file readable by root:
|
|
The content is:
|
|
If you do not use the domain, delete the domain line. Confirm permissions again:
|
|
Expected permissions are 600 root:root.
Mount a Windows or Samba Share Manually
Assume the shared address is //192.168.8.100/files:
|
|
Verify mount and read:
|
|
First confirm that the share can be read stably before writing the rsnapshot configuration. If manual mounting fails, rsnapshot will not resolve authentication, protocol, or network issues.
Configure Automatic Mounting at Boot
Add a line to /etc/fstab:
|
|
Do not restart directly when testing:
|
|
Among them:
ro: Mount in read-only mode to reduce the risk of the backup machine accidentally changing the source data;credentials=: Read account password from independent file;vers=3.0: Explicitly try SMB 3.0;_netdev: Mark this as a network-dependent mount;nofail: Does not prevent the system from continuing to start when the mount fails.
nofail only affects startup behavior and does not mean that backup tasks should ignore mount failures. The mount status must still be checked before scheduled backup.
Add the SMB Mount Point to rsnapshot
Configuration:
|
|
Then verify:
|
|
Don’t just check if the directory exists. Even if the SMB mount is down, the local mount point directory may still exist, but be empty.
Mount an NFS Export from a NAS
Assume the NAS exports 192.168.8.200:/volume1/files:
|
|
Corresponding to /etc/fstab example:
|
|
rsnapshot configuration:
|
|
NFS has a different user mapping and permissions model than SMB. Being able to mount does not mean being able to read all files. You should use the account that actually runs rsnapshot to recursively check the directory.
Prevent Empty Snapshots When a Share Goes Offline
The simplest cron protection is to first check all necessary mount points:
|
|
If any mount point does not exist, rsnapshot will not execute.
You can also check for a sentinel file that only exists on the share:
|
|
The sentinel file can detect problems such as “the mount point exists but the wrong share is mounted”. The file should be created by the source administrator and must be readable by the backup account.
Schedule Backups and Rotate Snapshots
Recommended cron Order
Assume the configuration is:
|
|
Editable root’s crontab:
|
|
Write:
|
|
When actually writing to the crontab, do not add a backslash before the asterisk.
The high-level rotation is scheduled before daily synchronization so that monthly and weekly receive snapshots that are about to be phased out from lower levels first. When the 1st of every month happens to be a Sunday, the execution sequence is monthly, weekly, daily.
Use One Lock Across All Retention Levels
When the disk is slow, there are many files, or the network is unstable, a daily may run until the scheduled weekly time. Use flock to prevent overlap:
|
|
-n means to exit immediately if the lock cannot be obtained. This will not start two rsnapshots at the same time, but it must be combined with log monitoring to prevent tasks from being skipped due to lock conflicts in the long term.
If SMB and NFS mounts must be checked before daily, it is recommended to write a wrapper script that is owned by root and cannot be modified by ordinary users, and then called by cron. Don’t stack long compound commands in crontab.
Validate the Setup Before Enabling Scheduled Jobs
Complete in order:
|
|
Also make sure that the root used by cron can connect to each remote Linux without interaction:
|
|
The command should return success directly and should not wait for password or first connection confirmation.
Verify That Hard Links Are Working
After taking two consecutive snapshots, select an unchanged file:
|
|
If the inodes are the same and the hard link count is greater than 1, it means that the two snapshots share the same file data.
Do not use the simple addition of du -sh daily.0 daily.1 to estimate the true additional space. Hard links will make per-directory statistics appear as if each snapshot occupies a full capacity.
Restore Files
Browse historical snapshots before restoring:
|
|
Restore files to a temporary directory:
|
|
Inspect the recovered files before deciding whether to overwrite the production directory. When restoring to a remote server, rsync to a temporary location first and have the administrator or data owner verify permissions, ownership, and contents.
Common Problems and Troubleshooting
configtest Reports an Error or an Invalid Field Count
The most common cause is that Tabs are replaced with spaces. Show invisible characters:
|
|
Tab usually appears as \t. Correct the file and run the check again:
|
|
Also check that the command path actually exists and that snapshot_root is readable and writable.
Permission denied (publickey)
This means that the local account executing the task cannot log in via SSH keys. Test with the same account:
|
|
Check the following items:
- Whether the public key is added to
~/.ssh/authorized_keysof the remote account; - Whether the local private key belongs to the account running rsnapshot;
- Whether the remote
.sshandauthorized_keyspermissions are too wide; - whether cron actually runs as root instead of
test; - Whether the host key has been confirmed by the same account.
SSH Works, but rsync Reports command not found
Confirm the remote path:
|
|
If rsync is installed in a nonstandard location, append the option to that backup point:
|
|
Don’t guess the path, actually confirm it on the remote machine first.
The Remote Directory Is Not Readable
First test with the remote backup account:
|
|
Then bypass rsnapshot and test rsync directly:
|
|
If Permission denied still occurs, the problem is the remote account’s directory traversal or file-read permissions, not rsnapshot. Check them on the remote system:
|
|
Prefer authorization via dedicated read-only accounts, group permissions, or ACLs. Don’t change the entire source directory to be readable and writable by everyone just to save trouble.
The SMB Mount Reports Permission denied
First check the kernel log and mount errors:
|
|
Check the share name, username, domain, credential file permissions, and whether the NAS allows access for the account. Only try other vers= if the server is truly older, don’t consider downgrading to an older protocol as a default solution.
rsnapshot Succeeds, but the Windows or NAS Snapshot Is Empty
Check the source mount immediately:
|
|
If the share is not mounted, stop further rotations, restore the mount, and then run daily. Do not keep running against an empty mount point, or successive snapshots will record an empty source.
rsnapshot -t Looks Correct, but the Real Run Still Fails
-t primarily displays the command that will be executed and does not fully verify permissions, capacity, network stability, and all file names during transfer. Think of dry-run as a first check, not a guarantee of success.
Check the log:
|
|
Copy the rsync command in the log and run it separately to confirm whether it is a network, permission, file name or disk issue.
Disk Usage Grows Unexpectedly
First distinguish between “many file changes” and “hard link failure”:
|
|
A large number of small files will exhaust inodes first; database files, virtual machine images, and large files that continue to change may occupy new complete file space in new snapshots even if only a small part is changed.
Space reuse will also fail if the snapshot root directory is moved to a file system that does not support hard links, or if different snapshots span file systems. Recheck:
|
|
cron Does Not Run
Confirm crontab content:
|
|
cron environment variables are fewer than interactive shells, so absolute command paths should be used in tasks. Do not rely on temporary settings of PATH in the shell, SSH agent, or manual mount status.
If the command works manually but not from cron, compare the execution account, HOME, SSH key, known_hosts file, and mount visibility in both environments.
Jobs Overlap or Run Indefinitely
Check the progress:
|
|
Do not directly delete the lock file without knowing the process stage. Check the log and process status first to confirm that there is no active rsnapshot, and then handle the remaining locks.
If the schedule window is frequently crossed, you should adjust the execution time, reduce the scan scope, fix the slow network, or use a unified flock lock instead of allowing multiple tasks to concurrently read and write the same snapshot root directory.
Why Do Deleted Source Files Still Exist in Older Snapshots?
This is expected. The new daily.0 can reflect a source-side deletion, while the older daily.1 and weekly.0 remain historical versions until their configured retention limits are exceeded.
Don’t manually go into old snapshots and delete files one by one to “sync state”. This defeats the purpose of historical retention and may accidentally delete data entries that are still shared via hard links.
How to Verify That a Backup Is Recoverable
Perform at least one sample restore each month:
- Select a snapshot from daily, weekly or monthly;
- Copy several different types of files to separate temporary directories;
- Check file sizes and checksums, and confirm that the files open correctly;
- Run consistency checks on bare Git repositories;
- Document recovery times and problems found.
Git bare warehouse can be randomly checked:
|
|
Only the scheduled task success log is not enough. The true acceptance criterion is the ability to recover correct, usable data from a specified historical point.
A Practical Combined Configuration
The following example simultaneously backs up the local machine, remote Linux, Git bare repository, Windows share and NAS NFS. Please confirm that the columns in the code block are Tab:
|
|
The online order should be fixed as:
|
|
Confirm item by item:
- The snapshot root directory is located on the correct backup disk;
- SMB and NFS share real mounts and are readable;
- SSH connections require no interaction;
- dry-run has no unexpected sources or targets;
.gitfilter results include only expected directories;- All key files can be found in
daily.0; - Use hard links for unchanged files in the second snapshot;
- The recovery test was able to successfully open the file.
Finally enable cron. This way when a problem occurs, you can clearly distinguish between configuration syntax, SSH, share mounts, source permissions, disk capacity, and timing environment, without attributing all errors to rsnapshot.