On 04/04/2012 07:40 PM, Ken Woods wrote:
> Sorry for the rudeness in my response, as well.
> It sounds as if you set rsnapshot up, got it working, then fucked with
> the configuration, and now you're pissed because you realize that it's
> messed up and doesn't do what you want it to do without modification.
> That's the wonderful thing---change it as you see fit.
Yep, you're right :)
Well, I actually discovered this when trying to deterimine if rsnapshot
is well behaved.
> My thoughts are interspersed.
> On Tue, Apr 3, 2012 at 3:50 PM, Espen<espenx3@...> wrote:
>> The way rsnapshot only syncs to the top-most interval/retain config
>> directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
>> "weekly"/"monthly") depends on the the first one in this list, is really
>> flawed, confusing and error prone in my opinion.
> It's not at all, in my opinion.
> It makes recovery easy, simple, and fast.
> This is the expected behaviour, IMO.
The point is that the way it works today is uneccesary confusing and
There are alot of other posts to this mailing list addressing the exact
Recovery with my suggested solution is also as easy, simple and fast.
>> When running "rsnapshot weekly" when having "retain daily 3" at the top
>> in the config file, you'll get a weekly backup _only_ if daily.0 exists,
>> and regardless of when daily.0 was created.
Becuase it's not a weekly backup. It's a weekly copy of whatever daily.0
"rsnapshot daily" and "rsnapshot weekly" does different things because
if this dependency on eachother.
> Why would that matter?
> Daily's are run every day, or, as in my case, as often as possible.
> Sometimes my daily backup takes 36 hours to run. Sometimes they take
> an hour. I'm backing up somewhere between 6 terabytes and
> 200megabytes. I simply don't care what they're called---as long as
> they run and rotate. The name is meaningless.
Even because you _can_ name the backups whatever you want, doesn't mean
that it is sane to do so.
The way each retain setting depends on the one above it strongly suggest
that you should name them something that is visually sortable: daily,
weekly, monthly - one, two, three - etc.
>> "rsnapshot daily" in cron, while forgetting to comment out "retain daily
>> NUM" in the config file, then your backup plan is completely borked!
> rsnapshot is not responsible for your failure to do things correctly
> and with care.
> It doesnt' know what you want unless you tell it.
>> In addition to this, it also seems like it is very important to run the
>> cron daily/weekly/monthly jobs in the correct order, and with a
>> (uncertain) delay between each of them, in order for rsnapshot to work
> Indeed. This is well documented. Perhaps large red letters in the
> docs would help?
> 01 05 * * * root /usr/bin/rsnapshot daily
> 01 04 * * 6 root /usr/bin/rsnapshot weekly
> 01 03 1 * * root /usr/bin/rsnapshot monthly
>> I also dislike the way rsnapshot forces you to seperate arguments with
>> <TAB> in the config file.
>> Especially because my editor (vim) expands all tabs to 4 spaces. It
>> would be much better if rsnapshot required quotes around the config
>> arguments that contains spaces.
> This would require a lot of changes to the code.
> Quotes aren't good in configurations, for the obvious reasons.
> Besides, as has been mentioned, vim does handle tabs.
Haven't really given this much thought, but i know bash and Getopt for
perl already does well with e.g command line arguments enclosed in
quotes, or arguments with escaped meta characters.
>> I hope I'm not offending anyone, but large portions of the rsnapshot
>> code also seems old and outdated (atleast at first sight), and would
>> probably benefit alot from some simple refactoring, cleanup and
>> abstraction. I'm blaming this mostly on the age of the Perl code
> This is true. However, the developers are unwilling to change things
> because right now, it works and is VERY stable.
>> Why should you have to specify "retain daily 3", "retain weekly 4", and
>> so on, in the config when you'll have to create seperate cron-jobs for
>> all of these anyway?
>> It doesn't make sense?
> It does from a server standpoint, but certainly not a machine that's
> turned on and off.
> It also make sense when you have machines with massive amounts of
> data, such as mine, that sometimes take longer to back up than the
> interval time. My initial backup took 9 weeks to run. That's not a
> typo. Obviously, the rsync had to be run by hand several times. I
> would *MUCH* rather rely on the lock than anything else. I know it
> won't do duplicate runs if it's locked, so.......
> 122T /storage/pangea_snapshots/daily.0/
> 452G /storage/pangea_snapshots/daily.1/
> 940G /storage/pangea_snapshots/daily.2/
> 922G /storage/pangea_snapshots/daily.3/
> 23G /storage/pangea_snapshots/daily.4/
> 733G /storage/pangea_snapshots/daily.5/
> 824G /storage/pangea_snapshots/daily.6/
> 567G /storage/pangea_snapshots/daily.7/
> (daily.4 was stopped on purpose, ignore that...)
> Anyway, you propose interesting ideas, I'd say implement things as
> they work for you.