|
|
|
date: Sun, 23 Aug 2009 11:30:48 +0100,
group: uk.comp.misc
back
Backup file fragmentation
I have three HDDs on my computer; two internal ones configured as
drives C & D, and the third configured as Drive G, and which is
external to the computer linked via a USB cable. All three drives are
formatted NTFS. The external drive is used solely for backup, using
the seldom-mentioned MS Backup programme in Windows XP (ntbackup.exe),
giving in my case a single .bkf file of some 50Gb in size.
I keep drives C & D continuously defragmented using Ashampoo Magical
Defrag 2, but the other day I thought I'd see how fragmented was drive
G. It was seriously fragmented, so I set the defragger to work on it.
After about 36 hours of continuous defragging, it had made very little
progress, so I thought that a quicker approach would be to delete the
backup file completely and run the backup programme. This would give a
fresh backup file which I expected to be unfragmented.
Not a bit of it. The fresh backup file was as fragmented as before.
My questions are: is this typical of backup files in general or just
those created by the MS backup utility? Is there a good reason for it
and would defragging them damage them in some way? In any case,
attempting to defrag them would seem a rather protracted exercise!
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Sun, 23 Aug 2009 11:30:48 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:ge6295h9fs6vn9s7rp0t8lktg58rlm5j2h@4ax.com...
>I have three HDDs on my computer; two internal ones configured as
> drives C & D, and the third configured as Drive G, and which is
> external to the computer linked via a USB cable. All three drives are
> formatted NTFS. The external drive is used solely for backup, using
> the seldom-mentioned MS Backup programme in Windows XP (ntbackup.exe),
> giving in my case a single .bkf file of some 50Gb in size.
>
> I keep drives C & D continuously defragmented using Ashampoo Magical
> Defrag 2, but the other day I thought I'd see how fragmented was drive
> G. It was seriously fragmented, so I set the defragger to work on it.
> After about 36 hours of continuous defragging, it had made very little
> progress, so I thought that a quicker approach would be to delete the
> backup file completely and run the backup programme. This would give a
> fresh backup file which I expected to be unfragmented.
>
> Not a bit of it. The fresh backup file was as fragmented as before.
>
> My questions are: is this typical of backup files in general or just
> those created by the MS backup utility? Is there a good reason for it
> and would defragging them damage them in some way? In any case,
> attempting to defrag them would seem a rather protracted exercise!
>
> --
>
> Chris
>
> E-mail: christopher[dot]hogg[at]virgin[dot]net
Hi. I suspect not many use the MS backup; and those who do won't be much
help here.
I'm interested in this problem because I regularly backup my hard drive
with Paragon HD Manager (free). It works just fine; and every now and
again I put the latest archive onto a HD through USB, and store that for
when needed. (Either pick off individual folders and files, or a
complete HD replacement)
So, it's of more than just academic interest, so I'll go with it. If not
solved it may just be the tip of an iceberg, and grow more threatening.
36 hours displays a man after my own heart; stoical and persevering.
What we need here is analysis data. First suggestion; what does Windows
say when you ask for defrag analysis of the drive?
Ed
date: Sun, 23 Aug 2009 13:22:13 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Sun, 23 Aug 2009 13:22:13 +0100, "Ed Cryer"
wrote:
>Hi. I suspect not many use the MS backup; and those who do won't be much
>help here.
>I'm interested in this problem because I regularly backup my hard drive
>with Paragon HD Manager (free). It works just fine; and every now and
>again I put the latest archive onto a HD through USB, and store that for
>when needed. (Either pick off individual folders and files, or a
>complete HD replacement)
>
>So, it's of more than just academic interest, so I'll go with it. If not
>solved it may just be the tip of an iceberg, and grow more threatening.
>
>36 hours displays a man after my own heart; stoical and persevering.
>What we need here is analysis data. First suggestion; what does Windows
>say when you ask for defrag analysis of the drive?
>
>Ed
>
Hi Ed, thanks for the interest.
Analysis of the drive using C:\WINDOWS\system32\dfrg.msc, which I
assume is what you're suggesting I use, is as follows (but I confess
it doesn't mean a great deal to me):
Volume Local Disk (G:)
Volume size = 149 GB
Cluster size = 4 KB
Used space = 49.00 GB
Free space = 100 GB
Percent free space = 67 %
Volume fragmentation
Total fragmentation = 49 %
File fragmentation = 99 %
Free space fragmentation = 0 %
File fragmentation
Total files = 20
Average file size = 4.63 GB
Total fragmented files = 1
Total excess fragments = 283,868
Average fragments per file = 14194.40
Pagefile fragmentation
Pagefile size = 0 bytes
Total fragments = 0
Folder fragmentation
Total folders = 9
Fragmented folders = 1
Excess folder fragments = 0
Master File Table (MFT) fragmentation
Total MFT size = 8 MB
MFT record count = 4,882
Percent MFT in use = 59 %
Total MFT fragments = 3
--------------------------------------------------------------------------------
Fragments File Size Most fragmented files
283,869 55.62 GB \BackupCD.bkf
There are a few other files on the disk as well as the backup file,
which appear unfragmented, but their inclusion in some of the averages
above distorts the numbers a little, in particular the average file
size and average fragments per file. I guess the key point would seem
to be that the backup file itself contains 283,862 fragments, in a
file of 55.62Gb size.
Thinking about it a bit, I've just looked at the report file that the
MS backup programme generates, and it says it backed up a total of
142396 files. That's very close to half the number of fragments, too
close for it to be a coincidence IMO, so I guess all these fragments
must be something to do with the way MS backup works. Trying to defrag
them is probably very much the wrong thing to do!
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Sun, 23 Aug 2009 21:37:54 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:b18395113nq4r1idhrpsopufpatgvt6mq8@4ax.com...
> On Sun, 23 Aug 2009 13:22:13 +0100, "Ed Cryer"
> wrote:
>
>>Hi. I suspect not many use the MS backup; and those who do won't be
>>much
>>help here.
>>I'm interested in this problem because I regularly backup my hard
>>drive
>>with Paragon HD Manager (free). It works just fine; and every now and
>>again I put the latest archive onto a HD through USB, and store that
>>for
>>when needed. (Either pick off individual folders and files, or a
>>complete HD replacement)
>>
>>So, it's of more than just academic interest, so I'll go with it. If
>>not
>>solved it may just be the tip of an iceberg, and grow more
>>threatening.
>>
>>36 hours displays a man after my own heart; stoical and persevering.
>>What we need here is analysis data. First suggestion; what does
>>Windows
>>say when you ask for defrag analysis of the drive?
>>
>>Ed
>>
> Hi Ed, thanks for the interest.
>
> Analysis of the drive using C:\WINDOWS\system32\dfrg.msc, which I
> assume is what you're suggesting I use, is as follows (but I confess
> it doesn't mean a great deal to me):
>
> Volume Local Disk (G:)
> Volume size = 149 GB
> Cluster size = 4 KB
> Used space = 49.00 GB
> Free space = 100 GB
> Percent free space = 67 %
>
> Volume fragmentation
> Total fragmentation = 49 %
> File fragmentation = 99 %
> Free space fragmentation = 0 %
>
> File fragmentation
> Total files = 20
> Average file size = 4.63 GB
> Total fragmented files = 1
> Total excess fragments = 283,868
> Average fragments per file = 14194.40
>
> Pagefile fragmentation
> Pagefile size = 0 bytes
> Total fragments = 0
>
> Folder fragmentation
> Total folders = 9
> Fragmented folders = 1
> Excess folder fragments = 0
>
> Master File Table (MFT) fragmentation
> Total MFT size = 8 MB
> MFT record count = 4,882
> Percent MFT in use = 59 %
> Total MFT fragments = 3
>
> --------------------------------------------------------------------------------
> Fragments File Size Most fragmented files
> 283,869 55.62 GB \BackupCD.bkf
>
>
>
> There are a few other files on the disk as well as the backup file,
> which appear unfragmented, but their inclusion in some of the averages
> above distorts the numbers a little, in particular the average file
> size and average fragments per file. I guess the key point would seem
> to be that the backup file itself contains 283,862 fragments, in a
> file of 55.62Gb size.
>
> Thinking about it a bit, I've just looked at the report file that the
> MS backup programme generates, and it says it backed up a total of
> 142396 files. That's very close to half the number of fragments, too
> close for it to be a coincidence IMO, so I guess all these fragments
> must be something to do with the way MS backup works. Trying to defrag
> them is probably very much the wrong thing to do!
>
> --
>
Files and indexes.
The index for a file contains the absolute addresses of cylinders &
sectors. If a file is all of one piece then there will be one entry.
Fragmented files have several. When the defragging program prepares its
report it reads those indexes.
Now, one of two things. The file either is genuinely fragmented in the
above sense; or it is structured on a basis quite personal to the MS
Backup prog itself and the defrag prog is misconstruing its structure.
I've got a defrag report of the HD with my Paragon backup archive on it
(16GB size), and it says "17 fragments".
On your drive it is just that backup file with large fragments. The MFT
is fine.
I think there's absolutely no cause for alarm.
Do two checks;
1. Check the volume for errors; leave last two options unticked.
2. Another program that will read it sequentially following indexes; AV
prog will do fine.
Time both runs and let us know.
Ed
date: Sun, 23 Aug 2009 23:24:21 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Sun, 23 Aug 2009 23:24:21 +0100, "Ed Cryer"
wrote:
>
>Files and indexes.
>The index for a file contains the absolute addresses of cylinders &
>sectors. If a file is all of one piece then there will be one entry.
>Fragmented files have several. When the defragging program prepares its
>report it reads those indexes.
>
>Now, one of two things. The file either is genuinely fragmented in the
>above sense; or it is structured on a basis quite personal to the MS
>Backup prog itself and the defrag prog is misconstruing its structure.
>
>I've got a defrag report of the HD with my Paragon backup archive on it
>(16GB size), and it says "17 fragments".
>
>On your drive it is just that backup file with large fragments. The MFT
>is fine.
>I think there's absolutely no cause for alarm.
>Do two checks;
>1. Check the volume for errors; leave last two options unticked.
Not sure if this is what you meant, but I did:
my computer > select local drive G > properties > tools > error
checking > check local disk G > start
Phase 1 took 6 seconds; phase 2, 22 seconds; phase 3, 4 seconds,
making a total time of 32 seconds.
>2. Another program that will read it sequentially following indexes; AV
>prog will do fine.
>Time both runs and let us know.
My AV prog is Kaspersky. A scan of drive G took about one second or
less.
Bearing in mind the drive is ~150Gb, with ~50Gb used, both those times
seem rather quick to me. I have a recollection from many years ago,
running CHKDSK, of it clunking along and taking an hour or two to
check a disk. OK, so computers are much faster now than they were, but
disks are also much bigger. Have I misunderstood what you were
suggesting I do? I'm no expert when it comes to the basics of
computers!
The MS backup programme allows incremental and differential backups in
addition to normal backups, which means that any files that have been
altered since the last backup get appended to the existing backup
file, which considerably shortens the time taken to do the backup. I
wonder if the fragmented structure of the backup file is to allow this
to happen.
Incidentally, I do have the Paragon HD manager somewhere on my machine
but don't actually use it.
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Mon, 24 Aug 2009 18:01:19 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:d7g59518unaoujh7rvra09vlkh4r1vikjd@4ax.com...
> On Sun, 23 Aug 2009 23:24:21 +0100, "Ed Cryer"
> wrote:
>
>
>>
>>Files and indexes.
>>The index for a file contains the absolute addresses of cylinders &
>>sectors. If a file is all of one piece then there will be one entry.
>>Fragmented files have several. When the defragging program prepares
>>its
>>report it reads those indexes.
>>
>>Now, one of two things. The file either is genuinely fragmented in the
>>above sense; or it is structured on a basis quite personal to the MS
>>Backup prog itself and the defrag prog is misconstruing its structure.
>>
>>I've got a defrag report of the HD with my Paragon backup archive on
>>it
>>(16GB size), and it says "17 fragments".
>>
>>On your drive it is just that backup file with large fragments. The
>>MFT
>>is fine.
>>I think there's absolutely no cause for alarm.
>>Do two checks;
>>1. Check the volume for errors; leave last two options unticked.
>
> Not sure if this is what you meant, but I did:
>
> my computer > select local drive G > properties > tools > error
> checking > check local disk G > start
> Phase 1 took 6 seconds; phase 2, 22 seconds; phase 3, 4 seconds,
> making a total time of 32 seconds.
>
>>2. Another program that will read it sequentially following indexes;
>>AV
>>prog will do fine.
>>Time both runs and let us know.
>
> My AV prog is Kaspersky. A scan of drive G took about one second or
> less.
>
> Bearing in mind the drive is ~150Gb, with ~50Gb used, both those times
> seem rather quick to me. I have a recollection from many years ago,
> running CHKDSK, of it clunking along and taking an hour or two to
> check a disk. OK, so computers are much faster now than they were, but
> disks are also much bigger. Have I misunderstood what you were
> suggesting I do? I'm no expert when it comes to the basics of
> computers!
>
> The MS backup programme allows incremental and differential backups in
> addition to normal backups, which means that any files that have been
> altered since the last backup get appended to the existing backup
> file, which considerably shortens the time taken to do the backup. I
> wonder if the fragmented structure of the backup file is to allow this
> to happen.
>
> Incidentally, I do have the Paragon HD manager somewhere on my machine
> but don't actually use it.
>
> --
>
That all looks A1 perfect to me. The drive file structure is good; the
file structure of the large backup is ok for third-party software (seen
as one single file); and, last but not least, the backup prog (which is
the only one that will use that large file) is working fine.
If the only thing bugging you is the reported fragmentation of that
backup, then dismiss it.
It has caused a bit trouble by enticing you in to try and defrag the
drive (which seems a bit naughty of MS who should have catered for that
circumstance).
If I were in your shoes I'd drop MS an email (better than phoning their
0870 number).
http://support.microsoft.com/contactus/?ws=support
(Type in "Backup" and then same again at next screen followed by "yes"
to get the email screen)
Ed
date: Mon, 24 Aug 2009 19:56:25 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Mon, 24 Aug 2009 19:56:25 +0100, "Ed Cryer"
wrote:
>>
>
>That all looks A1 perfect to me. The drive file structure is good; the
>file structure of the large backup is ok for third-party software (seen
>as one single file); and, last but not least, the backup prog (which is
>the only one that will use that large file) is working fine.
>
>If the only thing bugging you is the reported fragmentation of that
>backup, then dismiss it.
>It has caused a bit trouble by enticing you in to try and defrag the
>drive (which seems a bit naughty of MS who should have catered for that
>circumstance).
>If I were in your shoes I'd drop MS an email (better than phoning their
>0870 number).
>http://support.microsoft.com/contactus/?ws=support
>(Type in "Backup" and then same again at next screen followed by "yes"
>to get the email screen)
>
>
>Ed
I might just do that. Thanks for your help Ed.
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Mon, 24 Aug 2009 20:10:30 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:tbp595p3ta680g7mtqeqqi75tjoa2c67pl@4ax.com...
> On Mon, 24 Aug 2009 19:56:25 +0100, "Ed Cryer"
> wrote:
>
>
>>>
>>
>>That all looks A1 perfect to me. The drive file structure is good; the
>>file structure of the large backup is ok for third-party software
>>(seen
>>as one single file); and, last but not least, the backup prog (which
>>is
>>the only one that will use that large file) is working fine.
>>
>>If the only thing bugging you is the reported fragmentation of that
>>backup, then dismiss it.
>>It has caused a bit trouble by enticing you in to try and defrag the
>>drive (which seems a bit naughty of MS who should have catered for
>>that
>>circumstance).
>>If I were in your shoes I'd drop MS an email (better than phoning
>>their
>>0870 number).
>>http://support.microsoft.com/contactus/?ws=support
>>(Type in "Backup" and then same again at next screen followed by "yes"
>>to get the email screen)
>>
>>
>>Ed
>
>
> I might just do that. Thanks for your help Ed.
>
> --
>
Have a look here;
http://tinyurl.com/nhg3ox
and yes, it also applies to NTbackup (put that in the Find box).
Ed
date: Mon, 24 Aug 2009 22:21:59 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Mon, 24 Aug 2009 22:21:59 +0100, "Ed Cryer"
>Have a look here;
>http://tinyurl.com/nhg3ox
>and yes, it also applies to NTbackup (put that in the Find box).
>
>Ed
Thanks Ed. Very interesting. Time to contact Microsoft, I think.
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Tue, 25 Aug 2009 18:06:14 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:7528959sfrufrm2u64gr27jbv9g65vqb11@4ax.com...
> On Mon, 24 Aug 2009 22:21:59 +0100, "Ed Cryer"
>>Have a look here;
>>http://tinyurl.com/nhg3ox
>>and yes, it also applies to NTbackup (put that in the Find box).
>>
>>Ed
>
> Thanks Ed. Very interesting. Time to contact Microsoft, I think.
>
> --
>
I thought I'd give NTbackup a spin just out of interest.
Volume C, 150 GB with only 18GB used. I regularly back this up to an
external HD (Volume H, 250 GB) with Paragon HD Manager. So I used the
same drive for the backup, after first defagging it.
NTbackup took 4 times as long as Paragon does; output file about 1GB
larger.
Then I looked at the file expecting hideous fragmentation, but no!
15.64 GB with 134 fragments.
Ed
---------------------------
---------------------------
Volume USB250 (H:)
Volume size = 233 GB
Cluster size = 4 KB
Used space = 91.47 GB
Free space = 141 GB
Percent free space = 60 %
Volume fragmentation
Total fragmentation = 8 %
File fragmentation = 17 %
Free space fragmentation = 0 %
File fragmentation
Total files = 14,097
Average file size = 7 MB
Total fragmented files = 1
Total excess fragments = 133
Average fragments per file = 1.00
Pagefile fragmentation
Pagefile size = 0 bytes
Total fragments = 0
Folder fragmentation
Total folders = 1,015
Fragmented folders = 1
Excess folder fragments = 0
Master File Table (MFT) fragmentation
Total MFT size = 18 MB
MFT record count = 15,129
Percent MFT in use = 80 %
Total MFT fragments = 2
--------------------------------------------------------------------------------
Fragments File Size Most fragmented files
134 15.64 GB \NTbackupfile.bkf
date: Wed, 26 Aug 2009 17:53:19 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Wed, 26 Aug 2009 17:53:19 +0100, "Ed Cryer"
wrote:
>
>"Chris Hogg" wrote in message
>news:7528959sfrufrm2u64gr27jbv9g65vqb11@4ax.com...
>> On Mon, 24 Aug 2009 22:21:59 +0100, "Ed Cryer"
>>>Have a look here;
>>>http://tinyurl.com/nhg3ox
>>>and yes, it also applies to NTbackup (put that in the Find box).
>>>
>>>Ed
>>
>> Thanks Ed. Very interesting. Time to contact Microsoft, I think.
>>
>> --
>>
>
>I thought I'd give NTbackup a spin just out of interest.
>Volume C, 150 GB with only 18GB used. I regularly back this up to an
>external HD (Volume H, 250 GB) with Paragon HD Manager. So I used the
>same drive for the backup, after first defagging it.
>
>NTbackup took 4 times as long as Paragon does; output file about 1GB
>larger.
>Then I looked at the file expecting hideous fragmentation, but no!
>15.64 GB with 134 fragments.
>
>Ed
>---------------------------
>---------------------------
>
>
>
>Volume USB250 (H:)
> Volume size = 233 GB
> Cluster size = 4 KB
> Used space = 91.47 GB
> Free space = 141 GB
> Percent free space = 60 %
>
>Volume fragmentation
> Total fragmentation = 8 %
> File fragmentation = 17 %
> Free space fragmentation = 0 %
>
>File fragmentation
> Total files = 14,097
> Average file size = 7 MB
> Total fragmented files = 1
> Total excess fragments = 133
> Average fragments per file = 1.00
>
>Pagefile fragmentation
> Pagefile size = 0 bytes
> Total fragments = 0
>
>Folder fragmentation
> Total folders = 1,015
> Fragmented folders = 1
> Excess folder fragments = 0
>
>Master File Table (MFT) fragmentation
> Total MFT size = 18 MB
> MFT record count = 15,129
> Percent MFT in use = 80 %
> Total MFT fragments = 2
>
>--------------------------------------------------------------------------------
>Fragments File Size Most fragmented files
>134 15.64 GB \NTbackupfile.bkf
Now I am confused! Why should it behave reasonably well for you, but
not for me? (I don't expect an answer, but if you've got one, I'd like
to hear it).
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Wed, 26 Aug 2009 19:49:43 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:4mta951c407ig8h17llg3d8d3virql4uq0@4ax.com...
>>Fragments File Size Most fragmented files
>>134 15.64 GB \NTbackupfile.bkf
>
> Now I am confused! Why should it behave reasonably well for you, but
> not for me? (I don't expect an answer, but if you've got one, I'd like
> to hear it).
>
> --
I'm on version 5.1.2600.
Windows/ System32/ntbackup.exe
What are you on?
Ed
date: Wed, 26 Aug 2009 21:29:22 +0100
author: Ed Cryer
|
Re: Backup file fragmentation
On Wed, 26 Aug 2009 21:29:22 +0100, "Ed Cryer"
wrote:
>
>"Chris Hogg" wrote in message
>news:4mta951c407ig8h17llg3d8d3virql4uq0@4ax.com...
>
>>>Fragments File Size Most fragmented files
>>>134 15.64 GB \NTbackupfile.bkf
>>
>> Now I am confused! Why should it behave reasonably well for you, but
>> not for me? (I don't expect an answer, but if you've got one, I'd like
>> to hear it).
>>
>> --
>
>I'm on version 5.1.2600.
>Windows/ System32/ntbackup.exe
>
>What are you on?
>
>Ed
>
Ah, good question. It's version 5.1.2505.0 so perhaps they've fixed it
now. IIRC I downloaded it from somewhere as I don't have a set of
Windows discs (the computer came with Windows pre-installed). I'll go
and see if I can find a copy.
Failing that, I have two options: either I just live with it, as I
only do a differential backup monthly and a full backup about every
six months (it's not as if I run a business or whatever, backing up
every day), or I try the Paragon backup facility as you use.
I contacted MS, but their 'help' was very broad-brush, directing me to
a forest of articles that just might possibly be relevant. It would
take some time to plough through them all.
I assume your disc is formatted NTFS, as the link you gave me to the
Symantec/Veritas problems seemed to indicate that the way Windows was
writing blocks to the NTFS disc was at least a factor in that case, so
possibly with mine also.
--
Chris
E-mail: christopher[dot]hogg[at]virgin[dot]net
date: Thu, 27 Aug 2009 07:33:05 +0100
author: Chris Hogg
|
Re: Backup file fragmentation
"Chris Hogg" wrote in message
news:v99c95pvllnad78e2258savu6g5mr3gcmi@4ax.com...
> On Wed, 26 Aug 2009 21:29:22 +0100, "Ed Cryer"
> wrote:
>
>>
>>"Chris Hogg" wrote in message
>>news:4mta951c407ig8h17llg3d8d3virql4uq0@4ax.com...
>>
>>>>Fragments File Size Most fragmented files
>>>>134 15.64 GB \NTbackupfile.bkf
>>>
>>> Now I am confused! Why should it behave reasonably well for you, but
>>> not for me? (I don't expect an answer, but if you've got one, I'd
>>> like
>>> to hear it).
>>>
>>> --
>>
>
>>I'm on version 5.1.2600.
>>Windows/ System32/ntbackup.exe
>>
>>What are you on?
>>
>>Ed
>>
> Ah, good question. It's version 5.1.2505.0 so perhaps they've fixed it
> now. IIRC I downloaded it from somewhere as I don't have a set of
> Windows discs (the computer came with Windows pre-installed). I'll go
> and see if I can find a copy.
>
> Failing that, I have two options: either I just live with it, as I
> only do a differential backup monthly and a full backup about every
> six months (it's not as if I run a business or whatever, backing up
> every day), or I try the Paragon backup facility as you use.
>
> I contacted MS, but their 'help' was very broad-brush, directing me to
> a forest of articles that just might possibly be relevant. It would
> take some time to plough through them all.
>
> I assume your disc is formatted NTFS, as the link you gave me to the
> Symantec/Veritas problems seemed to indicate that the way Windows was
> writing blocks to the NTFS disc was at least a factor in that case, so
> possibly with mine also.
>
> --
>
Yes. Both discs involved are formatted NTFS. I always format NTFS.
Screenshot;
http://tinyurl.com/nvenc4
My NTbackup.exe has a creation date of August 2001 and is 1.08 MB in
size.
Only one thing I can pinpoint here is that I don't use incremental
backup with the thing. In fact that run was the first time I've used it.
Could there be something here affected by you doing the regular
incremental runs?
I'll gladly let you have a copy of my version. I don't want to put it on
my website as that might lead to criminal proceedings against me in the
current climate of gov. warfare against illegal file-sharing. But if you
tell us your addy in this kind of format
(ed@cryerdotwanadoodotBritishdotIsles)
I'll decrypt it manually and mail it there.
Ed
date: Thu, 27 Aug 2009 15:15:14 +0100
author: Ed Cryer
|
|
|