I have a laptop with a C and E partition, around 35 G each. Windows and
programs are on the C and it is 50-60% occupied. I don't have any files yet,
but plan on transferring no more than 1G. I'm a home user and the only large
files I plan on having are some audio recordings. With that said, is there
any need for me to have this partiton?
Need, no. Desire, I'd say YES; YMMV.
I mean, if I del;eted it and saved my files in one C of around 76 G, would
this jeopardize either the files or Windows in any way?
Yes.
For starters, your audio files would be mixed in with the OS and
everything else, and if they get as big as usual, you'd have to
trundle the heads from one end of the volume to the other even when
not doing anything with the audio files.
Windows is constantly writing to C:, so bad exits usually mean C: has
to be "checked for errors". Do you want to trudge through 18G of
current C:, or 60G of a C: that contains all your data?
In XP, System Restore operates on a per-volume basis. With a small C:
and a code-free E:, you can disable SR completely on E: and limit SR's
head travel to within the small C: volume.
File corruption happens during file write operations. Because Windows
is constantly writing to C:, that's not really where I'd want my data,
especially as you have no control over how AutoChk (after bad exits)
or ChkDsk "fixes" it.
File system corruption usually stays within the confines of the
afflicted volume - another reason to keep data off C:
You can backup and restore data files as files, but you cannot backup
and restore an XP installation in this way. Instead, you'd have to
make a partition-level image of the volume containing the boot and OS.
I'd much rather have to backup a small C: (and have another nearby
volume to store the image on) than have to image off a massive C:
bloated by data files I've already backed up as files.
The prospect of having just one hard drive intrigues me
in that it should be easier to manage and free up 5-6 G.
How "easy" is it to re-create all data since last backup, if it melts
down? There are easier ways to free up 5-6G.
I also have a question about system restore. If I create a restore point in
Windows XP, would this safeguard the files on the E as well as the operating
system and programs on the C?
System Restore is conceptually the opposite of a data backup - i.e. it
strives to EXclude your data from the backup!
Having said that; yes, SR will track system, settings and code changes
across all HD volumes unless you specifically set it not to. I keep
core OS and apps on C:, not caring if less-crucial games and apps
elsewhere get hosed, and I disable SR on all volumes other than C: -
so not only is there no SR traffic on other volumes, but by SR store
is not bloated with off-C: code changes I don't care about.
The last question leads to an even broader inquiry: What's the best way to
back up one's computer?
That's like "how do we attain World Peace?"
Backup what, against what eventuality?
Backup strives to retain wanted changes while avoiding all unwanted
changes. How do you scope unwanted changes out, and wanted changes
in? Bearing in mind that it may take a while before you notice
something is lost, and may not want to lose everything done since
then, so a monolithic slab of "full system backup" would be useless.
What's likely to go wrong?
Against total hardware failure or site destruction, you'd want a full
system backup stored off-site.
Against an "oops" saved-A-over-B, you'd be more interested in how
recent your backup of B was, rather than where it was stored.
Against malware that's been presentwithin the code file set for an
unknown period of time, you'd want to be sure the backup was
malware-free; that means a pure data backup free of any incoming
material and containing no infectable material (e.g. no code files).
Copying files elsewhere on the same volume is a "shallow" backup in
that anything that corrupts the volume, trashes your backup too.
Copying files to another volume on the same HD is better in that it
survives volume corruption - but a physical failure of the HD may kill
both data and backup.
Copying files to another physical HD in the system is better in that
ir survives HD failure, but a lightening strike, mains surge or theft
of the PC may take out both HDs at once.
Copying files off the system altogether is "deep" in that it protects
against a wide range of eventualities, but if you have to sit there
feeding in disks, etc. you probably won't do it all that often. If
that's the only backup you have, you'd likely lose less data across a
wide range of disasters, but lose more data (created since last
backup) no matter how "shallow" the disaster was.
I think you can join the dots - there is no single "perfect" backup
solution. Not one, no matter how much money you throw at the problem,
given that certain disasters will permeate any "complete" backup.
You have to choose 1 or 2 points from the triangle of "depth" (how
wide a range of disasters am I protected against?), "size" (how much
stuff can I fit on the backup?) and "currency" (will my last backup
contain even my most recent data?). Not only that, but you may want
temporal depth too, so you can fall back to long-lost data, etc.
So I would combine frequent "shallow" unattended data-only backups
with more formal off-PC backups, and I would keep backups going back
at least a week in time. For large data sets, I would do a definitive
end-of-project backup and then remove that project from the active
data set, so that the data set remains small enough for easy
(frequent) backup, such as an unattended inter-volume transfer.
By "volume", I mean "partition" or "drive" or "logical volume", in the
sense of something that has a drive letter and a file system and is
always there, in the same way that removable disks aren't.
When I say "best," I mean a combination of effectiveness and
price, of which the latter is a huge object.
Multiple volumes on the same HD, open-source command-line archiver,
and a Task that automates data backup to other volume: Free.
Transfer of this data archive backup to DVDRW; Cheap, but not in time,
if you have to swap multiple disks. Small data sets that fit on a
single CDR(W) or DVDR(W) are nice.
Imaging off the installation volume to another volume on the same HD;
cheapish, and impossible if you have "one big C:"
Imaging off the OS volume to DVDR(W); cheapish, and cheap in time if
the whole of C: fits on one DVDR(W).
Adding a second HD to accept images of C:; costly, and poor in
temporal depth if C: is as big as the extra HD.
OTOH, a decent-sized (e.g. 200G) HD can store multiple copies of a
small C: in one volume, while the rest of the HD can be used for data,
and the rest of the original HD can be used to hold backups of this
data. This is what I might do...
HD1 small C: (depending on discipline, could be 7.9G)
HD1 large D: for data backups
HD2 large E: for live data
HD2 largish F: for C: image backups
The nice thing about this is that because normal runtime doesn't
involve doing data or C: backups, the heads never have to traverse D:
on HD1 or F: on HD2 - you have all the joys of phat data-per-cylinder
with the joys of a short "stroke" because your active volumes and file
sets are not bloated by inactive lumpy backups.
This is better than the more obvious "HD1 for C: and live data, HD2
for backups", in that this cross-backup allows "live" work to seperate
(and shrink) head activity for data and code - which is particularly
useful for real-time recording and editing of large data streams.
The only downside is that you can't remove HD2 as an "only for
backups" hard drive, protecting it against HD destruction or theft.
Still, compare this with living within one big doomed C:, tossing
backups about within the same volume, and having these interleaved
with your code and live data... eeeww. I'd be prepared to learn my
ABCs (or rather, by CDEFs) in order to do better than that ;-)
---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
