I love rsnapshot, for the most part. It’s one of the most efficient and straightforward incremental backup solutions I’ve ever used — much more reliable than some of the commercial solutions I’ve tried. It leverages the power of GNU cp, your filesystem, rsync and others and smashes them all together into a big happy chunk of reliability.
However, it must contain some idiocy, and I guess it’s somewhere in parse_config_file. I just set up another server, the same way I usually do, but it needed a slightly different rsnapshot.conf. So I edited the one that was there and known to work because it automatically comes off my server images. Afterwards I wanted to do a test run of each of the backup intervals, because that’s what you do. But rsnapshot didn’t agree. It didn’t disagree either. It didn’t do *anything*.
The next step was to increase its logging verbosity and look for hints in syslog. Interesting: It seems to read its config file successfully and it even writes a pid file. Next, it checks for stale backup directories it might have to rotate. That means it parsed its config file and is happy, no? No! The thing wouldn’t copy anything into the backup. Not a single file!
As a last resort, I straced one of those test runs but forgot to include the tracing of child processes. That probably would have given me more of a clue — the way it was, it just added to my confusion.
In the end I decided to unpack a fresh, distribution-approved config file from /usr/share/doc/rsnapshot/examples and to make the required changes by hand. I retested while already preparing to submit a bug report, when… It worked! The thing performed all the backups reliably, packed up and went to sleep until cron wakes it up tomorrow.
There must have been **some** character **some**where in my config file that deeply confused rsnapshot, confused it so much that it claimed the config file syntax was OK but silently refused to work.
Perhaps config file parsing in rsnapshot has to be rethought. The way I see it, this is sad indeed. It’s the least reliable bit in an otherwise very reliable package, but it’s always the weakest link that breaks the chain, and other assorted age-worn sayings.