[sf-perl] [ot] pruning rsnapshot backups
mgrimes at cpan.org
Thu Mar 25 11:49:47 PDT 2010
Each tree is made up of files that may share inodes with other trees.
Deleting one file will not delete its contents as long as there is
another file that references that inode. You should be able to delete
one tree without impacting others***.
That said, since the trees sharing inodes, they typically don't take
up all that much room. If you are just deleting blindly you might have
to delete a whole bunch of trees to make an impact. I have a q&d perl
script that I use to see which trees are really taking up space. Often
you can spot something odd in just a few backups that are taking up a
bunch of room. You can find the script at:
Hope it is helpful.
*** I am not all that familiar with rsnapshot specifically, but I use
the rsync --link-dest in my own backup scripts.
On Thu, Mar 25, 2010 at 2:10 PM, David Alban <extasia at extasia.org> wrote:
> i have a nightly rsnapshot job which is running out of disk space.
> assume that it's a major pita to get additional disk space and that
> i'm stuck with what i now have.
> currently i have three hundred and seventy five backup trees,
> representing slightly more than a year of daily backups. say i want
> to keep only twenty selected trees from this set. i'm assuming i can
> delete 355 of the trees without compromising the integrity of the
> remaining twenty trees, because each backup tree is completely
> independent of any other backup tree.
> but i wanted to run this by some folks for a sanity check.
> do you think i'm safe doing this? am i missing anything?
>  i know that when a backup tree is *created* rsnapshot uses the
> previous tree to determine whether to reuse an inode or to use a new
> one. but after the backup is created, the new tree is completely
> independent of the old tree,
> Live in a world of your own, but always welcome visitors.
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm