Question about backups with Ghost

[Bob Davis]

Restoring a clone is much more dangerous
when you are testing the backup approach.

Actually, when I "restore" a clone I am just cloning from the clone to
another drive. That's the way I've always done it. I'm talking
disk-to-disk clones, not creating an image file. I do the image-file
procedure with my notebook, however, but if I lost everything on it there
would be no major loss.

Bet you're remembering it wrong.

Could be. It's been a while.

You get a lot more capability with True Image, being able to
image over the lan effortlessly, incremental images, full file
level backups, etc etc etc. Those last two are much better
for your second level backups than your current approach.

It would, but only if I've installed programs or updates in the interim.
That doesn't concern me that much, as I keep a log of them and can just
repeat the process. It would be easier *if* I require a recovery, but that
hasn't happened in two years and averages about that duration. I can live
with the minor extra effort once in a long while. As for LAN, I don't have
another computer on the network that is always powered up.

OCD is obsessive compulsive disorder and is a problem between your ears.

Yes, I have this problem that when something isn't broken, does the job,
and I won't save a significant amount of time by changing, I don't fix it.

Yes you do, True Image would be a much cleaner
approach with the secondary backups you do too.

It sounds like it would, but I would need to have another computer running
on the LAN or another drive running at all times to do the incrementals. If
another drive is installed it means another space heater running along with
the four other drives and two CRT's--good in winter, bad in summer.

I obviously can't have another drive inside this machine receiving the
backup files. The savings in time would be a factor only when a restore is
needed. With this setup I crank up Ghost on Sat. morning (<1 min.), go make
coffee and clean the bird cages, come back into the office 20 min. later and
power down, remove the mobile rack and floppy, and reboot. No big deal, and
so habitual I'd probably go through the motions anyway if I changed the
procedure. OCD, you know. That said, I'll think about the other
proposition. I'm open-minded.

The fool that wrote that is just mindlessly repeating the drivel
thats been pig ignorantly spouted on the net for decades now.

Maybe the "drivel" was originally prompted by the Symantec warning.

Makes more sense to test the claim instead and prove its wrong.

The net result is the same by separating the clone and the hourly backups,
except that when I restore a clone (clone the clone, if you will) it takes a
few minutes to copy the backed-up files back to C: from D:. If this is
necessary once a year, historically less than that, it isn't a problem.

The risk of the power supply failing and killing both drives is very low.

Low but could happen, even though I don't skimp on PSU quality.

 

[Rod Speed]

I can't imagine a scenario when I would boot from the clone with the
parent present.

It isnt hard to do it when testing that the clone is
bootable if you dont realise that you shouldnt do that.

But what about keeping D: as a clone of C: in the machine at all times?
IOW, a clone of C: is made to D:, then you
restart XP from C: as usual and keep D: installed?

Works fine and quite a few do it like that, mainly because
that approach requires no manual ops at all and the clone
can be repeated at a high rate, say overnight, so the clone
is as up to date as possible.

You can even clone hourly if you like with some like
xxclone which will only copy stuff thats changed

I know you can do this with Win9x, as I did it for years--but the
caveats I've seen apparently refer to NT-based OS's (NT, 2K, and XP).

They're just plain wrong and the evidence that they are just plain
wrong is those who choose to leave the clone in the system all
the time, mainly because then no manual ops are required at all
until the original fails for whatever reason.

I prefer to do it to a different PC on the lan instead,
because that eliminates any possibility of a power
supply failure killing both drives, and still doesnt
require any manual ops at all until something breaks.

 

[Rod Speed]

Actually, when I "restore" a clone I am just cloning from the clone to
another drive.

Too cryptic, try again.

That's the way I've always done it. I'm talking disk-to-disk clones, not
creating an image file.

Sure, the question of two installs visible
at once doesnt apply with image files.

I do the image-file procedure with my notebook, however, but if I lost
everything on it there would be no major loss.

I always image across the lan to a drive on another PC.
That way the only time I can lose everything is if all the
PCs are stolen at once, or the house burns down etc.

And that risk is easy to protect against by having a decent
hard drive on the lan inside a hidden fire proof safe etc.

It would, but only if I've installed programs or updates in the
interim. That doesn't concern me that much, as I keep a log of them
and can just repeat the process. It would be easier *if* I require a
recovery, but that hasn't happened in two years and averages about
that duration. I can live with the minor extra effort once in a long
while.

Same is true of your rather anal approach to backup tho.

