Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |