.BKF file is nearly twice the size of backed-up data

[R. Steven Kadish]

Hi all,

I just performed an ASR backup of my computer using NTBackup.ese and I have
a strange problem that I haven't encountered before. According to Windows
Explorer, there is 77 GB of data on my C: drive. However, the .bkf file
created by the backup is 151 GB - almost twice the size. Now my external
drive is full and I can't do any more backups!

I've extensively explored my hard drive, including looking at System and
Hidden files, but I am unable to explain this discrepency. Does anyone know
what happened?

Thanks,
- Steve

 

[Allan]

Hi all,

I just performed an ASR backup of my computer using NTBackup.ese and I
have
a strange problem that I haven't encountered before. According to Windows
Explorer, there is 77 GB of data on my C: drive. However, the .bkf file
created by the backup is 151 GB - almost twice the size. Now my external
drive is full and I can't do any more backups!

I've extensively explored my hard drive, including looking at System and
Hidden files, but I am unable to explain this discrepency. Does anyone
know
what happened?

It may be an error in NTBackup; the next time you run the backup it may not
be so large. The backup should compress the data so it takes up less space
than before, not more than the original uncompressed data.

 

[Big Al]

Hi all,

I just performed an ASR backup of my computer using NTBackup.ese and I have
a strange problem that I haven't encountered before. According to Windows
Explorer, there is 77 GB of data on my C: drive. However, the .bkf file
created by the backup is 151 GB - almost twice the size. Now my external
drive is full and I can't do any more backups!

I've extensively explored my hard drive, including looking at System and
Hidden files, but I am unable to explain this discrepency. Does anyone know
what happened?

Thanks,
- Steve

I know that zipping a zip file makes it larger because you can't
compress the data but you still need the zip overhead data and directory
info. Thus its larger. But 1% maybe 2% larger. Not 100%.
If you created the backup on the same drive that you are backing up, it
might be that the back is in the backup too.

 

[R. Steven Kadish]

Hi Allan,

Thanks, but I've done it three times with the same results. Also, I don't
believe that NTBackup compresses the data, especially with an ASR backup
where it uses the Volume Shadow Copy service.

Thanks,
- Steve

 

[R. Steven Kadish]

Hi Al,

Thanks, I am backing my data up onto an external drive, not on to the same
drive. (What would be the point of backing up onto the same drive?) I'm not
sure what you are getting at when you talking about "Zipping a ZIP file;"
there's no WinZIP or any other compression untility involved in this process.

Thanks,
- Steve

 

[Pegasus \(MVP\)]

Hi all,

I just performed an ASR backup of my computer using NTBackup.ese and I
have
a strange problem that I haven't encountered before. According to Windows
Explorer, there is 77 GB of data on my C: drive. However, the .bkf file
created by the backup is 151 GB - almost twice the size. Now my external
drive is full and I can't do any more backups!

I've extensively explored my hard drive, including looking at System and
Hidden files, but I am unable to explain this discrepency. Does anyone
know
what happened?

Thanks,
- Steve

You are correct: ntbackup.exe does NOT compress files. While
the command does have a switch to compress data, that switch
is only a directive to the backup device (usually a tape drive) to
perform hardware compression. And while the zip argument
mentioned by Big Al is correct, it is irrelevant in your context.
Furthermore, it would add only a tiny amount to the overall size
of the file.

I am uncomfortable with your statement "According to Windows
Explorer, there is 77 GB of data on my C: drive." Your first step
should be to verify this figure. You can do it like so:

Click Start / Run / diskmgmt.msc{OK}, then check both the
capacity and the amount of free space on drive C:. Subtract
one from the other. Does it give you around 77 GBytes?

 

[R. Steven Kadish]

Hi Pegasus,

Thanks; I verified using Disk Management as you suggested.

Capacity = 149.04 GB, Free Space = 76.98 GB, for a usage of 72.06 GB.
Percent Free is at 51%.

Thanks,
- Steve

 

[Pegasus \(MVP\)]

I suspect you used the "append" option in your backup job,
causing the new backup to be added to the previous backup.

 

[R. Steven Kadish]

Hi Pegasus,

No, I'm afraid it's not that simple. I am not using "append."

First of all, this was an ASR backup, and every time I do an ASR backup I
give the backup file a unique name. Secondly, after experiencing the
problem, I deleted the .BKF file and tried again; same result. Then I
re-formatted the backup media and tried a third time with the same result.
So you see, there was nothing to append to.

Thanks,
- Steve

 

[Pegasus \(MVP\)]

When problems appear unsolveable, one needs to break them
up into small components and deal with one component at a
time.

In your case this means that you should back up individual folders
(e.g. c:\Windows, c:\Program Files, c:\Documents and Settings),
one at a time, and compare the reported folder size with the size
of the backup file.

To see the names of all root folders on drive C:, including the
hidden ones, do this:
- Click Start / Run / cmd{OK}
- Type this command:
dir c:\ /ad {Enter}

 

[Big Al]

Hi Al,

Thanks, I am backing my data up onto an external drive, not on to the same
drive. (What would be the point of backing up onto the same drive?) I'm not
sure what you are getting at when you talking about "Zipping a ZIP file;"
there's no WinZIP or any other compression untility involved in this process.

Thanks,
- Steve

It was just a point of reference. People used to think they could zip
files to save space, then zip the zip file to save more space. But all
that does is make it bigger by 1-2%. It does not apply but I just
tossed it in. Probably should not have.

By the way, I WAS able to do a drive clone with Acronis to the same
drive. I think it took a inventory of the drive and then built just
what it saw, excluding the new 30 gig clone file it was going to create.

 

[Allan]

Hi Allan,

Thanks, but I've done it three times with the same results. Also, I don't
believe that NTBackup compresses the data, especially with an ASR backup
where it uses the Volume Shadow Copy service.

Have you checked the external USB drive using CHKDSK for errors? Is there a
log file created for the full system backup?
Try backing up a small file as a test to compare your results. You could
also try using a different external drive if you can borrow one from
someone.

 

[R. Steven Kadish]

Hi all,

So - I found out what is going on here.

I have an old version of PGP Desktop installed (version 9) and I recently
created an encrypted volume to hold sensitive files. The volume mounts as a
folder inside My Documents (it's called "Private.") When the volume is
dismounted, "Private" appears to Explorer as an empty folder.

The volume was dismounted when I did the backup. On a hunch, I took a look
at the folder in the backup catalog. Nested inside "Private" was - strange!
- my entire C: drive folder structure, backed up a second time!

I guess my next posting will be to the PGP forums!

Thanks,
- Steve

 

[Pegasus \(MVP\)]

Hi all,

So - I found out what is going on here.

I have an old version of PGP Desktop installed (version 9) and I recently
created an encrypted volume to hold sensitive files. The volume mounts as
a
folder inside My Documents (it's called "Private.") When the volume is
dismounted, "Private" appears to Explorer as an empty folder.

The volume was dismounted when I did the backup. On a hunch, I took a
look
at the folder in the backup catalog. Nested inside "Private" was -
strange!
- my entire C: drive folder structure, backed up a second time!

I guess my next posting will be to the PGP forums!

Thanks,
- Steve


:

Thanks for the feedback.

I suspect that you might have received some pointers if you had
adopted my suggestion of backing up just a single folder. The
size of your backup file would then have been the size of drive C:
plus a small number, which would have rung alarm bells all over
the place.