As for LAN, I don't have another computer on the network that is always
powered up.

Doesnt have to be always powered up, just powered
up when its needed. Completely trivial to automate that.

Yes, I have this problem that when something isn't broken, does the job,
and I won't save a significant amount of time by changing, I don't fix
it.

That aint what the OCD has produced. Its what produces
that confusion on saturdays if you dont do the cloning.

It sounds like it would, but I would need to have another computer
running on the LAN or another drive running at all times to do the
incrementals.

No you dont.

If another drive is installed it means another space
heater running along with the four other drives and two CRT's--good in
winter, bad in summer.

A drive is only about 5W, nothing in the total power consumption
and you can sleep it when its not being used anyway.

I obviously can't have another drive inside this machine receiving the
backup files. The savings in time would be a factor only when a
restore is needed. With this setup I crank up Ghost on Sat. morning
(<1 min.), go make coffee and clean the bird cages, come back into
the office 20 min. later and power down, remove the mobile rack and
floppy, and reboot. No big deal, and so habitual I'd probably go
through the motions anyway if I changed the procedure. OCD, you
know. That said, I'll think about the other proposition. I'm
open-minded.

Thats how the OCD got in.

Maybe the "drivel" was originally prompted by the Symantec warning.

Nope, it was around long before symantec ever had that.

The net result is the same by separating the clone and the hourly
backups, except that when I restore a clone (clone the clone, if you
will) it takes a few minutes to copy the backed-up files back to C: from
D:. If this is necessary once a year, historically less than that, it
isn't a problem.

Its still an unnecessarily complicated approach
to backup that could have been avoided by
testing the claim instead of going along with it.

Low but could happen, even though I don't skimp on PSU quality.

Then have the drive on the lan instead.

 

[Timothy Daniels]

Timothy Daniels wrote


I wasnt talking about any fixed order bios, child.

I was talking about drives that do have a HD boot
order list but dont use that for the rdisk() parameter.
The rdisk() parameter is the physical order of the
drives on the controllers, not the HD boot order list.

The default setting of the HD boot order *is* the physical
order of the HDs on the controller. You've just been using
the default setting all along without even knowing it. The
default HD boot order is:
Master on ch. 0, <--rdisk(0)
Slave on ch. 0, <--rdisk(1)
Master on ch. 1, <--rdisk(2)
Slave on ch. 1. <--rdisk(3)

If there is also no Slave on ch. 0, the default HD boot order is:
Master on ch. 0, <--rdisk(0)
Master on ch. 1, <--rdisk(1)
Slave on ch. 1. <--rdisk(2)

If there is also no Master on ch. 0, the default HD boot order is:
Master on ch. 1, <--rdisk(0)
Slave on ch. 1. <--rdisk(1)

Etc. Where there is no HD connected, the HDs below it in
the default HD boot order move up on position in the ordered
list. Thus, if some HD is disconnected, the meaning of
"rdisk()" for all HDs below it in the order changes.

If it doesn't change for those HDs lower in the order if you
disconnect a hard drive (as you describe your own system)
you will have a hanging "rdisk()" for it in the boot.ini file that
points to a phantom hard drive.

*TimDaniels*

 

[Timothy Daniels]

"Bob Davis" asked:

But what about keeping D: as a clone of C: in the machine at all
times? IOW, a clone of C: is made to D:, then you restart XP from
C: as usual and keep D: installed?

A virus could infect the C: drive and then get into a connected
clone drive. I keep my backup clones on a large capacity HD
mounted in slide-in tray that is powered down most of the time.

*TimDaniels*

 

[Rod Speed]

Bob Davis wrote

A virus could infect the C: drive and then get into a connected
clone drive. I keep my backup clones on a large capacity HD
mounted in slide-in tray that is powered down most of the time.

Makes more sense to image instead of clone, ensure
that a virus cant get into the system, and protect the
images so that even a virus cant touch them if it does.

Powering down is dinosaur stuff and prevents a high backup frequency.

And you've never manage to grasp that you
have no protection against PC failure at all.

 

[Rod Speed]

Rod Speed wrote

The default setting of the HD boot order *is* the physical order of the
HDs on the controller.

Irrelevant to the FACT that if the bios uses the HD
boot order list sequence for the rdisk() parameter,
IF YOU CHANGE THE HD BOOT ORDER LIST
ORDER FOR ANY REASON, YOU HAVE TO
MANUALLY EDIT THE BOOT.INI FILE.

