SATA and Ghost 2002

[Rod Speed]

Rod Speed wrote

And where is "the imager"?

Anywhere you want it to be.

If it's on the drive that just failed, you're hosed.
Nope.

And the clone can be booted where it lies - no other HD needed.
An image file has to be *restored* to another HD to be booted.

Wrong, as always. It can be restored to the drive the image is on too.

No, image files are for people who like accounting.

Pig ignorant lie. The imager looks after that for you.

Clones are for people who want to get on with life.

Never ever could bullshit its way out of a wet paper bag.

You waste FAR more time working out how
to boot the clone you want to boot instead.

AND you waste even more time when you
cant do incremental and differential cloning too.

AND what matters for any decent backup scheme is the time
the backup takes, NOT the time the restore takes, because you
ALWAYS do FAR more backup ops than you ever do restores.

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

 

[Timothy Daniels]

"Rod Speed" stretched the imagination:

Anywhere you want it to be.

Yeah. Like on a 2nd hard drive. One hard drive
for the OS. One for the imager. And a stack of CDs
for the image files. You must be an accountant by
trade.

Wrong, as always. It can be restored to the drive the image is on too.

Right. And the image probably came from partition 1 of the
primary drive, and the image files are stored in partition 1 of
the archival drive, and so you restore the image to partition 2 -
AND YOUR BOOT.INI ENTRIES ARE NO LONGER VALID
because they point to partition 1. Smart.

You waste FAR more time working out how
to boot the clone you want to boot instead.

Yeah. See above and your screwed up boot.ini file.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Yeah. Like on a 2nd hard drive. One hard drive for the OS. One for the
imager.

Not a ****ing clue, as always. The usual thing is
one on the OS/app drive thats used for the routine
imaging so the image is always up to date, and
a bootable CD in case that drive is unusuable, stupid.

And a stack of CDs for the image files.

Only a pig ignorant fool like you would do that.

The obvious place to put the image files is exactly
where you are currently putting the clone, ****wit.

You must be an accountant by trade.

Never ever could bullshit its way out of a wet paper bag.

Right.

Fraid so.

And the image probably came from partition 1 of the primary drive, and
the image files are stored in partition 1 of the archival drive, and so
you restore the image to partition 2 -
AND YOUR BOOT.INI ENTRIES ARE NO LONGER VALID
because they point to partition 1. Smart.

It would be terminally stupid to do it that way if you want to be
able to boot off that 'archival drive' without changing any of the
multiboot detail. It would make a hell of a lot more sense to keep
the image files in other than partition 1 of that drive, ****wit.

You clearly need that seeing eye dog and white cane bad.

Yeah. See above and your screwed up boot.ini file.

See above on your terminal stupidity exposed
for the entire world to laugh at, as always.

 

[Timothy Daniels]

"Rod Speed" wet his paper bag:

The usual thing is one on the OS/app drive thats
used for the routine imaging so the image is always
up to date, and a bootable CD in case that drive is
unusuable....

So you have to synchronize the imager in the OS/app
drive and the imager in the bootable CD to keep
track of the incremental updates in case the hard drive
craps out. You must love accounting.

It would be terminally stupid to do it that way if you want to be
able to boot off that 'archival drive' without changing any of the
multiboot detail. It would make a hell of a lot more sense to keep
the image files in other than partition 1 of that drive, ****wit.

Ahhh! So you have to go into the image files and modify
their boot.ini entries so they will be correct when you
"restore" them. Smart. Especially when can have any
of the archived clones boot right where they lie by having
the "parent" boot.ini have a full complement of generic
boot.ini entries that get copied automatically to every
clone of it that's made. That means that although the
"parent" partitions can be partition X, the clone can be
booted right where it was put in partition Y *without* any
boot.ini diddling, without any "restoring", and without
synchronizing 2 versions of the imager to keep track of
the incremental file updates. Cloning is clearly the way to
go unless you want waste your time with record keeping.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

