If the goal is “simple, reliable, historical files can be opened directly”, it is very suitable for Ubuntu to actively pull the Synology shared folder, and then use rsnapshot to make a local snapshot. Synology only provides read-only data, and Ubuntu is responsible for timing, logs, version rotation, and hard disk backup. After Synology accidentally deletes a file, it can also directly copy it back from the directory of yesterday, last week, or last month.
rsnapshot works based on rsync and hard links. Each snapshot directory looks like a complete copy of the file, but unchanged files do not occupy disk space over and over again. Photos, videos, PDFs, DOCX, etc. are still ordinary files and do not rely on specialized recovery software or backup databases.
Recommended architecture
|
|
This is not a “Synology pushes files to Ubuntu” solution. Ubuntu has read-only access to Synology, and Synology does not need to save the write password of the Ubuntu backup disk. This permission isolation is usually more secure: when Synology is misused, affected by ransomware, or a package account is abused, the attack surface does not directly extend to Ubuntu’s historical snapshots. This judgment is based on permission isolation, rather than replacing offline disks, off-site copies, or recovery drills.
Applicable scope and boundaries
This method is especially suitable for:
- common shared folders such as photos, videos, documents, project materials, etc.;
- want to retain multiple time points, but do not want to learn special recovery tools;
- There is already a dedicated backup hard drive on Ubuntu;
- I just want to select a few shared folders, not the entire machine image.
It primarily backs up the files themselves and is not equivalent to a complete restore of the DSM, suite configuration, database service status, or all system-level metadata. When full disaster recovery is required, Hyper Backup, application export, database backup, or other targeted solutions should still be retained.
Create a read-only backup account on Synology side
First create a dedicated account in DSM, such as backup-reader:
- Only grant read permission to the shared folder that needs to be backed up;
- Do not grant administrative permissions, write permissions and unnecessary application permissions;
- Use independent strong passwords;
- Only allow Ubuntu’s fixed IP to access related SMB/NFS services.
Do not directly reuse the daily administrator account. In this way, even if the credentials used for mounting on Ubuntu are leaked, the impact will be limited to directories that are authorized to be read.
Ubuntu Mount Synology shared folder
It is recommended to mount each shared folder to a fixed directory:
|
|
Both SMB and NFS are acceptable. Just choose a protocol that you have enabled in Synology and are familiar with. For ordinary home or small team networks, SMB is easier to check permissions, while NFS is closer to the Linux permission model.
SMB/CIFS read-only mount example
First install the tool and create a credential file that only allows root to read:
|
|
Credential file content:
|
|
Added example in /etc/fstab. Replace Synology IP and share name with actual values:
|
|
Test the mount and confirm that the directory is readable:
|
|
ro is the key option. If mount -a reports that the authentication, protocol version or share does not exist, do not configure rsnapshot first; read through the single mount point first.
NFS read-only mount example
If NFS has been enabled in DSM and the shared folder has allowed the Ubuntu IP to be mounted read-only, you can use:
|
|
The NFS export path varies depending on the Synology share name and volume. First confirm on the shared folder NFS permissions page of DSM. After confirming that it is readable, write the actual export path to /etc/fstab.
Prepare Ubuntu backup hard drive
The snapshot root directory should be located on Ubuntu’s dedicated backup disk, for example:
|
|
gives priority to Linux file systems such as ext4 and XFS. rsnapshot relies on hard links to save space, so do not place the snapshot root directory on file systems that do not support Unix hard links, such as FAT or exFAT; nor let the backup directory be split across different file systems.
It is recommended to first confirm that the mounting of the backup hard disk is stable: after the system restarts, /srv/backup/rsnapshot must still be located on the backup disk and not accidentally fall into the empty directory of the Ubuntu system disk.
configure rsnapshot
Edit /etc/rsnapshot.conf. The “configuration items” and “parameters” of this configuration file are usually required to be separated by Tab. If the verification fails after copying, first check whether they have been replaced by spaces by the editor.
The following is the core configuration corresponding to the directory structure of this article:
|
|
has the following meaning:
| Configuration | Function |
|---|---|
snapshot_root |
Root directory where all snapshots are saved |
retain daily 7 |
Keep 7 daily snapshots |
retain weekly 4 |
Keep 4 weekly snapshots |
retain monthly 12 |
Keep snapshots for 12 months |
backup |
Back up the read-only mount directory to the corresponding subdirectory in the snapshot |
Verify the configuration first, and then manually run a daily snapshot:
|
|
After normal completion, the directory is roughly as follows:
|
|
daily.0 This is the latest successful snapshot. After the next run, old snapshots are rotated backwards, and versions exceeding the retain number will be cleaned up.
Set daily, weekly, and monthly scheduled tasks
After confirming that the manual snapshot is normal, create /etc/cron.d/rsnapshot:
|
|
The sample content of is as follows:
|
|
It is recommended to place the task in a period when Synology is relatively idle. The first backup will copy all files, which takes the most time and disk usage; subsequent runs mainly transfer the changed parts.
Before running scheduled tasks, make sure the mounting is successful. You can add a simple check before rsnapshot, or implement it through systemd mounting dependency; the most important thing is not to mistake the empty directory as the source directory when /mnt/synology/* is not mounted, resulting in a “successful but empty content” snapshot.
How to confirm that hard links really save space
Don’t just look at the logical size displayed for each directory. You can check the inode and link count for the same unchanged file:
|
|
If the file has not changed, you will usually see the same inode and the link count is greater than 1. To check the actual usage of the backup disk, use:
|
|
Method to restore files
The rsnapshot command is not required for recovery. Locate the appropriate date directory and copy the target file directly:
|
|
Before restoring to Synology, it is recommended to copy to a temporary directory or change the file name to confirm the content to avoid overwriting the new version that is still in use. To restore the entire folder, you should also confirm the target space and coverage first.
FAQ
rsnapshot is displayed successfully, but the snapshot directory is empty
First check whether the source mount point is really mounted:
|
|
The mere existence of the /mnt/synology/photo directory does not mean that the network share is mounted. The scheduled task should be stopped, delete this invalid snapshot, repair SMB/NFS connectivity first, and then run again.
Configuration check prompts syntax error
Run:
|
|
Key check snapshot_root Whether it ends with /, whether the backup rule has a source path and target subdirectory, and whether Tabs are used between configuration items. Don’t join cron directly without passing configtest.
The snapshot usage is suddenly very large
First check whether a large number of files have been renamed, moved, recoded or modified with time/permissions causing rsync to re-copy. Hard links can only reuse historical files whose content and attributes have not changed; when backing up for the first time, organizing photo libraries in batches, or applying export directories with frequent changes, it is normal for the usage to increase.
Is it possible to directly back up the entire Synology
It is technically possible to mount more shared folders, but it is not recommended to add the system directory, package internal directory and all volumes indiscriminately. Prioritize starting with user data such as photos, documents, and work files, and then gradually expand after confirming the recovery process; database and application configurations should be processed separately according to their respective export or backup mechanisms.
Summary
The process of Ubuntu actively pulling + rsnapshot is very clear: Synology provides a read-only share, Ubuntu mounts it to /mnt/synology/, and rsnapshot is written to the dedicated backup disk. daily, weekly, monthly snapshots. Historical versions are ordinary files that can be browsed directly, and recovery means copying the files; at the same time, Synology does not need to have write permissions on the Ubuntu backup disk. This is a practical solution for long-term storage of photos, documents and work files.