THATS THE REASON ONLY YOUR COMPLETELY
****ED BIOS ACTUALLY DOES IT LIKE THAT.
EVERY OTHER BIOS USES THE PHYSICAL
ORDER OF THE DRIVES ON THE CONTROLLERS
FOR THE RDISK() PARAM SO YOU DONT HAVE
TO MANUALLY EDIT THE BOOT.INI WHEN YOU
DO SOMETHING AS TRIVIAL AS CHANGE THE
HD BOOT LIST ORDER.

You've just been using the default setting all along without even knowing
it.

Wrong, as always. I do change
the HD boot order at times.

The default HD boot order is:
Master on ch. 0, <--rdisk(0)
Slave on ch. 0, <--rdisk(1)
Master on ch. 1, <--rdisk(2)
Slave on ch. 1. <--rdisk(3)

The default is completely irrelevant, and only your
completely ****ed bios has the rdisk() param have
anything whatever to do with the HD boot list at all.

If there is also no Slave on ch. 0, the default HD boot order is:
Master on ch. 0, <--rdisk(0)
Master on ch. 1, <--rdisk(1)
Slave on ch. 1. <--rdisk(2)

Wrong again. It isnt just what drives are plugged in that matters,
it also matters which drives are bootable BY THE BIOS too.

The boot.ini system ALLOWS THE BOOTING OF
PARTIONS THAT THE BIOS CANT BOOT. THAT IS
THE WHOLE POINT OF THE BOOT.INI SYSTEM.

AND ITS ONLY YOUR COMPLETELY ****ED BIOS
THAT HAS THE RDISK() PARAM DETERMINED BY
THE HD BOOT ORDER LIST, EVERY OTHER BIOS
USES THE PHYSICAL ORDER OF THE DRIVES ON
THE CONTROLLERS FOR THE RDISK() PARAM,
SO YOU CAN CHANGE THE HD BOOT LIST ORDER
AND NOT NEED TO MANUALLY EDIT THE BOOT.INI.

If there is also no Master on ch. 0, the default HD boot order is:
Master on ch. 1, <--rdisk(0)
Slave on ch. 1. <--rdisk(1)

See above.

Etc. Where there is no HD connected, the HDs below it in the default HD
boot order move up on position in the ordered list.

It isnt just what drives are plugged in that matters, it also
matters which drives are bootable BY THE BIOS too.

The boot.ini system ALLOWS THE BOOTING OF
PARTIONS THAT THE BIOS CANT BOOT. THAT IS
THE WHOLE POINT OF THE BOOT.INI SYSTEM.

Thus, if some HD is disconnected, the meaning of
"rdisk()" for all HDs below it in the order changes.

No it doesnt with the universal system of the rdisk() param
specified by the order of the physical drives on the controller.
In that case nothing changes for drives that arent unplugged.

If it doesn't change for those HDs lower in the order if you
disconnect a hard drive (as you describe your own system)
you will have a hanging "rdisk()" for it in the boot.ini file that
points to a phantom hard drive.

Wrong again. You just dont get that entry in
the boot.ini presented to the user to select.

And when you change the HD boot list order,
the boot.ini continues to work fine, because
that DOES NOT AFFECT THE RDISK()
PARAMETER AT ALL EXCEPT WITH
YOUR COMPLETELY ****ED BIOS.

 

[Bob Davis]

Too cryptic, try again.

C = Original source drive
G = Drive cloned from the original with Ghost
N = New drive

Remember that I only do disk-to-disk clones on this desktop. Suppose "C"
dies, I'll simply replace it with "N", insert "G", and tell Ghost to clone
from "G" to "N". That's the way I've always done it.

I always image across the lan to a drive on another PC.
That way the only time I can lose everything is if all the
PCs are stolen at once, or the house burns down etc.

Good idea, actually, and I could build a cheap PC with old PIII parts,
putting it in another room with an existing LAN connector. I'm not too
worried about theft around here anyway.

Questions about TI: Can you do one clone, then do continual incrementals
on a frequent basis? Does that keep the clone updated, except changes made
between incrementals?
I assume it is creating image files, right?

And that risk is easy to protect against by having a decent
hard drive on the lan inside a hidden fire proof safe etc.

I'd feel better keeping it off-site. I think my fire safe produces liquid
when things heat up, which protects the contents from ignition. That might
not be good for a HD.

