How do you back up two NAS devices in different locations? Old Synology moved to my mom's house, and the entire Rsync timed sync process was running smoothly

last year when I wrote about ransomware, my backup setup was like this: Feiniu was the main user, an old Synology DS220j plugged into the same socket, and rsync pulled in one direction. After writing, I still had a knot in my heart— two machines in one room, that's not a backup, it's copying two copies waiting to die. Water pipes burst, thieves getting in and taking down the pot, electric scooters downstairs catching fire while charging—any of these happen, it's all about being wiped out. I delayed doing the 'one remote port' in the 3-2-1 for over half a year, until mid-September when my mom's broadband was installed ( wrote about it in the article about remotely managing the router for her), that I finally decided to send the DS220j over and truly fill the remote gap.

first think about three things: what to stockpile, where to stock, and how often to stockpile them

before moving the machine, I'll settle the accounts first. For things from other locations, there are two stalls: 46,000 photos from the photo library, totaling 186GB, plus 20GB of work documents and scans, totaling 206GB. The DS220j has two 4TB drives for RAID1, which is more than enough. The machine is a bit old, so it's more than enough for slow backup tasks.

There is only one

direction: my Feiniu is the source, the DS220j is the destination, one-way, only allowing data to flow from me to my mom's . I discussed this in ransomware —two-way synchronization is a disaster amplifier: one side of the file is encrypted, the other side faithfully synchronizes the encrypted version, effectively destroying the only healthy copy by hand.

frequency, I set it to run incremental runs once every day in the early morning. 206GB is just the first full usage; after running it, the daily addition is only hundreds of megabytes of photos and tens of megabytes of documents, all within a few minutes.

How to get through

remote route: first check the public IP address, if none available, take a detour

two machines are not in the same house, rsync has to go through the public network. The premise of using public networks is that my Feiniu can be reached by outsiders. The first thing is to check the public IP: log in to the router and check the WAN port; if the address matches the exit IP found by your phone's data, then it's genuine public network; If the WAN port starts with 100.64 or 192.168, and there's still the carrier or optical modem layer in front, you need to call number 10000 first to get a public IP or switch to the optical modem for bridging. How to check—I've written a specifically for you, and you can determine it in just three steps.

my home uses gigabit broadband, uplink 50Mbps, which translates to about 6MB/s, which is the speed ceiling for remote syncing—the first full 206GB run at this speed takes about ten hours, with cross-network latency discounted. I actually ran for two nights. Calculate this account first, so you don't have to stare at the progress bar and complain about the machine being slow the first time you run.

There are two paths

open up. I have a public IP at home, and I'm following the proper route: set up DDNS on the router and bind a domain name, and port forwarding the external 50022 to Feiniu's port 22— don't forward the external port with the 22 port as is. The script for scanning the segment can knock you hundreds of times a day. Move to a high-level port and log in with the key mentioned later. The security level is more than enough for home use. If you don't have a public IP at home, don't force it. Just use networking tools like Tailscale to pull two NAS units into the same virtual LAN, run rsync like local access, and don't expose any port externally. I explained the principle thoroughly in my about VPN home.

First Run: Password-Free Login and That Command

the line is open, next is the password-free password. If you stop halfway through a scheduled task to enter a password, it's not a backup—it's an alarm.

my direction was that the DS220j would come to my house proactively, so the private key was placed on the DS220J. SSH enters the DS220j, ssh-keygen -t ed25519 press Enter all the way to append the generated public key to the authorized_keys on Feiniu's side. I was stuck at this step for over half an hour—even after the key was paired, I still needed the password, over and over. Later, I remembered it was about permissions: SSH was extremely picky about the permissions of the home directory. The home and .ssh directories had 700 , the authorized_keys 600, almost silently ignoring your key, reverting to the password without any errors. Synology's home directory is under /var/services/homes/. Try again after changing the permissions, and it will pass in one go.

Then there's that core command, which I ran manually:

rsync -avzh --delete -e "ssh -p 50022" /vol1/photo/ admin@My domain:/volume1/backup/photo/

