G
Guest
When using XP-Backup doing a complete C:/ backup to an external hard disk, make sure the external hard drive is formatted in NTFS and not FAT32 before starting as the file size limit of FAT32 is 4GB
J
Jim
That's good advice. Here's some more.
If you're using FAT32 volumes as a result of an upgrade to
XP from a prior MS operating system (as am I) then you
might consider using a backup utility that will allow you
to break up the backup file into smaller files, such as
670MB for CD burning. The Windows Backup utility doesn't
support this. In fact, the Windows Backup program will run
for a couple of hours until it hits the 4GB limit before
complaining. This is silly - it knew the destination
volume was FAT32, and the approximate size of the backup
file. It should've displayed a warning that the backup
file would probably be too large BEFORE it started.
In fact, I personally recommend against using ANY backup
utility that runs under Windows, since there are far too
many system files in use that won't get backed up. Also,
since the system is constantly changing while Windows is
running, these tools backup by file rather than imaging
the drive, which is painfully slow.
Try a DOS mode backup utility like Norton Ghost or
Powerquest DriveImage. The only downside with these
utilities is that you can't backup to any medium which
isn't visible from your BIOS, or which you don't have DOS
mode drivers for. This includes USB and Firewire drives.
It also includes network drives, unless you have DOS mode
drivers for your NIC.
Finally, NEVER store your backups on an alternate
partition of your boot drive. If the drive crashes then
you lose both the operating system installation AND the
backups. However, you CAN use an alternate partition as a
temporary holding place for your backup files until you
can write them to tape, burn them to CD, or copy them to a
network server.
Jim
formatted in NTFS and not FAT32 before starting as the
file size limit of FAT32 is 4GB.
If you're using FAT32 volumes as a result of an upgrade to
XP from a prior MS operating system (as am I) then you
might consider using a backup utility that will allow you
to break up the backup file into smaller files, such as
670MB for CD burning. The Windows Backup utility doesn't
support this. In fact, the Windows Backup program will run
for a couple of hours until it hits the 4GB limit before
complaining. This is silly - it knew the destination
volume was FAT32, and the approximate size of the backup
file. It should've displayed a warning that the backup
file would probably be too large BEFORE it started.
In fact, I personally recommend against using ANY backup
utility that runs under Windows, since there are far too
many system files in use that won't get backed up. Also,
since the system is constantly changing while Windows is
running, these tools backup by file rather than imaging
the drive, which is painfully slow.
Try a DOS mode backup utility like Norton Ghost or
Powerquest DriveImage. The only downside with these
utilities is that you can't backup to any medium which
isn't visible from your BIOS, or which you don't have DOS
mode drivers for. This includes USB and Firewire drives.
It also includes network drives, unless you have DOS mode
drivers for your NIC.
Finally, NEVER store your backups on an alternate
partition of your boot drive. If the drive crashes then
you lose both the operating system installation AND the
backups. However, you CAN use an alternate partition as a
temporary holding place for your backup files until you
can write them to tape, burn them to CD, or copy them to a
network server.
Jim
external hard disk, make sure the external hard drive is
formatted in NTFS and not FAT32 before starting as the
file size limit of FAT32 is 4GB.
C
cquirke (MVP Win9x)
On Sat, 21 Feb 2004 09:49:44 -0800, "Jim"
Yes, I see value in local HD backups for this reason.
I don't usually attempt "full system backup" outside very particular
circumstances, such as before resizing partitions etc. Usually those
circumstances are such that a backup is automatically created, e.g.
keeping the old HD when imaging to a new one, etc.
Few circumstances "fit" a simple restore of a "full system backup".
If a PC is stolen, or core parts break, then the replacement hardware
may not run the restored backup, and a malware payload situation means
the malware will likely be present (in active but latent form).
Because these "full system backups" are typically partition images,
they aren't as browsable as file-level backups should you need to pick
out a few files; OTOH a file-level backup generally won't yeild a
working installation when restored even if no files are missing.
So I do a full data backup instead. This gets automated daily via
Tasks to another volume on the local HD, where the last 5 backups are
kept. The most recent of these is then pulled (again, via unattended
Task) to another PC over the LAN, and from there the collected LAN's
data backups can be "last miled" to CDRW.
This means if all but the backup system is stolen, the LAN's data will
be no more than one day behind, even if no-one has done anything
except leave the PCs running overnight. OTOH, if no PCs are lost,
each PC can fall back a working week, should the need arise - e.g.
- on Wednesday, a hunter-killer payload overwrites data file content
- on Monday, this is discovered
- the last backup of Friday is equally affected
- so they'd fall back to Tuesday's backup from the local HD
Sometimes the most recent backup isn't the one you want
Market Research: ' What would you like us to be? '
Yes, I see value in local HD backups for this reason.
I don't usually attempt "full system backup" outside very particular
circumstances, such as before resizing partitions etc. Usually those
circumstances are such that a backup is automatically created, e.g.
keeping the old HD when imaging to a new one, etc.
Few circumstances "fit" a simple restore of a "full system backup".
If a PC is stolen, or core parts break, then the replacement hardware
may not run the restored backup, and a malware payload situation means
the malware will likely be present (in active but latent form).
Because these "full system backups" are typically partition images,
they aren't as browsable as file-level backups should you need to pick
out a few files; OTOH a file-level backup generally won't yeild a
working installation when restored even if no files are missing.
So I do a full data backup instead. This gets automated daily via
Tasks to another volume on the local HD, where the last 5 backups are
kept. The most recent of these is then pulled (again, via unattended
Task) to another PC over the LAN, and from there the collected LAN's
data backups can be "last miled" to CDRW.
This means if all but the backup system is stolen, the LAN's data will
be no more than one day behind, even if no-one has done anything
except leave the PCs running overnight. OTOH, if no PCs are lost,
each PC can fall back a working week, should the need arise - e.g.
- on Wednesday, a hunter-killer payload overwrites data file content
- on Monday, this is discovered
- the last backup of Friday is equally affected
- so they'd fall back to Tuesday's backup from the local HD
Sometimes the most recent backup isn't the one you want
Consumer Asks: "What are you?"
Market Research: ' What would you like us to be? '