[/QUOTE]
I don't think so, no. As other posters suggested, I allow SR to
operate only on the system drive C:, which is the only place I install
tightly-integrated sware that's likely to prang the PC and need SR to
"undo". I do install some programs off C:, such as bulky games etc.,
but if these fail, they shouldn't take down the system, and an SR
rollback that leaves them unfixed doesn't faze me.
SR is supposed to ignore data files, but the basis for this
distinction is wobbly when it comes to unusual file name extensions
and file types. So using SR on a data volume can have the risk of
reverting data when doing an SR restore.
SR can present a malware risk when it restores malware files and the
integration thereof. Less significantly, it may restore an inactive
malware (as it arrived, e.g. email or MS Messenger attachment). I
route all incoming material off C:, so not running SR on those volumes
removes the particular risk of restoring these files.
SR's real danger is where you have multiple OS installations, booting
sometimes one, sometimes others. It's important to keep each OS on
its own volume (the exception being a DOS mode, which if you know what
you are doing can co-exist with an NT or Win9x on the same volume) as
all Windows from NT and Win95 onwards will contend over "Program
Files". So you'd start by having each Windows on its own volume, and
you may want to prevent NT OSs from seeing each other's core files.
If you leave one OS's SR to monitor another OS's volume, then that SR
will miss all changes made while this other OS is running (because at
that time, the SR in question is not running). If you were to do a SR
restore, it would be verrrry likely to garbage the other OS!!
The only thing I would change in your setup is that I wouldn't use the
built-in MS backup program. I really hate backup programs where you need to
have the backup program installed to get your data; i.e., where the backups
are stored in a proprietary format. My preference is to just copy the files
to DVD as they are.
Similar logic, but I prefer to use an archiver (e.g. anything that can
make .ZIP with LFN preservation) and then transfer the archive to DVD
or CD. The reasons are:
- file system naming rules differ on CD vs. Windows
- some environments will cause all files to come back as read-only
- archives include some error detection for bent contents
It's been said that DVDs lack the built-in error correction that
typify CDs; if so, the last is particularly beneficial. But the main
hassles I want to avoid are prompts about too-long file names,
Internet files with funny characters, names that start or end with a
space, broken links between files because file names were "massaged"
by the write to CD or DVD, characters like ! or - becoming _ because I
used the wrong file name standard when burning the disk, everything
being read-only, and files on the disk being inaccessible from DOS
mode because what it sees as 8.3 names have spaces in them.
Or you can write your own script if you are talented that way and use Task
Scheduler to run it.
That's what I do; I batch a CLI archiver to cycle through 5 archives,
looping over from 6 back to 1 and deleting the next in the sequence
(which would be the oldest). If on a private LAN, I read-share the
backup location so that other PCs can gather the latest archives from
all the PCs on the LAN, for a "holographic redundancy" effect
------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
