Um, by your definition, perhaps. That's just a little too facile to be a
general definition.
It's inevitable if you take user expectations as to what "backup" does
into account, i.e. that it loses unwanted changes while preserving
wanted changes. Implicit is the idea that the unwanted changes are
more recent than the changes you want to keep; therefore, falling back
to an earlier state will preserve data while losing the damage.
Clearly, falling back to an earlier state loses data saved or changes
made after the backup was made; thus "loses data".
Now you can hedge this in various ways:
1) Reduce time lapse between backup and live data
The extreme of this is real-time mirroring, such that changes are made
to "live" and "backup" data at the same time - in essence, both copies
of data are "live". This protects against a very specific type of
problem; death of one half of the mirror.
But anything that writes junk to the HD will write junk to both HDs
equally, unless the junk arises within half of the HD subsystem of
course. So in that sense, zero-lag backup isn't really a "backup".
Also, several things that kill one HD will very likely kill both HDs;
power spike, site disaster, theft of PC, flooding, etc.
2) Keep multiple time-lapse backups
Now we're getting somewhere; instead of having one big backup, you
keep a number of these made at different times, and can fall back as
far as needed; assuming you discover the data loss you wish to reverse
within the time period you are covering in your backup spread.
You will still lose whatever data you saved between the last sane
backup, and the time of data loss. The only way to avoid that is to
have transaction-grain steps between successive backups.
The assumption this approach rests on is that the disaster is such
that all further work ceases, so that the time between the data state
you want to keep and the disaster you want to lose is always positive.
3) Selective scope
This counters the negative lead time problem that is inherent in the
malware infection-stealth-payload sequence of events.
By including only non-infectable data in your backup, you will lose
malware, as well as losing content that ties the backup to particular
hardware or application version.
These backups can then be restored onto new replacement PCs with less
worry about inappropriate drivers, version soup, or malware restore.
You can reasonably expect to have saved only what data you've
saved in your backup before your head crashed
My point exactly; if you want anything more recent that - or you find
all your backups are unacceptable when restored - then the "other"
stuff you want to see again will have to be recovered.
If my filesystem or disk crashes (and any disk can crash at any time,
leaving moot the question of running chkdsk), I count myself lucky if I can
save *anything*. That's why I often backup.
Sure, that's why we <cough> all backup. My approach is to:
- keep a small data set free of infectables and incoming junk
- automate a daily backup of this elsewhere on HD
- scoop the most recent of these to another PC daily
- dump collected recent backups from that PC to CDRW
If you can image the entire system, then you'd keep the last image
made after the last significant system change, and use that as your
rebuild baseline before restoring the most recent data backup.
In practice, users tend to skip the "last mile" to CDRW for one reason
or another (out of disks, didn't get it together, etc.). If it's a
stand-alone PC, that leaves only the local HD backups, which remain
available only as long as that part of the HD works. If they have
been switching the PC off overnight, they won't even have that.
I fail see how this moves us towards *how* a naive user may
recover data from a crashed disk or severely damaged filesystem.
My point was that backups do not remove the role of data recovery,
even if they do reduce what is at stake.
The user's environment includes support techs, and in such cases,
you'd expect these to be involved if the user isn't keen on firing up
the Diskedit chainsaw themselves.
Data recovery is not always a costly clean-room epic undertaking;
sometimes it's a couple of snips here and there, and can be faster and
cheaper than rebuilding from scratch and restoring backups.
http://www.windowsubcd.com/index.htm
Ah! This time the page loaded!!
Looks verry interesting, thanks!!
--------------- ----- ---- --- -- - - -
The memes will inherit the Earth
