|
Home > Archive > Backup Software > March 2005 > NTBACKUP Verify
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Bob Willard 2005-01-15, 5:45 pm |
| I use NTBACKUP under XP Pro for disk-to-disk backup of a couple of datasets,
and I have noticed that the Verify times are much shorter than the Backup times.
So I kinda suspect that Verify is not a full bit-by-bit read'n'compare of the
original files and the backed-up copies. Does anybody know how NTBACKUP does
the Verify pass?
Time details: On the 6.1 GB Boot dataset, Verify takes 58% of Backup;
6:19 vs. 10:52. This backs up from a 10K RPM SATA HD to
the slow (35-45 MB/s) end of a 7.2K RPM SATA HD.
On the 6.0 GB Data dataset, Verify takes 37% of Backup;
4:31 vs. 12:41. This backs up from the fast (55-60 MB/s)
end of a 7.2K RPM SATA HD to the slow (35-45 MB/s) end of
the same HD.
Hardware: 3.0 GHz P4, Asus P4C800ED MB, 2x512MB of dual-channel ECC RAM.
Please skip the lectures on what's wrong with NTBACKUP/etc; I know all that,
and I'm only interested in how NTBACKUP does Verify.
--
TIA & Cheers, Bob
| |
| Gerard Bok 2005-01-16, 7:45 am |
| On Sat, 15 Jan 2005 14:14:24 -0500, Bob Willard
<BobwBSGS@TrashThis.comcast.net> wrote:
>I use NTBACKUP under XP Pro for disk-to-disk backup of a couple of datasets,
>and I have noticed that the Verify times are much shorter than the Backup times.
>So I kinda suspect that Verify is not a full bit-by-bit read'n'compare of the
>original files and the backed-up copies. Does anybody know how NTBACKUP does
>the Verify pass?
Not a direct answer to your question, but I would tackle this
question by other means:
- Copy a typical backup file
- use a disk-editor to modify a single bit
(or whatever you want :-)
- run verify on the copy
--
Kind regards,
Gerard Bok
| |
| Bob Willard 2005-01-16, 5:45 pm |
| Gerard Bok wrote:
> On Sat, 15 Jan 2005 14:14:24 -0500, Bob Willard
> <BobwBSGS@TrashThis.comcast.net> wrote:
>
>
>
>
> Not a direct answer to your question, but I would tackle this
> question by other means:
> - Copy a typical backup file
> - use a disk-editor to modify a single bit
> (or whatever you want :-)
> - run verify on the copy
>
Thanks, but NTBACKUP only verifies as part of a backup operation. And, my
suspicion is not that its verify would fail to catch simple errors but that
its verify was based on some signature of the data rather than on the data,
such as a checksum of each file.
--
Cheers, Bob
| |
| Rob Turk 2005-01-16, 5:45 pm |
| "Bob Willard" <BobwBSGS@TrashThis.comcast.net> wrote in message
news:vqydncD8y6UQ9nTcRVn-pg@comcast.com...
>I use NTBACKUP under XP Pro for disk-to-disk backup of a couple of
>datasets,
> and I have noticed that the Verify times are much shorter than the Backup
> times.
> So I kinda suspect that Verify is not a full bit-by-bit read'n'compare of
> the
> original files and the backed-up copies. Does anybody know how NTBACKUP
> does
> the Verify pass?
>
> Time details: On the 6.1 GB Boot dataset, Verify takes 58% of Backup;
> 6:19 vs. 10:52. This backs up from a 10K RPM SATA HD to
> the slow (35-45 MB/s) end of a 7.2K RPM SATA HD.
>
> On the 6.0 GB Data dataset, Verify takes 37% of Backup;
> 4:31 vs. 12:41. This backs up from the fast (55-60 MB/s)
> end of a 7.2K RPM SATA HD to the slow (35-45 MB/s) end of
> the same HD.
>
> Hardware: 3.0 GHz P4, Asus P4C800ED MB, 2x512MB of dual-channel ECC
> RAM.
>
> Please skip the lectures on what's wrong with NTBACKUP/etc; I know all
> that,
> and I'm only interested in how NTBACKUP does Verify.
> --
Since you know all the badness already, have you thought of the backup pass
being a lot slower because it needs to maintain and update it's index
database and the archive bits for the files it has saved? Lots of extra
seeks on the disks.
On verify it doesn't need to do all that, and most of the index will be in
RAM. Your verify speeds are about 25MB/s, it's very well possible that
verify does a full compare.
Rob
| |
|
| It is reading in from the media and comparing. I suspect that the write
operation is slower than the read because of compression... it is slower to
compress than to decompress. You might want to try a backup without
compression and see if the times aren't more closer.
"Bob Willard" <BobwBSGS@TrashThis.comcast.net> wrote in message
news:vqydncD8y6UQ9nTcRVn-pg@comcast.com...
>I use NTBACKUP under XP Pro for disk-to-disk backup of a couple of
>datasets,
> and I have noticed that the Verify times are much shorter than the Backup
> times.
> So I kinda suspect that Verify is not a full bit-by-bit read'n'compare of
> the
> original files and the backed-up copies. Does anybody know how NTBACKUP
> does
> the Verify pass?
>
> Time details: On the 6.1 GB Boot dataset, Verify takes 58% of Backup;
> 6:19 vs. 10:52. This backs up from a 10K RPM SATA HD to
> the slow (35-45 MB/s) end of a 7.2K RPM SATA HD.
>
> On the 6.0 GB Data dataset, Verify takes 37% of Backup;
> 4:31 vs. 12:41. This backs up from the fast (55-60 MB/s)
> end of a 7.2K RPM SATA HD to the slow (35-45 MB/s) end of
> the same HD.
>
> Hardware: 3.0 GHz P4, Asus P4C800ED MB, 2x512MB of dual-channel ECC
> RAM.
>
> Please skip the lectures on what's wrong with NTBACKUP/etc; I know all
> that,
> and I'm only interested in how NTBACKUP does Verify.
> --
> TIA & Cheers, Bob
| |
| Bob Willard 2005-03-07, 5:45 pm |
| JohnA wrote:
> It is reading in from the media and comparing. I suspect that the write
> operation is slower than the read because of compression... it is slower to
> compress than to decompress. You might want to try a backup without
> compression and see if the times aren't more closer.
>
Good guess, John, but that is not the cause -- NTBACKUP does not do
compression. In fact, backing up a couple of text files (one 8MB and
one 256MB) that would compress well, the backup copies were slightly
larger than the originals (some header data, I'm sure).
--
Cheers, Bob
| |
|
| Yes, I was thinking of Backup My PC - the commercial version. You're right
that ntbackup only supports hardware compression. My only other guess is
that writes are somehow slower on your device than reads... for example, on
my DVD media, writing is twice as slow as reading (1X vs 2X). I wouldn't
have guessed this for a hard drive however...
"Bob Willard" <BobwBSGS@TrashThis.comcast.net> wrote in message
news:DMmdnWFKjIKqNrHfRVn-pw@comcast.com...
> JohnA wrote:
>
> Good guess, John, but that is not the cause -- NTBACKUP does not do
> compression. In fact, backing up a couple of text files (one 8MB and
> one 256MB) that would compress well, the backup copies were slightly
> larger than the originals (some header data, I'm sure).
> --
> Cheers, Bob
| |
| abram@mailinator.com 2005-03-08, 8:45 pm |
| You may want to try http://www.firestreamer.com/fsdvd/
JohnA wrote:
> Yes, I was thinking of Backup My PC - the commercial version. You're
right
> that ntbackup only supports hardware compression. My only other
guess is
> that writes are somehow slower on your device than reads... for
example, on
> my DVD media, writing is twice as slow as reading (1X vs 2X). I
wouldn't[vbcol=seagreen]
> have guessed this for a hard drive however...
>
> "Bob Willard" <BobwBSGS@TrashThis.comcast.net> wrote in message
> news:DMmdnWFKjIKqNrHfRVn-pw@comcast.com...
write[vbcol=seagreen]
slower[vbcol=seagreen]
without[vbcol=seagreen]
and[vbcol=seagreen]
slightly[vbcol=seagreen]
| |
| Bob Willard 2005-03-09, 7:45 am |
| abram@mailinator.com wrote:
> You may want to try http://www.firestreamer.com/fsdvd/
>
>
> JohnA wrote:
>
>
> right
>
>
> guess is
>
>
> example, on
>
>
> wouldn't
>
>
> write
>
>
> slower
>
>
> without
>
>
> and
>
>
> slightly
>
>
>
Thanks for the suggestion. Looking at the specs/etc. on the product's
website, I probably won't use it, but thanks anyway.
--
Cheers, Bob
|
|
|
|
|