Today, Rock made these interesting comments ...
There are three aspects to backup:
- your data, and other static content such as downloaded music
- your installation
- special material, such as license keys etc.
The first can be backup by copying as files, either directly, or via
something that agregates and compresses them, such as an archiver or
file-orientated backup program.
But XP is too fragile to survive a file-level copy, even if you
meticulaously preserve every file perfectly - it has dependencies that
break, and which can only be preserved by imaging the partition that
holds the installation. And because installed apps usually require
preservation of the registry, which is chained to the OS installation,
everything depends on this process.
The last is "beyond the scope of this post"; just let's say that if
you deal with user-hostile DRM thugs, the chances are high that simply
having your music files doesn't mean you will be able to use them.
Backup is easy; it's restoration that is difficult, as this process is
rarely tested and fraught with gotchas!
Planning backups starts before the system is set up:
I'd use a small C: to facilitate imaging of the software installation
in a minimum of space and time.
I'd relocate data OFF C: so that it is away from the incessent traffic
there. Files are corrupted by writes; fewer writes, less risk... and
the scope of file write errors and corruption is typically limited to
the volume, even though a physical HD failure can eat all partitions
and volumes on that HD equally.
I'd debulk the data set so that it is small enough to back up, by
moving Music, Pictures and Videos out of there.
I'd also sanitize the data set by ensuring no infectable code files or
incoming material is stored there. Off-the-peg downloads, received
attachments etc. are NOT "data", are hi-risk, and should NOT be mixed
with data and backups thereof.
Then I'd use a file-level backup for the data set, and separate
similar backups for music and other bulky stuff, and yet another
separate process for incoming and infectable material.
Why would you need to restore?
- finger trouble, so data backups must be browsable
- malware payload, so data backups must be clean
- delayed damage, so backups must have temporal depth
- theft of PC, so backup must be off PC
- site destruction, so backup must be off site
One size clearly does not fit all, so I:
- scope data from code as noted above
- handle narrow-focus restores via browsable data file backups
- handle narrow-focus system rollback via System Restore
- add my own registry backup (ERUNT)
- have temporal depth by keeping the last X data backups
- have temporal immediacy by automating nightly data backups
- do other backups (imaging, pictures etc.) less often
- hold at least 2 copies of backups off the PC
I agree, a reasonable amount of redundancy is highly valuable.
And, since no one knows when their HD will crash, even though
modern ones are quite reliable, even having a secondary external
isn't enough. In my case, I have an external for work-in-progress
style backups and rotate 2 200 gig externals between my bank's
safety deposit box and a shelf in my basement.
Sounds good. Several scenarios will kill any device connected to the
PC, such as mains surges, theft, site flooding etc. so twin HDs in the
same box doesn't cut it. However, it's hard to beat a RAID1 setup for
immediacy, but hte flip side is that most events will hit the "backup"
as well. You need immediacy (how recent?) as well as depth (do we
have a backup from before things went wrong?)
My backup regimen, about every 4-6 weeks, is to first scan both
my PCs for malware, there being no sense in backing up an
infected system,
That's a weak approach to the problem. Consider...
- you have a resident av
- that resident av misses malware
- malware infects PC and is active
- malware can hide from or defeat scans while active
- you use the same av that failed to "detect malware"
....how well can you expect this to work?
Far better to scope malware out of your data set altogether, by strong
"no infectable files" and "no incoming material" policies. You'd also
want an off-HD facility to formally scan the system to better exclude
the presence of malware.
Malware's designed to hide, so it is very likely to have been present
long enough to pervade all backups that don't scope it out. You can
and should assume an installation image will be infected (hence the
formal cleaning tools to be applied after restore but before first
boot) and that's why you want separate data backups.
Not if you maintain an installation image backup, though you may
indeed have to rebuild from scratch if the core hardware (motherboard
etc.) changes. A "repair install" will usually, but not always, fix
an image restored to different hardware.
That can be automated, up to a point. My tactics:
- keep data set small and clean, as noted
- night task archives data set to another local HD volume
- this process keeps the last 5 backups (temporal depth)
- this backup collection is manually dumped to flash or optical disk
On a LAN, you can read-share the backup location and have a later
night task find the latest backup archive and pull it to a different
PC on the LAN. The read-only shares prevent inter-PC malware payload
damage, and you can have a "holographic storage" model where as long
as one PC survives, you have day-old data for all PCs on the LAN,
without having to "remember" to do anything at all
It has been said that the time most people decide to start
backing up their system is right AFTER a major crash or failure.
"Real men do data recovery.
Sensible people make backups"
It's a good line, but the need for data recovery never goes away
completely. A good system design (partitioning, choice of file
systems, data locations) facilitates both.
--------------- ----- ---- --- -- - - -
Who is General Failure and
why is he reading my disk?