Doesnt have to be always powered up, just powered
up when its needed. Completely trivial to automate that.

I think this old PIII mobo bios has a "power-on LAN" option, which I assume
would work to power it up, but what about shutting it down after the update?

A drive is only about 5W, nothing in the total power consumption
and you can sleep it when its not being used anyway.

I'm not sure how to sleep only one firewire drive, but if it can be done I
can figure it out.

Thats how the OCD got in.

It's good OCD, tho. Kind of a conditioned response to produce a good
result, like working out at the gym.

Its still an unnecessarily complicated approach
to backup that could have been avoided by
testing the claim instead of going along with it.

It's complicated in principle, perhaps, but if I can do it easily it isn't a
problem.

 

[Bob Davis]

"Bob Davis" asked:

A virus could infect the C: drive and then get into a connected
clone drive. I keep my backup clones on a large capacity HD
mounted in slide-in tray that is powered down most of the time.

Good point about the virus possibility, though I haven't had one in 24 years
of computing (knock on wood). I know, could happen tomorrow.

Please tell me in more detail about your procedures. Do you clone to an
image file on the drive in the mobile rack, or is it a disk-to-disk clone?
How do you handle updates? What program are you using?

 

[Rod Speed]

Good idea, actually, and I could build a cheap PC with old PIII parts,
putting it in another room with an existing LAN connector. I'm not too
worried about theft around here anyway.

Yeah, I only care about the irreplaceable stuff thats offsite
in those two scenarios. There would be quite a bit of effort
required to replace all the hardware with all new toys, so
it would be no big deal at all to do a clean reinstall since
the hardware detail could well be significantly different then.

Questions about TI: Can you do one clone, then do continual
incrementals on a frequent basis?

Not with a clone, but you can with an image.

I've never believed that clones make much sense
instead of images. Clones do allow you to come up
a little more quickly on a drive failure, but you wouldnt
get that with your quite complex backup system, it
would be just as quick to restore the image instead.

If you really need instant cutover in case of drive failure, you
should be using OS level shadowing instead, because its
going to be much more up to date than cloning can ever be.

And you really need full duplication of the PC anyway,
because drive failure is only one of the failure possibilitys.

Thats something Timmy has never managed to grasp.

Does that keep the clone updated, except changes made between
incrementals?
I assume it is creating image files, right?

Yes, the incremental is images.

It also has a full file level backup system too, which
would replace second level of backup you currently
have. All completely automatic and schedulable.

xxclone does do incremental clones in the way you
are asking about, adding what files have changed
to the clone at whatever frequency you shedule.

I'd feel better keeping it off-site.

Thats got its own downsides tho. You cant have anything
like the same backup frequency that way unless you do
that to the hard drive over the net to the remote PC.

I think my fire safe produces liquid when things heat up, which protects
the contents from
ignition. That might not be good for a HD.

Sure, you do need the right type of fire safe, but it
obviously doesnt need to be very big or expensive.

I think this old PIII mobo bios has a "power-on LAN" option, which I
assume would work to power it up,
Yep.

but what about shutting it down after the update?

Thats trivially automatable. The power up too.

I'm not sure how to sleep only one firewire drive, but if it can be done
I can figure it out.

One obvious approach is to have the drive in and
old PIII etc with firewire still being used if you
want. Might as well use a standard lan instead tho.

It's good OCD, tho.

No such animal.

Kind of a conditioned response to produce a good result, like working out
at the gym.

Nothing like.

It's complicated in principle, perhaps, but if I can do it easily it
isn't a problem.

Yes it is. It'll go flat on its face with a
failure of the raid hardware for starters.

 

[Timothy Daniels]

All Rod Speed presents are epithets and denials - no
experimental data or examples that others can check
to see if he's just full of gas. Who knows what he means
or says as none of it makes any sense if you analyse it.
Maybe he's just a bad expository writer, or maybe his
motive is disinformation. If he really wanted to clarify
his idea of what rdisk() means, you'd think he'd have
done so by now, wouldn't you?

*TimDaniels*

 

[Timothy Daniels]

Makes more sense to image instead of clone, ensure
that a virus cant get into the system, and protect the
images so that even a virus cant touch them if it does.

It makes more sense to keep a clone available for
immediate booting in case the primary HD fails if your
needs are immediate - such as stock daytrading or
software development assignments for college or taking
an online course. There's nothing like just resetting the
boot order and booting up a clone instead of rounding
up another drive and restoring an image file.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

