Not sure if this is the correct place to post but I’m wondering that since the initial backup would take so long (say if it’s backing up a large folder across the WAN) would it be possible to pause and resume the backup based on a schedule?
This way the initial backup can happen when I know the network is not in use?
I would not mind if it took a few days for it to accomplish the initial backup as long as it’s during non-use hours.
And along the same lines, is it possible to specify how much bandwidth should be allocated for restic? So say I know that my network is 10Mbps (upload speed) I would like to have restic only consume half of that.
I’m trying to address the issue of minimizing network impact which is why there are 2 questions here…
With the way restic works currently, you can just interrupt the backup run and start it again later whenever you want. On every run, restic will scan the files to back up, but only send what has not yet been sent to the repository, so you will effectively be able to run your initial backup over several separate invocations.
There’s no “scheduling” for it in restic itself, but you can easily script this if you really want to. Just start the backup at certain times and shut restic down at certain times.
To know when you first backup has completed, run restic snapshots to see if you get any snapshots. The first snapshot will not be created until everything has been backed up in its entirety.
Restic has a --limit-upload int flag, which should do what you are looking for. I haven’t used it myself though.
The only downside of interrupting incomplete backups is that as long as there is no complete initial backup, restic will read all files again, detect that they were already backed-up and continue. Depending on your backup size this might slow down later runs a bit.
Thank you for the valuable info gentlemen. I will definitely test the bandwidth limiting option.
I’m also curious how I would interrupt the backup. I know this may sound totally noobish but would I script it to kill -9 the process? It feels a little harsh to do that.
And if that is the recommendation then wouldn’t doing that corrupt certain data?
There is the possibility that restic might write out an incomplete pack or index file if it is forcibly terminated. Both of these are not serious issues and are easily corrected. restic check would pick up on both of them. (In fact, with object storage backends like S3, B2, etc. it’s not even possible as the remote will detect that the upload was incomplete and not persist the data. It’s only possible with filesystem-like backends, such as a local directory or sftp.)
rclone allows you to set bandwidth-limits with a timetable. This is a nice way to adjust bandwidth usage to your business hours without interrupting the backup (or any other operation).
Depending on the situation, you might also take a look at ionice which handles priorities with local file system bandwidth. Maybe that would be sufficient or a good companion to the connection bandwidth above.