parameters listed one by one: -a is the archiving mode, with timestamps and permissions carried over as is; -v Let it read out what it did; -z for compression; photos and videos that have already been compressed don't yield much benefit, while documents and tables can save some data; -h converts the numbers into MB and GB that humans can understand. The slash at the end of the source path is important: a slash means "contents in the directory," without it means "connects to the directory itself." If you get it wrong, your backup will add an extra folder. Be sure to use a small directory for the first time.

the first night, after more than six hours of driving, my mom's house tripped the circuit breaker once—in an old neighborhood, the air conditioner and microwave would jump as soon as they started. I don't panic if it stops. rsync's greatest skill is incremental relays—rerunning and continuing the previous progress, then without having to start over. This is far better than a full copy. The second night wrapped up, with the full 206GB installed.

--delete almost deleted my backup

after fully running the plan, I was steady for a week, then got tricked by myself. Over the weekend, I organized my album, deleted a duplicate imported directory, and casually included the 2022 National Day directories next door, 40GB. After deleting the local data, I didn't react in time. That night, the scheduled tasks kept running, and only the next day did I remember to dig them out from the backup— the 40GB in the backup was gone too. --delete means keeping the target and source exactly the same. Whatever you delete at the source, it faithfully deletes what is in the backup, without asking why you deleted it.

this is the essential difference between "mirroring" and "backup": mirroring only ensures both sides are the same, without preserving history; You really need a version to back it up; if you delete it wrong, it can revert to how it was yesterday. Fortunately, the DS220j's storage pool used Btrfs, so I opened the snapshot and retrieved the entire directory exactly as it was from the 5 a.m. snapshot, which lasted forty minutes of false alarm.

After

was pulled back, I changed the order to this:

rsync -avzh --delete --backup --backup-dir=/volume1/backup_trash/$(date +%F) -e "ssh -p 50022" ...

--backup means: Files deleted or overwritten during synchronization do not disappear immediately; they are first moved to the directory specified by backup-dir and archived by date. Combined with the DS220J's daily snapshots, it's like double insurance against accidental deletion. I even set a cleanup task to keep the recycle directory for a month, otherwise it would fill up all 4TB of disks on its own—don't ask me how I know.

Run on time: Task planning and alarms are essential

manual run is only half the run, leaving the rest to the timing. On the DS220j, in the DSM control panel, go → task scheduler→ create → scheduled tasks → user-defined scripts, paste the modified rsync command, and set it to 03:40 every day. Timing is important: the DS220j is currently a pure backup PC, so I turned off its hard drive to hibernate to avoid the disk still groggy when the task started; If you don't want that bit of power, stagger the task window and the hibernation wait. the hibernation about the pit clearing, I wrote about how these two fought.

alarms must be . On the task plan editing page, there is a "Send email notification" option, with the box "Send only when a task is terminated abnormally." At first, I was lazy and didn't get the job. In mid to late September, my mom's house tripped the door again, and the task failed silently for three consecutive nights. I stared at the app and checked the records before realizing it. After completing the email, the task fails and the email rings. It's noisy, but reassuring. You need to configure your sending email in the Control Panel's → Notification Settings first, so don't miss this step.

By the way, readers who use both Synology devices can be lazy: the DSM7 source control panel → file service → advanced → shared folder sync, and the target side opens the rsync service (control panel → file service →rsync), and the graphical interface is just a few clicks. The underlying approach is rsync, but fine-grained parameters like --backup are not exposed. I'm Feiniu and Synosys, but I don't have that luck, so I can only order the servants.

who is worth copying this trick

running for a month, with a daily increment of over ten minutes, the monthly data plan was less than 20GB, and the 50MB uplink was completely imperceptible. Whether this set is worth copying depends on your financial situation:

to wrap up, here's the overall order: check the public IP→ if none are found, use Tailscale→ router forwards high-level ports→ install SSH password-free → mini-directory test run, confirm slash → full → plus backup→ scheduled tasks→ check email alerts. If you get stuck, turn back and check the corresponding section. I've already stepped on the pitfalls for you.