It makes more sense to keep a clone available for
immediate booting in case the primary HD fails if your
needs are immediate - such as stock daytrading

Thanks for that completely superfluous proof that you have
never ever had a ****ing clue about anything at all, ever.

That wont protect you against other than a hard drive
failure, you stupid little pig ignorant ****wit child.

or software development assignments for college

None of those are that time critical, you
stupid little pig ignorant ****wit child.

or taking an online course.

None of those are that time critical, you
stupid little pig ignorant ****wit child.

There's nothing like just resetting the boot order and booting up a clone
instead of rounding
up another drive and restoring an image file.

Pity that wont work if something other than the hard
drive has failed, you stupid little pig ignorant ****wit child.

 

[Rod Speed]

All Rod Speed presents are epithets and denials - no experimental data or
examples that others can check to see if he's just full of gas.

Even someone as stupid as you should be able to
work out how to check if changing the HD boot order
order actually changes the rdisk() parameter in any
system, you stupid little pig ignorant ****wit child.

Who knows what he means or says as none of it makes any sense if you
analyse it.

By trying it for yourself, you stupid
little pig ignorant ****wit child.

Maybe he's just a bad expository writer, or maybe his motive is
disinformation.

Or maybe you lied about what you claimed you
saw on that completely ****ed system of yours,
you stupid little pig ignorant ****wit child.

If he really wanted to clarify his idea of what rdisk() means, you'd
think he'd have done so by now, wouldn't you?

Wouldnt prove a damned thing over trying it on their
own system, you stupid little pig ignorant ****wit child.

 

[Timothy Daniels]

Please tell me in more detail about your procedures.
Do you clone to an image file on the drive in the
mobile rack, or is it a disk-to-disk clone?
How do you handle updates? What program are you using?

My needs are simple as I don't have a business that
needs daily backup. I have a couple large capacity HDs,
each mounted in a removable tray. My operational OS
and my working files are on a 20GB partition, so I can
store many clones of it on the removable archive HD.
The removable rack/tray assembly is one made by
Kingwin. The tray has a horizontal fan in the base, and
it works very well to keep the HD cool - it's *never* warmer
than body temperature:
http://www.kingwin.com/pdut_detail.asp?LineID=&CateID=25&ID=136 .
Kingwin makes other models (with varying numbers of
cooling fans) for both PATA and SATA hard drives:
http://www.kingwin.com/pdut_Cat.asp?CateID=25
http://www.kingwin.com/pdut_Cat.asp?CateID=47
Extra trays can be bought separately for about half
the price of the complete set, and prices for
the set run between $23 and $30 on the Web.

On each archival HD, I have 4 Primary partitions or
3 Primary partitions and 1 Extended partition. I can
put one clone in each of the Primary partitions which
can be booted from the ntldr/boot.ini/ntdetect.com
boot files in the same partition, or I can use an Extended
partitions to contain a bunch of clones which can be
booted from the boot files in one of the Primary partitions.
The Primary to supply the boot files are determined by
which Primary partition is marked "active" - which can
be done with WinXP's Disk Management - and the HD
to supply the partition is designated by putting it at the
head of the BIOS's hard drive boot order. It really doesn't
matter much which Primary partition in the system is
chosen, as each one has a boot.ini file with generic
entries to most of the partitions on all 3 of the drives in
the system. Each entry has in its comment field what its
rdisk()/partition() values are, so I just have to know where
the desired clone resides, and then choose the appropriate
entry from the resulting boot menu that ntldr displays.

This system requires that a cloning utility be able to
copy a single selected partition and put the copy into an
existing partition on another HD or into unallocated space
on another HD which may already have several other
partitions on it. That's why I use Casper XP. It will do
single partition cloning, and it's a dedicated cloner without
all of Ghost's bells and whistles. And it doesn't require
..NET Framework like Ghost 9.0 and 10.0 do, and it doesn't
need to reboot after the cloning is complete.

As for procedures, when Casper XP completes a cloning,
I immediately change the name of a marker file that I have
on the Desktop to reflect the current date and a file to list
any unusual software settings or installations. That way I
can immediately identify a clone by looking at the Desktop
before or after it boots. I then shut down the PC and toggle
the power switches for the other 2 HDs to OFF, then I restart
the PC. The archival HD automatically becomes the boot
HD since its the only remaining HD in the HD boot order,
and it boots right up for its first view of the world. Then I shut
down and reconnect the other HDs and switch off the power
to the archival HD, then boot back up again. (The mobile
rack has its own power switch, and I've installed power switches
for the other 2 internal HDs.)