So you have to synchronize the imager in the OS/app
drive and the imager in the bootable CD to keep track of the incremental
updates in case the hard drive craps out.

Wrong, as always. A decent imager keeps
track of that in the image files, ****wit.

You must love accounting.

Thanks for that completely superfluous proof that you have
never ever had a ****ing clue about even the basics.

Ahhh! So you have to go into the image files and modify their boot.ini
entries so they will be correct when you "restore" them.

Wrong, as always. ALL you have to do is ensure that the partition
where the images are kept is separate from the partitions you can boot.

Smart.

Terminally stupid in your case.

Especially when can have any of the archived clones boot right where they
lie by having the "parent" boot.ini have a full complement of generic
boot.ini entries that get copied automatically to every clone of it
that's made.

Just as true with imaging, ****wit. And you get the real
advantages of hot incremental and differential imaging as well.

That means that although the "parent" partitions can be partition X, the
clone can be booted right where it was put in partition Y *without* any
boot.ini diddling,

Just as true with imaging, ****wit. And you get the real
advantages of hot incremental and differential imaging as well.

without any "restoring",

But without any possibility of hot incremental or differential cloning.

and without synchronizing 2 versions of the imager to keep track of the
incremental file updates.

Thats always been your pathetic little pig ignorant fantasy.

Any decent imager keeps track of that stuff in the image
files. You can restore those image files with anything you
like, even a clean install of the imager if you need to.

Cloning is clearly the way to go unless you want waste your time with
record keeping.

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

He's right.

There too.

 

[Timothy Daniels]

"Rod Speed" runs out of ideas:

ALL you have to do is ensure that the partition where
the images are kept is separate from the partitions
you can boot.

And that *still* requires one to do a RESTORE
and then to diddle with the boot.ini entries
before being able to boot the clone. With
direct cloning, none of that is necessary.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

And that *still* requires one to do a RESTORE

You quite sure you aint one of those rocket scientist ****wit children ?

and then to diddle with the boot.ini entries
before being able to boot the clone.

Wrong, as always. If the partition where the images are stored is after the
other partitions, no need to do a damned thing with the boot.ini entrys.

With direct cloning, none of that is necessary.

And you cant do incremental or differential clones,
and cant do file level backup of particular files that
are particularly important at a higher rate either.

One VERY fundamental FACT is that you will ALWAYS
do a hell of a lot more backup ops than you will ever do
restores or recoverys, so its important that the backup
ops are optimised, cretin.

 

[Timothy Daniels]

"Rod Speed" fogged over:

If the partition where the images are stored is after the
other partitions, no need to do a damned thing with the
boot.ini entrys.

<LOL> Who can argue with nonsense!

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

<LOL> Who can argue with nonsense!

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

Even someone as stupid as you should have noticed that
the boot.ini partition parameter numbers are entirely numeric,
numbered from the front of the drive, so as long as you have
the partition you are restoring the image before the partition
you have the images in, there will be no need to do a damned
thing to the boot.ini, ****wit.

 

[Timothy Daniels]

"Rod Speed" struggled with his English::

Even someone as stupid as you should have noticed that
the boot.ini partition parameter numbers are entirely numeric,
numbered from the front of the drive, so as long as you have
the partition you are restoring the image before the partition
you have the images in, there will be no need to do a damned
thing to the boot.ini, ****wit.

Wrong again! AGAIN!! The partition to which the images
are restored must have the same partition number as the
original partition. It has nothing to do with which is before
the other.

*TimDaniels*

 

[Rod Speed]

"Rod Speed" struggled with his English::

Wrong again! AGAIN!!

We'll see.

The partition to which the images are restored must have the same
partition number as the original partition.
Duh.

It has nothing to do with which is before the other.

Having the partition the image are on after the one
thats going to be booted is one way to keep the
partition number in the boot.ini constant tho, ****wit.

Presumably you actually are that stupid.

 

[SG-1]

Go Acronis m8

i had similar with Ghost 2003 which i liked apart from its total failure
with SATA

Acronis is the future !