Cal Sawyer
10 years ago
Hi
You fellows are, of course, absolutely right. What i discovered in
retrospect was that the snapshots i had varied widely in date, so huge
deltas and generally a pretty rotten example
This morning, i collapsed a 7-day tree onto 5 by deleting daily.6 and
daily.5. Those deletes took barely any time at all and the subsequent
snapshot was similarly very fast.
thanks very much to everyone who pitched in
Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | www.blue-bolt.com
On 25/04/15 02:33, rsnapshot-discuss-***@lists.sourceforge.net wrote:
From: David Keegel <***@cyber.com.au> Subject: Re: [rsnapshot-discuss]
Collapsing a rsnapshot tree? To: Cal Sawyer <cal-***@blue-bolt.com> Cc:
rsnapshot discussion list <rsnapshot-***@lists.sourceforge.net>
Message-ID: <***@honey.keegel.id.au> Content-Type:
text/plain; charset=us-ascii I agree with Scott (and most of the other
comments on this thread). On Fri, Apr 24, 2015 at 10:34:49AM +0100, Cal
(1) files which are no longer current (not present in daily.0), and
will use up disk space that can be freed by deleting them (assuming
you don't have any weekly or similar backups), but deleting them
will have no effect on the next day's backup
(2) files which do exist in daily.0, in which case having a hard link
to them in daily.3-6 will not make any difference to disk space
used; if daily.3-6 are deleted then the link count for those files
in daily.0 will go down but no disk space will be freed . If the
files still exist in daily.0 then it will have no effect on the
next day's backup, because linking is only done against daily.0.
I don't think deleting daily.3-daily.6 was naive at all.
If you measured "lost a few TB of data" using df, then the difference
would be old files which are no longer current, and hence not relevant
to how long the rsnapshot will take.
To explain the "took quite a while to complete", I'd be looking at
whether there were many differences between daily.0 and your source
file systems. For example, something messed with daily.0, or lots
of files on the source directory appear to have changed (for example
the mtime differs between files in source and daily.0).
Or whether something changed in your rsnapshot config that means it
is not making hard links properly any more (in which case I'd expect
each rsnapshot will take quite a while until that is fixed).
and I think the answer is*not* because you deleted old daily.3-6 (which
are no longer used nor relevant to rsnapshot).
You fellows are, of course, absolutely right. What i discovered in
retrospect was that the snapshots i had varied widely in date, so huge
deltas and generally a pretty rotten example
This morning, i collapsed a 7-day tree onto 5 by deleting daily.6 and
daily.5. Those deletes took barely any time at all and the subsequent
snapshot was similarly very fast.
thanks very much to everyone who pitched in
Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | www.blue-bolt.com
On 25/04/15 02:33, rsnapshot-discuss-***@lists.sourceforge.net wrote:
From: David Keegel <***@cyber.com.au> Subject: Re: [rsnapshot-discuss]
Collapsing a rsnapshot tree? To: Cal Sawyer <cal-***@blue-bolt.com> Cc:
rsnapshot discussion list <rsnapshot-***@lists.sourceforge.net>
Message-ID: <***@honey.keegel.id.au> Content-Type:
text/plain; charset=us-ascii I agree with Scott (and most of the other
comments on this thread). On Fri, Apr 24, 2015 at 10:34:49AM +0100, Cal
Thanks
The reverse is actually what happened, i think. I had a daily 7 setup
that i had reconfigured to daily 3 When i run rsnapshot -v manually, i
can see at what level it's doing its initial rm's and cp's and
daily.4-6 are no longer being touched, although they held data - a lot
of it.
These data are either:The reverse is actually what happened, i think. I had a daily 7 setup
that i had reconfigured to daily 3 When i run rsnapshot -v manually, i
can see at what level it's doing its initial rm's and cp's and
daily.4-6 are no longer being touched, although they held data - a lot
of it.
(1) files which are no longer current (not present in daily.0), and
will use up disk space that can be freed by deleting them (assuming
you don't have any weekly or similar backups), but deleting them
will have no effect on the next day's backup
(2) files which do exist in daily.0, in which case having a hard link
to them in daily.3-6 will not make any difference to disk space
used; if daily.3-6 are deleted then the link count for those files
in daily.0 will go down but no disk space will be freed . If the
files still exist in daily.0 then it will have no effect on the
next day's backup, because linking is only done against daily.0.
When i (naively) deleted daily.3-daily.6, i lost a few TB of data which
Deleting daily.3-6 makes sense and is what I would have done.I don't think deleting daily.3-daily.6 was naive at all.
i lost a few TB of data which
then had to be picked up again in the latest daily (which took quite a
while to complete).
This bit I don't understand.then had to be picked up again in the latest daily (which took quite a
while to complete).
If you measured "lost a few TB of data" using df, then the difference
would be old files which are no longer current, and hence not relevant
to how long the rsnapshot will take.
To explain the "took quite a while to complete", I'd be looking at
whether there were many differences between daily.0 and your source
file systems. For example, something messed with daily.0, or lots
of files on the source directory appear to have changed (for example
the mtime differs between files in source and daily.0).
Or whether something changed in your rsnapshot config that means it
is not making hard links properly any more (in which case I'd expect
each rsnapshot will take quite a while until that is fixed).
So the question remains. i think - how best to
condense/collapse older daily snapshots when reducing the retention
time?
No, I think the question is why did your rsnapshots start taking longercondense/collapse older daily snapshots when reducing the retention
time?
and I think the answer is*not* because you deleted old daily.3-6 (which
are no longer used nor relevant to rsnapshot).
...
--
___________________________________________________________________________
David Keegel <***@cyber.com.au> Cyber IT Solutions Pty. Ltd.
http://www.cyber.com.au/~djk/ Linux & Unix Systems Administration
___________________________________________________________________________
David Keegel <***@cyber.com.au> Cyber IT Solutions Pty. Ltd.
http://www.cyber.com.au/~djk/ Linux & Unix Systems Administration