This will all be much clearer if you read the Microsoft
description of WinXP's boot process. That will give you a
better idea of how a partition is selected as the source of
an operating system to boot. Here is a synopsis:

The Master Boot Record (MBR) of the HD which is at the
head of the BIOS's HD boot order gets control. The MBR
finds the "active" partition on its HD, and it passes control
to the Boot Sector on that partition. The Boot Sector finds
ntldr on its own partition and passes control to ntldr. Ntldr
accesses the boot.ini file in the same partition. If boot.ini
has a single ARC pathname entry, ntldr goes there to find
the OS. If boot.ini has 2 or more ARC pathname entries,
ntldr displays them and waits for the user to select one. If
the user selects one before it times out, ntldr uses the
selected entry to find the OS to boot. ntldr will only display
10 entries, so I can have up to 10 clones to choose from for
booting. I normally have more clones archived, so I might
have to modify a boot.ini file to access a clone "way in
the back" of the archive.

This simple procedure backs up *everything*. I don't
have to set differing frequencies for differing priorities or
even to know what I want to back up. *Everything*, including
configuration settings, dialup connectoids (of which I have
more than 60), recent email, favorites, recent documents -
*everything* gets backed up once a week and remains
archived on hard disk for several months before the
underlying disk space gets recycled. I find it a no-brainer
convenience, and Usenet poster "Anna" finds that her
small business customers like it, too.

If you choose to install several HDs as I have, give a
thought to using "round" cables - they save a lot of room
inside the case and they allow for easier cable routing
and better case ventilation. These cables have a ground
wire twisted together with each of the 40 signal wires to
emmulate the 40 ground wires in 80-wire ribbon cable,
and I haven't experienced any problems with round cables
in 3 years of use. I use the ones with the aluminum braid
for extra shielding, and I've found SVCompucycle to have
a good combination of selection and price:
http://www.svc.com/cables-ata-100-133-round-cables.html .

*TimDaniels*

 

[Timothy Daniels]

And you really need full duplication of the PC anyway,
because drive failure is only one of the failure possibilitys.

Thats something Timmy has never managed to grasp.

Multiple PCs and a router are something Timmy hasn't
the space and the money for, either.

*TimDaniels*

 

[Eric Gisin]

You are the one who is full of shit, Timmy. The real world is not just your little PC.

 

[Bob Davis]

I've never believed that clones make much sense
instead of images. Clones do allow you to come up
a little more quickly on a drive failure, but you wouldnt
get that with your quite complex backup system, it
would be just as quick to restore the image instead.

What I like about a disk clone is that I can insert the drive and extract
one file quickly. Perhaps you can do that with the image file, too, but
using Ghost 2003 it would be more difficult.

Yes it is. It'll go flat on its face with a
failure of the raid hardware for starters.

I tried to explain why that isn't so, but I give up. I don't need the RAID
hardware at all to recover, just a working IDE controller. The clones are
all on IDE single drives.

 

[Bob Davis]

It makes more sense to keep a clone available for
immediate booting in case the primary HD fails if your
needs are immediate - such as stock daytrading or
software development assignments for college or taking
an online course. There's nothing like just resetting the
boot order and booting up a clone instead of rounding
up another drive and restoring an image file.

I like it so I can insert the mobile rack and extract a file quickly. On
occasion I delete something and don't realize it in time to extract it from
the recycle bin, and can recover it quickly from one of my five clones that
go back five weeks. Although I'm using an image to copy my notebook's HD,
I've never tried to restore anything, so I'm not sure if Ghost 2003 can
extract one file. In that case it isn't really important, as I don't keep
anything important there anyway, and do the imaging to save time in case of
a HD failure.

 

[Rod Speed]

I like it so I can insert the mobile rack and extract a file quickly.
On occasion I delete something and don't realize it in time to
extract it from the recycle bin, and can recover it quickly from one
of my five clones that go back five weeks. Although I'm using an
image to copy my notebook's HD, I've never tried to restore anything, so
I'm not sure if Ghost 2003 can extract one file.

Yes it can, and so can any decent modern imager.

In that case it isn't really important, as I don't keep anything
important there anyway, and do the imaging to save time in case of a HD
failure.

It makes more sense to use images instead of clones, basically
because you can keep more of them on the same number of hard drives.