Re: Backup Software rcommendation
- From: "Bill in Co." <not_really_here@xxxxxxxxxxxxx>
- Date: Sun, 23 Mar 2008 15:07:48 -0600
Brian A. wrote:
"Bill in Co." <not_really_here@xxxxxxxxxxxxx> wrote in message
news:%2324SwlLjIHA.4076@xxxxxxxxxxxxxxxxxxxxxxx
No, what I said above was that one *could* choose to do this, if one
wanted
to. NOT that one normally makes a clone TO do this!! BUT it IS an
option IF one so chooses, or at least it can be, right? Well, more
on
that below..
Before getting to the below, Yes, one could use a Cloned disk to Clone
another disk, yet I don't see any reason to do that to a failed disk.
Failed disk? No, not to a failed disk, but to a good backup HD, which
could then be "restored" to the source drive (note: I am *not* talking
about hardware disk failures here, just restoration for software
failures).
As I mentioned previously, disk failure can be caused by any number of
reasons, that would include software corruption. Perhaps I should have
used:
a disk that fails to properly boot the system which could be caused by any
number of reasons. I still see no purpose, reason or otherwise to create
a
clone disk as a restore disk, that's what images are for, not clones,
especially if the clone is an external USB drive. IMO external USB drives
are problematic at best as backup media when it comes to crunch time in
get a
system back up and running.
Yes, *normally* clones are used just for the purpose you said. BUT (see
below)
Let me repeat what I just said in response to Daave, and see if makes more
sense:
But this is the point that still seems to be missed here (IMHO): Yes, on
the surface it normally doesn't seem to make much sense to clone the source
drive to the backup and then reverse the operation (like when some software
installation has screwed up the source drive) - EXCEPT that Casper may have
a significant total time advantage, in that instead of making those daily,
complete images (like in TI) to overwrite the previous day's complete image,
it has this fast Smart Clone operation, which might only take a minute each
day to incorporate all the daily changes made on the source drive for that
day's work.
So, if one religiously makes these "smart clone" backups every day, it takes
very little time; and when and if one wants to "restore" the source drive
(due to some software mal-installation problem on it), one CAN simply clone
the backup clone back to the source drive. (And I'm assuming that
operation takes about as long as doing a image restore operation in True
Image).
The total time invested for doing all this might well be less than using
True Image each day to completely overwrite the previous day's image (and
then later restore it back).
And trying to use TI's "Incremental" feature seems a pain, as you have to
keep track (and use) ALL of the increments accumulated when the time comes
due - a real PIA, I think.
Obviously if there were a hardware-failed disk, that disk would be junk,
and
the whole concept I'm talking about here makes no sense. In that case,
a
cloned disk would be the right option (pull it out afterwards, and put it
in
the failed drive's place).
When one uses an application such as ATI, Ghost or Casper to "Clone"
disk(s), all data ("information") on the disk(s) platters that are
selected to be cloned is written to the "recipient" disks platters.
Depending on the app used, *this has been a debate drudgery", the
"Clone
is a Sector x Sector, Byte x Byte replica including the MBR//MFT of
the
"Donor" disk. When the clone is completed, the "recipient" disk has
the
same data on it that is on the "donor" disk and it should be stored in
a
what the user deems a relatively safe haven. To minorly clarify, a
cloned disk is an "exact" replica of a "donor" disk, if the "donor"
fails
for any reason all one has to do is shut down the PC, swap out the
disks
and reboot to be back up and running again. *Keep in mind that any
cloned disk(s) can be and are prone to conditional issues already
present
on the "donor" disk at the point in time the clone is created.
Yes, but I know this already - (UNLESS you are stating that the clone
disk
must be exactly the same size as (identical to) the source disk).
Not at all, it makes what-so-ever no difference whether one clones a
disk or
creates an image of the disk. Depending on the application used and the
knowledge on use of such application by the user, one can use a clone to
clone another disk or "Restore" an image to a disk\volume\partition
which
has less free space then the clone/image, as long as there is enough
free
space on that drive\volume to expand the volume\partition.
OR one could choose to "restore" the source drive (which had some
software
failure) by "restoring" the clone back to the source drive - that is, by
cloning FROM the backup drive TO the source drive (the opposite
direction,
in other words) - if one so desired.
Actually, someone may WANT to do that, if the cloned backup drive is in
an
USB external enclosure (it can be a pain to swap it out!), and all they
have
is a cloned backup (because they didn't use imaging for their backups, in
other words)
I wish anyone that chooses to do so good luck, it's still senseless IMO
to
use a clone as a restore disk in that manner.
I hope I explained it above (re: some potential *overall* time savings
involved, due to Casper's Smart Clone capability), even if using it for
"restoration" purposes (like in imaging) (which, as you said, is not it's
normal intent)
I'm sure I have some
type of error in the use of terms drive\volume\partiton for this
particular
post, but I'd rather swap out a cloned disk as apposed to waiting for an
image restore to complete so I could have at it.
Right, except that if we're just making system backups, and one of the
drives (the backup drive) is in an USB enclosure, it's more convenient to
leave it there.
As a side note, I can't overestimate this one. Some of these USB
enclosures are a bit of a pain to work with in terms of extracting the
drive. :-)
But if that is not the case, then again I ask: but this does not
necessarily preclude one from doing the reverse operation, does it?
That was my point. IOW, one could use a cloned disk to (in effect)
restore
the source disk. If not, why not?
The only way I see it is to swap out the the failed disk with the clone
to
expedite user production, otherwise it's senseless.
Wait - to "expedite user production" you say. What I see is a reverse
operation being employed, and yeah, ok, perhaps that takes more time than
simply doing a backup image restoration, but I don't see how it's so
difficult. Granted, it may take longer - I don't know. However,
there
is ONE advantage (to the cloning backup approach), in that you have a
bootable clone disk right there at your fingertips, IF the need arises -
like a hardware disk failure of the source drive).
How is the user going to get that external USB so called "bootable disk"
to
boot if the OS itself won't boot?
(But where did this case come up here? that's even another issue).
Are they going to boot with a type of
recovery disk for the backup application with hopes of USB support
working?
You mentioned you use
ATI, check into Acronis Snap Deploy. Although I believe it would be an
extra cost at the moment, in the long run it could/would be a godsend to
some. Ooops, sorry, they now call it Snap Restore:
http://www.acronis.com/homecomputing/products/trueimage/tour/6/
Heck, I *know* I can do that - by booting up on a floppy in BootitNG
(BING), which does a low level, partition copy, between two disks of
any
size (but NOT in windows). So is that an image copy or a clone
copy? Somewhat
ambiguous. What is NOT ambiguous is that it does a disk partition copy
operation.
From what I've read by others BING creates an "Image", not a clone, in
the
way you mention. As I mentioned before, a clone is a sector x
sector/byte x
byte transfer from one disk to another without compression, I did
however
fail to mention about the compression. An image is created where the
user
chooses to place it and it is compressed.
I think the terms are still a bit confusing here, but to clarify, what
BING
does do is a *partition to partition* copy. There is no ambiguity of
terms
at this level. (And there is no compression). It's just a fundamental,
sector-to-sector, copy of any partition you choose. (If you want to
copy
two partitions, you'll have to run it a second time for the second one,
and
so on). And of course, when you are in BING, you can't see anything
(except at the sector level) - files, per se, are not defined at this
level.
I'll take your word on that since I don't and never have used BING to
create a backup.
I've used it occasionally with my WinXP computer (and its external USB
enclosure drive), but even much more for my Win98SE computer (and its
external USB enclosure drive).
Although not scientifically exact in a manner of my wording, an
"Image" is
an exact copy of all data ("information") on the disk(s) platters that
are
selected to be cloned is written to the "recipient" disks platters.
Depending on the app used, *this has been a debate drudgery", the
"Image
is a compressed Sector x Sector, Byte x Byte replica including the
MBR//MFT of the "Donor" disk.. Think of an "Image" being like that of
a
Zip file.
(But (in some cases) still accessible, in that the files inside can be
accessed, as I mentioned before). But yeah, in a sense it is like a
zip
file.
The files of a cloned disk can be accessed at the point it is connected
and
the OS is up and running, whether it be connected as a Master or Slave
drive. An image can only be accessed via the software which created it
unless it's not proprietory.
Yup. The True Image disk image is indeed accessible (to a limited
extent)
in Windows Explorer, but only through a low level running background
service
provided by True Image. I say to a limited extent, because while you
can
copy from it, you can't copy to it (which seems expectable).
I'd have to look into that for ATI, yet I know Ghost, at least 2003 and
ver.
9 can do exactly that.
Do check it out. But I have rarely had the need to use that feature.
.
- Follow-Ups:
- Re: Backup Software rcommendation
- From: Brian A.
- Re: Backup Software rcommendation
- References:
- Re: Backup Software rcommendation
- From: Bill in Co.
- Re: Backup Software rcommendation
- From: PD43
- Re: Backup Software rcommendation
- From: Bill in Co.
- Re: Backup Software rcommendation
- From: PD43
- Re: Backup Software rcommendation
- From: Anna
- Re: Backup Software rcommendation
- From: Daave
- Re: Backup Software rcommendation
- From: Anna
- Re: Backup Software rcommendation
- From: Daave
- Re: Backup Software rcommendation
- From: Brian A.
- Re: Backup Software rcommendation
- From: Bill in Co.
- Re: Backup Software rcommendation
- From: Brian A.
- Re: Backup Software rcommendation
- From: Bill in Co.
- Re: Backup Software rcommendation
- From: Brian A.
- Re: Backup Software rcommendation
- From: Bill in Co.
- Re: Backup Software rcommendation
- From: Brian A.
- Re: Backup Software rcommendation
- Prev by Date: Re: XP SP3
- Next by Date: Re: Backup Software rcommendation
- Previous by thread: Re: Backup Software rcommendation
- Next by thread: Re: Backup Software rcommendation
- Index(es):
Relevant Pages
|
Loading