I know this discussion ended, in practical terms a while ago, but I
started some thoughts back then, and didn't have time to finish them.
So, I did so today, and thought they might be helpful in a conceptual
way.
One way to cut down on verify times would be to limit the number of delta's in
the
I'm not sure what you're doing with your --verify...
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets updated with a
delta, and you want to verify that file X is the same both on the
source and destination locations/drives.)
On Nov 24, 2009, at 7:01 PM, Alex Samad wrote:
On Tue, Nov 24, 2009 at 04:12:16PM -0500, Daniel Miller wrote:
On Nov 24, 2009, at 3:44 PM, listserv.traf...@sloop.net wrote:
[snip]
In my scenario the repository is synced to an external USB drive
that gets rotated each day (i.e. each day I
On Nov 25, 2009, at 12:25 PM, listserv.traf...@sloop.net wrote:
snip explanation of how rdiff-backup works
Sounds good.
So, a --verify isn't needed to verify the current files. The very
nature of RDB is that they're exact. (provided you trust the RDB
protocol...which we assume.)
OK, I can
[Inline]
On Nov 25, 2009, at 12:25 PM, listserv.traf...@sloop.net wrote:
snip explanation of how rdiff-backup works
Sounds good.
So, a --verify isn't needed to verify the current files. The very
nature of RDB is that they're exact. (provided you trust the RDB
protocol...which we assume.)
On Wed, Nov 25, 2009 at 02:12:37PM -0500, Daniel Miller wrote:
[snip]
I never do a direct compare between the two drives. I just use rsync
to copy from the FW to the USB drive. Here's my concerns: without
some type of regularly executed integrity check of the data on the
drive (FW or
listserv.traf...@sloop.net wrote:
I'm not aware, so if I'm wrong perhaps someone could correct me, but
I'd like a command to, in essence, do a comprehensive
--verify-all-files-in-the-archive. [I'm pretty sure such a thing
doesn't exist, at least I never saw it in the docs.]
This would apply
On Tue, Nov 24, 2009 at 09:00:48AM +, Dominic Raferd wrote:
listserv.traf...@sloop.net wrote:
I'm not aware, so if I'm wrong perhaps someone could correct me, but
I'd like a command to, in essence, do a comprehensive
--verify-all-files-in-the-archive. [I'm pretty sure such a thing
Daniel Miller wrote:
Why is the time needed to verify a three-month-old backup not leveling
off? And is there a way to bring down my verification times but still
be sure that my backup archives are not becoming corrupt due to
decaying storage media, etc? Is there some other method of
Gavin wrote:
Daniel Miller wrote:
Why is the time needed to verify a three-month-old backup not
leveling
off? And is there a way to bring down my verification times but still
be sure that my backup archives are not becoming corrupt due to
decaying storage media, etc? Is there some other
I mis-posted, and should have replied to the list, instead of just
Daniel...so here it is...
---
I'm not sure what you're doing with your --verify... [I'm confused, I
think...]
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets
[Now I'm bottom posting... :)]
---
I'm not aware, so if I'm wrong perhaps someone could correct me, but
I'd like a command to, in essence, do a comprehensive
--verify-all-files-in-the-archive. [I'm pretty sure such a thing
doesn't exist, at least I never saw it in the docs.]
This would
On Nov 24, 2009, at 3:44 PM, listserv.traf...@sloop.net wrote:
I'm not sure what you're doing with your --verify...
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets updated with a
delta, and you want to verify that file X
See inline...
I'm not sure what you're doing with your --verify...
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets updated with a
delta, and you want to verify that file X is the same both on the
source and destination
On Tue, Nov 24, 2009 at 04:12:16PM -0500, Daniel Miller wrote:
On Nov 24, 2009, at 3:44 PM, listserv.traf...@sloop.net wrote:
[snip]
In my scenario the repository is synced to an external USB drive
that gets rotated each day (i.e. each day I put yesterday's drive in
storage and bring a
Ideology: I do the large verify every day on the remote system to
make
sure my backup history is not becoming corrupt (e.g. due to disk
failure, etc.). Ideally I would like to verify the past year, but
that
will obviously take way too long to be possible with my setup.
Observations:
Despite
On Mon, Nov 23, 2009 at 09:06:42AM -0500, Daniel Miller wrote:
Why is the time needed to verify a three-month-old backup not
leveling off? And is there a way to bring down my verification times
but still be sure that my backup archives are not becoming corrupt
due to decaying storage media,
Daniel Miller wrote:
I think you are misunderstanding how --verify works. If you say:
rdiff-backup --verify-at-time 1Y
it does not verify the last 1 years worth of backups. It verifies a
single backup a year ago (I believe the closest backup before that exact
time); hence the name
Matthew Flaschen wrote:
That is incorrect. Every 10 incremental diffs, rdiff-backup stores
another snapshot of the file. [...] During the restore, rdiff-backup
finds the oldest snapshot at least as recent as the desired backup time
(it could be the current mirror, or one of these snapshots).
I know Matt corrected this post, but I wanted to address this:
---
If you do a --verify-at-time xyz where xyz is your oldest backup, it
should verify all files in that backup - so every delta should be
applied. This should verify that all delta's (backups) are good and
functioning.
[In short, it
Daniel Miller wrote:
Ideology: I do the large verify every day on the remote system to make
sure my backup history is not becoming corrupt (e.g. due to disk
failure, etc.). Ideally I would like to verify the past year, but that
will obviously take way too long to be possible with my setup.
21 matches
Mail list logo
