Re: Source directory doesn't exist - should this be fatal?
Gordon Messmer <gordon.messmer <at> gmail.com>
2015-07-15 16:43:11 GMT
On 07/14/2015 06:50 PM, Ken Woods wrote:
>> >I don't see why that would scale less well in a single configuration
>> >file rather than individual files per host (or per volume).
> Math. It's hard, yeah?
First, admittedly, I totally garbled my reply. I apologize for that.
However, I don't really see the point that you're trying to make. David
suggested that a failure in one retain line should be treated as a
warning rather than an overall failure. Nico's reply suggested that he
separate different hosts or different services into separate
configuration files so that a failure would affect only the backup of
that host or service.
That's a perfectly reasonable suggestion, and I don't see how it creates
Especially when you have a very large number of hosts or directories to
back up, separating them into their own configuration files becomes more
desirable. Each host (or however you decide to partition your
configurations, but I'll use host for example) can be generated from a
template, as Nico suggested. That makes maintenance much easier. When
you're dealing with hundreds or thousands of entries, you don't want to
manage the configuration by hand. Adding or removing items is much more
reliable when you script your maintenance tasks.
With individual files, you'll probably use a short script similar to
"run-parts" to run rsnapshot with the interval specified for each of the
configuration files present. rsnapshot processes each of the "retain"
entries in the configuration files in series. If you break up your
configuration files and process them in a loop, that remains true.
However, you can choose to add logic to the loop to run several
rsnapshot instances in parallel if your backup disk is fast enough to
not be the bottleneck in your backup system. In that case, individual
files scale better than a single file.
Finally, the exit status of rsnapshot is the only really reliable means
it has of indicating whether the backup process was successful or not.
You could, as I did, use the exit status and the name of the
configuration file run to feed a monitoring system so that alerts can be
generated when backups fail, and provide a dashboard for monitoring a
large set of backups. If individual "retain" lines are demoted to a
warning from a failure, then the ability to reliably communicate failure
is lost. rsnapshot only gets one exit code, and it should definitely be
used to indicate the most severe error that it encountered during a
So, for reliability and scalability, individual files really look like
best practice to me. If you think I'm wrong, I'm open to criticism.
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.