#Grsync time remaining bullshit archive#

There’s no need to needlessly sync files that haven’t changed since the last backup :-). If, when the cronjob runs again, no files have been changed, nothing will be synced. Store the verbose output of the command to /var/log/synology.log (not required). Recursively sync files from /droplet/path/to/files to /source/for/backups.ģ). So for example, our cronjob might look something like (on the Droplet): 0 2 * * 1 rsync -avzhe 'ssh -i /path/to/synology/privatekey' /droplet/path/to/files > /var/log/synology.logġ). If you’re not familiar with setting up a cronjob, I’d use from there, near the bottom of the file is where you’ll actually add the command and setup the frequency at which the job runs. On Ubuntu, you can setup a cronjob using crontab -e from the CLI. You can setup a cronjob to run the same commands at a time/frequency of your choosing :-). If you’ve got something like that setup, a basic guide to rsync can be found here: I’m not too familiar with Synology or how it works, though if you want to setup a cronjob to rsync your files offsite, you’ll need a way to connect and generally, that’s going to be a static IP or through some sort of dynamic DNS solution (such as ) on your end.

#Grsync time remaining bullshit archive#

You could could use rsync if you went with the archive option as well, of course :).

If the data set is large, rsync may be a better option that way you’re only syncing changes instead of repeatedly backing up data that hasn’t changed. If the data set it small, simply generating an archive of the data may prove to be the easiest solution. Solution really depends on the size of the data set – that’s the first thing I generally look at.