Question about backups with Ghost

"Rod Speed" wrote in message
...

Makes sense, but I've restored a clone enough that I feel confident in
its integrity.

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.


Actually, I just get the "found new hardware" and usually another
cryptic message, then it goes on about its business with no prompt to
reboot. It's been a while since I did it, but that's my recollection.

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.


Thus, in this case I don't do it, and have adapted.

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.


That said, I have no problem inserting the clone to retreive a file, but
I just don't leave it in like I did with Win9x. And like you said, it's
safer that way anyway.

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.

Bob Davis wrote
Timothy Daniels wrote

The clone only has to be isolated from its "parent" OS when it's started
for its first time.

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.

Bob Davis wrote
Rod Speed wrote

Makes sense, but I've restored a clone enough that I feel confident in
its integrity.

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.

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.

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.

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.

I do it every Sat. morning and not doing so would prolly confuse me
for the rest of the day.

Your problems with OCD are your problem.

I don't have any problems with cloning

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.

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

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.

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.

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.

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

Thus, in this case I don't do it, and have adapted.

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.

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

That said, I have no problem inserting the clone to retreive a file,
but I just don't leave it in like I did with Win9x. And like you said,
it's safer that way anyway.

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.

Then have the drive on the lan instead.

"Rod Speed" wrote:
Timothy Daniels wrote
Rod Speed wrote

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

Those fixed-order BIOSes are from the Old World

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*

"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*

Timothy Daniels wrote
Bob Davis wrote

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.

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.

Timothy Daniels wrote
Rod Speed wrote
Timothy Daniels wrote
Rod Speed wrote

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

Those fixed-order BIOSes are from the Old World

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.

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.

"Rod Speed" wrote in message
...

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

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?


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'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.

"Timothy Daniels" wrote in message
...

"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.


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?

Bob Davis wrote
Rod Speed wrote

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.

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.

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.

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.

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,

Yep.

but what about shutting it down after the update?

Thats trivially automatable. The power up too.

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'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.

Thats how the OCD got in.

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.

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.

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