I have (or at least, I think I have) an adequate backup setup on my computer. Data does not get get added/updated all that frequently, and there is no data that would be life-altering if I lost it. Inconvenient, yes, but if (for example) I lost all my music, I have the original CDs. There are pictures I wouldn't like to lose, but if I did, well, life would go on. With that said, I probably do my backups about once a month.

My C: and D: drives are my Windows and data drives, respectively. I back up to my E: drive, and also to an external USB drive at G:. My music, in addition to being on my D:, E:, and G: drives, is also on my empeg, so with four complete copies I feel reasonably safe. (Yes, Paul G. no doubt has his music on at least six different empegs as well as his system backups , but I know my limitations!)

So, I ran my backups last night, and then started doing file size comparisons, source to backup. There seem to be discrepancies.

If I right-click the C: drive and select properties for the whole drive(where I get the pretty little blue and pink pie chart) it shows a considerably different amount of used space than if I use Windows Explorer and highlight all the directories and show properties there. The D: drive does the same thing, but to a much lesser extent.

When I look at the used space on the backup files, I get more discrepancies yet, with the backup files only taking about 2/3 the space of the source files on the C: drive, and about 90% of the space of the source files on the D: drive.

There are even small differences comparing the E: backups to the G: backups, and they should be identical. Shouldn't they?

I know that some of the discrepancies are related to files in use in the Windows directory that can't back up. But nearly six gigabytes difference? (see table below) Doesn't seem likely. And why would there be a difference of more nearly nine gigabytes in C: space used when looking at the "whole drive" (with the pie chart) and the files on the drive?

When I ran the backups, all recycle bins were empty, compression was not turned on for any drive, and backup filtering was set to *.* (backup all files) with no directories or files excluded.

....................TABLE OF USED SPACE...................
.
Whole Drive.......Files on Drive......E: Backup#1.....G: Backup#2
==============================================================
C: 37.766 GB.....C: 28.912 GB.....E: 24.139 GB...G: 24.182 GB
D:158.302 GB....D:158.071 GB....E:158.055 GB...G:158.950 GB


Oh, Doh! A bit of super-sophisticated highly technical sleuthing on my part (I compared the file lists of source drive to the backup drive) shows two very large files on the source drive that are not on the backup drive: hiberfil.sys, and pagefile.sys. Hiberfil.sys I can safely get rid of. Pagefile.sys I think I'll keep. Uncle Google says I can kill it if I really need the space as long as I have lots of RAM, but with "just" 2 GB RAM (I remember how excited I was when I spent $400 to upgrade my old 386 computer to four MB of RAM!) I'll leave it be. I was mostly just interested in why my backups were so much smaller than my source, and that explains a lot of it.

I'm still confused about why my "whole drive" used space is so much more than my "files on drive" used space, though.

tanstaafl.

That might be the difference in the actual size of the files vs. the minimum allocation of filespace allowed by the formatting of the drive.

Edit: Reads more like I intended.

Absolute minimum space allocation might be in 512 byte blocks. But it depends mostly on how the drive is formatted.

Newbie. I remember when I upgraded to 640kB.

To expand on gbeer's explanation, Windows stores files by putting them in blocks. If a file is not an even number of blocks, it rounds up its allocation so that it uses an even number anyway. This is the difference between the "Size" and "Size on disk" numbers in the Properties panel of a file.

Also known as slack space.

Hiberfil.sys is what the system uses to store the active memory when it goes into hibernate mode. Pagefile.sys is the operating system's memory swap file. You *never* need to back those up.

If those files exist on a disk drive that isn't actually hosting those files for an active operating system (for example, your live operating system is on C: and your backup drive is D:, and you're seeing those files on D and you didn't specifically tell the OS to put them there), then they can be safely deleted.

Regarding file size discrepancy: As was stated elsewhere, the size of the allocation units on each disk drive is a factor. Imagine a disk drive as a large grid of allocation units. Each grid might be 512 bytes each, or 1024 bytes each, or 4096 bytes each, etc., depending on the size of the drive, the filesystem, and how it's formatted. A file fills up a bunch of allocation units and then the remainder (if the file doesn't fill that last grid completely) is wasted space. See Cluster.

Beyond the swap space and hibernate file, Windows will by default be taking a bit of space for System Restore.

And I remember the PDP-11 "Split ID" mode, with separate data and program memory spaces. Wow - 64 + 64 KB!

Probably not an issue in your case, but another reason may be that Windows won't show you the space taken up by files you don't have permission to see. (or at least directories, perhaps it will for files). It'll still report it under the disk usage if you look at a disks properties, it just won't show it to you if you look at a directories properties.

At least du (the unix equivalent) warns you when it can't descend into a directory to see how big it is.

Matthew

Pah. I remember when I upgraded my ZX81 (Timex Sinclair 1000) from 1KB to 16KB...

16KB? 16KB!! We used to dream about 16KB, when I were a lad...



pca

"...and we programmed in ones and in zeroes, and sometimes we ran out of ones."



tanstaafl.

edit: Add linky

Must have been nice to be spoiled with all that choice. I could only ever dream of that level of sophistication.

This was my first computer. I had the additional 1k, making a total to 2k.

I had to build my own parallel printer port and hand assemble the machine code to make it run.

Well, my first computer had 256B of main RAM (though there was other memory available). 15 Flooz (or equivalent) to whoever can guess what that was.