NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
nickjames
Feb 19, 2017Luminary
Documentation for Replicate, specifically backup and restoring data
Hello, I've been using Replicate for about 3 years now and luckily (knock on wood), I'v never had to restore my backup NAS to my primary NAS. That being said, I can't find any documentation on ho...
- Feb 26, 2017
Thanks againg for your input, StephenB and TeknoJnky.
I got everything backed up this last week and so far as good.
StephenB, I know when I called into Netgear originally to setup Replicate, they suggested NOT to use snapshots on the destination (backupnas) device. Should I also not be creating snapshots on the destination device, when using Rsync?
By the way, I'm going with the "pull" method as I like the idea of putting the NAS on a power schedule. That being said, do I just figure how long the backup jobs should take, schedule them within the hours that the NAS is powered on, and that is it? Will it power off automatically if schedule backups are pending or in the middle of finishing one?
Here is a picture of my current schedule, which by the way, can you just have them all run at the same time and it will run each one, one-by-one until completion?
Thanks again for your suggestions!
nickjames
Feb 21, 2017Luminary
http://kb.netgear.com/29929/ReadyNAS-OS-6-Setting-up-a-backup-job-with-rsync-over-SSH?cid=wmt_netgear_organic
Is this the best KB for this setup, Stephen?
Is this the best KB for this setup, Stephen?
aalexandrebeta
Feb 21, 2017Master
interresting topîc!
- nickjamesFeb 21, 2017Luminary
Hi Stephen,
I was able to get the "push" and "pull" method setup. I did a few tests to understand how that checkbox option works when deleting the files on the destination as well. I did have quick question - suggested puling the data whereas the KB article I was using suggested pushing the data as a snapshot is created at the time of push?
Here are the KB articles that I ended using:
→ http://kb.netgear.com/29929/ReadyNAS-OS-6-Setting-up-a-backup-job-with-rsync-over-SSH
Is there really a "better" method between the two? Could you give a scenario where you might want one but not the other?
Cheers,
Nick
- StephenBFeb 21, 2017Guru - Experienced User
nickjames wrote:
I was able to get the "push" and "pull" method setup. I did a few tests to understand how that checkbox option works when deleting the files on the destination as well. I did have quick question - suggested puling the data whereas the KB article I was using suggested pushing the data as a snapshot is created at the time of push?
The "push" backup does create a snapshot on the source share first. That is an advantage - it ensures that you get a coherent backup even if users are changing files in the share during the backup, or if there is an on-line database that is being updated during the backup. Another small advantage - if the backup NAS isn't working, the "errors" notification email will kick in, and you'll get notified that the backups failed.
My backup NAS are on a power schedule though - and with a "push" backup the NAS will do it's normal power scheduled power down. A "pull" backup will run to completion - the NAS waits for the completion before it shuts down. So that overrides the advantages of "push" for me. Since the NAS is for personal use, I can schedule the "pull" backups for off-hours times, when the data isn't likely to be changed. One backup job on each backup NAS is configured to always send me status, so I do get positive daily email notifications that the backup NAS are functioning.
If your backup NAS is turned on 24/7, then it's probably better to use "push". But in practice, "push" works out for me, and I like keeping the backups off when they are not in use.
- nickjamesFeb 21, 2017Luminary
StephenB wrote:
nickjames wrote:I was able to get the "push" and "pull" method setup. I did a few tests to understand how that checkbox option works when deleting the files on the destination as well. I did have quick question - suggested puling the data whereas the KB article I was using suggested pushing the data as a snapshot is created at the time of push?
The "push" backup does create a snapshot on the source share first. That is an advantage - it ensures that you get a coherent backup even if users are changing files in the share during the backup, or if there is an on-line database that is being updated during the backup. Another small advantage - if the backup NAS isn't working, the "errors" notification email will kick in, and you'll get notified that the backups failed.
My backup NAS are on a power schedule though - and with a "push" backup the NAS will do it's normal power scheduled power down. A "pull" backup will run to completion - the NAS waits for the completion before it shuts down. So that overrides the advantages of "push" for me. Since the NAS is for personal use, I can schedule the "pull" backups for off-hours times, when the data isn't likely to be changed. One backup job on each backup NAS is configured to always send me status, so I do get positive daily email notifications that the backup NAS are functioning.
If your backup NAS is turned on 24/7, then it's probably better to use "push". But in practice, "push" works out for me, and I like keeping the backups off when they are not in use.
Thanks for taking the time to reply with that detailed update!
I like what you are saying as I'm in the same boat-- I only ran backups when the business is closed so no-one should be accessing the data. It sounds like a good idea to use the power schedule so the device is not running all the time as well. This will save on the wear and tear too. Genius!
Those screen shots are sweet! Hopefully, this thread helps other in the future too!
I'll keep you posted on the progress with this project. From the sounds of it, Replicate is not as useful as RSYNC? I'm having a hard time understanding why you would want to use Replicate over RSYNC? RSYNC seems a lot more robust and readily available, ie- not having to restore your Replicate instance in a true "down" or "hardware failure" state
Related Content
- May 13, 2025Retired_Member
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!