Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] rsnapshot vs. rdiff-backup



Since rsnapshot always grabs the oldest of the previous type (eg oldest
hourly, daily, et. al), there is a very simple solution.
Just set up a simple shell script to use the GNU cp(1) using the link
option.  On the first day of the month, simply schedule the script to
link the proper hourly or daily. Since rsnapshot renames directories
when it runs, you can cd into the appropriate hourly or daily and do the
cp on '.'.  So, this way you can have your monthly and yearly reflect
the snapshot for that calendar day. But in a commercial situation, you
may want your backup archives to include all changes and deletions along
the way. This is where a true backup system is useful. I actually worked
on a system where we had to go back to our backups from 5 years ago.

On 12/04/2013 04:09 PM, John Abreau wrote:
> I never used the hourly level, just the daily, weekly, monthly, and yearly.
> I believe the higher levels were each grabbing the oldest instance of the
> level immediately below it, rather than the newest instance.
>
> i wanted the higher levels to use the newest, so that, e.g.,, the monthly
> snapshot made on March 1, 2012 would be a copy of the daily snapshot from
> March 1, 2012, and the yearly snapshot made on January 1, 2013 would be a
> copy of the daily snapshot from January 1, 2013. That way the age of each
> archival directory would be more predictable.
>
>
>
>
> On Wed, Dec 4, 2013 at 11:37 AM, Richard Pieri <richard.pieri at gmail.com>wrote:
>
>> John Abreau wrote:
>>
>>> I've never liked the way rsnapshot handles the additional levels of
>>> snapshots. As I recall, the most recent weekly was several weeks old, the
>>> most recent monthly  was always several months old, etc.
>>>
>> This suggests to me that the scheduling is off. It could be due to
>> incorrectly staggered cron jobs or runs overlapping. Overlaps /will/ wreck
>> the rotation cycles so it's important not to set your backup runs too close
>> together. Despite the name, the "hourly" increments aren't necessarily
>> hourly; I typically run them 3-6 hours apart.
>>
>> Tedious, like I originally wrote. :/
>>
>>
>>  Also, when I used rsnapshot to back up dozens of servers, I found that if
>>> only one portion of one server's backups failed, it would roll back
>>> everything, and I'd lose backups for all servers.
>>>
>> I discovered this the hard way. It's more reliable if each node runs its
>> own installation and pushes to a unique directory on the backup target.
>> Trying to glom many nodes together in a single rsnapshot run is not a good
>> way to do it.
>>
>> --
>> Rich P.
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>>
>
>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org