Cloning using BootIT NG

[Guest]

I recently "rebuilt" my OS from scratch, putting it on a
smaller partition (20 GB) of a 60 GB disk so that I could
just clone a basic setup for future restore. This basic
setup takes all of about 2 GB of this partition (NTFS, of
course).

I used BootIt NG successfully for the the repartitioning.
However, when I attempted to do a backup image I finally
aborted the session when I got to the ninth disk. Nine
disks?! Why is only 2 GB of data taking up nine-plus disks?

Seems to me there should be a "data only" image option,
which with Ghost would only span about 3 disks. When I
contacted Terabyte about this, I couldn't get a straight
answer. Either there is or there isn't such an option!
Apparently Terabyte's tech support personnel don't even
know. Too bad, because everything else about the product
seems solid and reliable.

The comments I've read about BING elsewhere suggest that
making a data-only compressed image is possible, but I
haven't been able to figure this out from the docs.In any
event if it's going to take 30 disks to back up a
partition, then this is not a good option for imaging.
What am I missing here?

Thanks in advance for any suggestions.

 

[dglock]

you have me confused!
you talk about 2 differnt programs,ghost and bootit ng.
which are you using?
don

 

[Jim]

I've been using BING (BootIt NG) for a long time, at least four years, so
I'm quite familiar with it. I don't do much imaging to CD-R/RW, but the few
times I have, I don't recall any such similar problem (but maybe I never
noticed, or my partitions were too small to notice). Most of the time I
image either to the same HD (placed at the high-end of the HD, for quick
access), or another HD (for recovery in case of HD failure).

But assuming this is true, I can think of at least a workaround. Try
imaging the partition to another FAT32 or NTFS partition (i.e., as a file
instead of a partition), then load Windows and run BINGBURN (available free
from TB) to burn the image(s) to CD-R/RW. You won't have any similar issues
because the files will be highly compressed *before* burning. Yeah, bit
more of a hassle, but it will work.

I suspect there's some limitation in DOS that makes compression and burning
difficult or unreliable, maybe BING can't use the buffer under-run
technology unless using Windows. I'm just speculating.

HTH

Jim

 

[Guest]

I am trying to use BootIt NG. However, I'm comparing it to
Ghost. The question is whether BootIt has the same ability
to create a data-only image of a basic system set-up,
which Ghost CAN do (requiring only about 2-3 CDs).

However when I tried using BootIt NG to make the image, it
seems to be making an image of the entire partition, data
or no data. I don't want that!

I know if Ghost's capabilities from the way it's used in
my workplace, however the new home version has a bad
reputation for being unstable and destructive. I'm
evaluating BootIt NG has a more stable alternative.
However, if it's going to require 30 disks to back up a
partition, then it's not a viable option.

I don't know how I can frame the problem more simply than
that!

 

[Guest]

My original question, however, was aimed at users of
BootIt NG whom might know how it can be set to create a
data only image (if it's possible--re-read my original
post). If you are not a user of BootIt NG, then it is not
necessary to reply.

 

[Jim]

I just thought of one very, very, very, speculative reason BING has a
problem with imaging directly to CD-R/RW.

I'd be willing to make a *small* wager that there's something that needs to
be known about the image file(s) *before* burning that makes it impossible
for BING to handle a direct image to CD-R/RW. IOW, perhaps BING needs to
know the total size of the compressed file(s), number of files, etc., as
part of some header information that goes on the first CD-R/RW disc. But of
course, it doesn't know this until *after* compression is complete. If it
wanted to support direct imaging to CD-R/RW, it would have to find someplace
to store a temporary image before actually burning. But this may not be an
available option to everyone, someone may be imaging their entire HD! So
BING takes the simplest, safest approach and burns without compression (of
course, at the expensive of media). This would also explain why BINGBURN
works, it KNOWS all this information before the image file(s) are burned.
In fact, by imaging to a FAT32 or NTFS partition as I instructed, you've
done manually what BING probably would have preferred to do automatically,
but that would perhaps be too presumptive.

I'm not familiar w/ Ghost and how it images, but perhaps its imaging is
proprietary, does not have similar header dependencies, etc., not like BING
does (then again, I'm not sure if BING is using some *standard* imaging
algorithm either, making it more portable than Ghost?!, again, just
speculation).

Anyway, I'm suspicious it's something along theses lines. If BING doesn't
need to do compression, it avoids all the messiness of these other issues
(is there space for a temp? where can I put it? in some other partition
for temp purposes?), etc. Again, at the cost of media.

HTH

Jim

 

[Jim]

Well, the plot thickens.

As a sanity check (since as I said, I do this very rarely, having an extra
HD around makes this a heck of a lot simpler and faster, using optical media
is just a royal pain), I decided to image my own NTFS partition to CD-R
media using BING 1.60f. The partition contains my OS, is 16GB total, and
~4.3GB used. I imaged the partition directly to some cheap 16x Hi-Val media
w/ my LITE-ON 451S DVD+-R/RW CD-R/RW combo drive. It consumed 4 CD-R discs,
which is exactly what I expected (~ 2-to-1 compression), ~2.4GB. Which is
exactly the same size as when I imaged that same partition to another FAT32
partition for subsequent burning w/ BINGBURN. So wrt your problems,
something is amiss here.

Time for a little more speculation (seems to be a lot of that today).

My partition is highly *de*fragmented. Frankly, I've never trusted that
with any compression algorithm, having a highly fragmented partition would
produce good results. Why? For reasons of speed, I suspect many
compression algorithms are based on sectors. IOW, if a sector contains
*any* data, it's not compressed, simply dumped as is. If the sector is
empty, then it's simple counted, but no data transfer is necessary to the
image file. This makes for a VERY efficient (and interoperable/portable)
process, esp. important when the output is to a highly volatile media like
optical, afterall, that's why we have buffer under-run technology. It also
greatly speeds up verification (unless you specify byte-for-byte
comparison). The idea of going byte-by-byte, sector-by-sector across 20,
30, 60GB of data for compression *and* verification could take a VERY long
time, worse than zeroing out a HD!

Therefore, I'm wondering if perhaps your partition is highly fragmented?!
And what would happen if you defragmented first. I suspect that while you
ate up 9 CD-R initially, it wouldn't have consumed 30, perhaps 12-15.
Perhaps fragmentation was severe enough to cause serious media consumption.
Again, speculating, since I had no problems and have very defragmented
partitions (I can't imaging what else could be different). Hardware,
perhaps, but I don't think BING makes any distinction among hardware.

HTH

Jim

 

[Guest]

Jim,

Yes this helps a great deal. I wrote the image to my data
partition, and the total size came out to 3.5 GB--much
more sensible!! Yes!

Terabyte got back to me with two more suggestions: 1.)
Write to a slower speed (e.g. 4X) and 2.) update the
firmware. Hmmm. This burner is only two years old, an
Aopen JustLink 24X. I've never upgraded the firmware
(didn't know I could!) because it's always done what I
told it to without a problem. Do you have any clues as to
why either of these would fix the problem? I'd sure like
to write directly to disk if I can, but I guess I can live
with the "workaround" if I have to.

Thanks again. I'm certainly sold on BING!

 

[Jim]

Not positive why a firmware update would help, or why the hardware even
matters since you would think it was TB that determined the amount of data
written. I wonder if perhaps the media is not being fully consumed on each
disc (check the back and notice if it appears only partially "burned").

But a firmware update couldn't hurt either, I've done it many times, and
most vendors make updates regularly available. Most updates, for optical
drives anyway, involve adding more media specs to the firmware's list, thus
making the drive better able to optimize use of that media. I suspect TB
believes that your firmware is not recognizing the media you inserted (it's
not currently listed in its firmware), and then chooses an inappropriate
speed. A more current firmware update might contain your media. Obviously,
inserting something like 4x media in a 24x drive w/o such information is
liable to produce bad results. For all I know, the output that was produced
before you quit the process wasn't even readable!

Anyway, given I can write just fine (I have the most available firmware
updates myself, am careful to chose the right speed (manually if need be)
based on my media, etc.), it makes sense to follows TB's advice. Perhaps
the firmware updates and/or a change in media might produce better results.
Just make sure you apply the *right* firmware update for your model, or you
could trash the optical drive too!

HTH

Jim

 

[cquirke (MVP Win9x)]

But a firmware update couldn't hurt either,

Er, no; unless you consider sudden death to be pain-free.

Failure for any reason while updating firmware can leave you with a
doorstop. Also, expect XP to re-detect the updated device as a new
one, tossing any drive letter changes and associated WPA life.

I suspect TB believes that your firmware is not recognizing the
media you inserted (it's not currently listed in its firmware), and
then chooses an inappropriate speed.

Could be - or it's a cheap guess to blame problems on something else,
knowing that TB won't have to pick up the pieces if something breaks.

I'd take that as the last resort, and do it uber-carefully; don't even
plug in the kettle while the update is in progress...

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[Alex Nichol]

I recently "rebuilt" my OS from scratch, putting it on a
smaller partition (20 GB) of a 60 GB disk so that I could
just clone a basic setup for future restore. This basic
setup takes all of about 2 GB of this partition (NTFS, of
course).

I used BootIt NG successfully for the the repartitioning.
However, when I attempted to do a backup image I finally
aborted the session when I got to the ninth disk. Nine
disks?! Why is only 2 GB of data taking up nine-plus disks?

The image backup of BING is designed to backup the entire content of a
partition,so as to restore everything exactly as it was. It is not a
file oriented (and hence potentially selective) one. When you say
'nine disks' - what sort of disk? 2GB allowing for compression should
fit on about 2 CDs; and I find that a compressed image of 7 GB fits on
one DVD

 

[Guest]

It was a fresh install of the OS, plus a few programs. I
can't imagine it being so fragmented as to create THIS
much trouble.

I need to try this on some RW disks (so that I can
blank 'em if all goes awry) with the CD-RW firmware now
upgraded. As I mentioned in my earlier post, this was
Terabyte's suggestion.

Somthing else too--when I reinstalled the OS, I went ahead
and deleted that partition, created a new one and
reformatted it. After the installation I noticed that what
Windows had done was create an extended partition out of
my primary, so that now the first MBR Entry is "Extended"
and then ther is an "unnamed" volume on which Windows is
loaded. Why would it do that? More importantly, when I
originally did this I believe I had the "Extended" entry
highlighted rather than the "Volume" entry when I told it
to Image and Paste.

Hmmm...could this have had something to do with it?

ARG

 

[Guest]

The image backup of BING is designed to backup the entire content of a
partition,so as to restore everything exactly as it was. It is not a
file oriented (and hence potentially selective) one. When you say
'nine disks' - what sort of disk?

CD-R disks. No, I'm not using Floppies! Each of these nine
disks contained 703 MB of data--all nine of them--for 2.5
or so worth of data. Something is clearly wrong with this
picture!

When I wrote the images to a data partition instead, I had
no troubles whatsoever. I now have about 5 GB of data on
my OS partition, but this backed up to only 6 image files,
which I burned to CD using BINGBurn. So, the question
remains--what was BING writing to these CDs that exceeded
the actual content of the disk?

Well, at any rate I have a backup for now. I'm looking
into the possibility of a firmware issue, however I'm
still open to suggestion.


2GB allowing for compression should

 

[Jim]

Several comments here, because your response has generate several different
issues.

First, I have no idea why the XP installer would create an extended
partition (and by extension, create a volume) for the installation of the
OS. As far as MS is concerned, they don't even support installation of
their OSs in the extended partition! And while several people (including
myself, w/ Win98) have managed to do it w/ the right boot loader and some
other trickery, I've not aware of MS's stance on this matter having ever
changed.

Second, I never trust the installer to do the right thing in this regard
anyway. I always predefine my partitions w/ BING, for several reasons.
First, I create them as FAT32, then "Align for NTFS Conversion" immediately
afterwards. This insures that when converted to NTFS later, I'll end up w/
4k sectors. If I use the installer's partition manager, I'm never sure what
I'm gonna get when defining NTFS directly. With every prior OS using NTFS,
the result has been the much less efficient default of 512 byte sectors.
Second, I create a boot menu item for the new OS based on the new partition
so I can hide all other partitions. IOW, as an extra precaution, I don't
even want the installer to see anything *except* the new partition, and what
appears to be unpartitioned space surrounding it. This means I always know
*exactly* where I'm installing, there are no doubts or questions, it's the
only partition available, and it's C:. I always install any OS in this
fashion, it gives me total control and works perfectly every time.

Third, I don't even use extended partitions (and by extension, volumes)
anymore. With BING's unlimited primaries feature, the need for the extended
partition is greatly deminished, I can create as many primaries as I like
(granted, I'm still limited to 4 primaries, or, 3 primaries + 1 extended at
runtime, but for definition purposes, the primaries are essentially
unlimited). Second, I'm not a big believer in having lots of partitions
anyway, just one for each OS, and then a single shared DATA partition among
them, that's it. Anything more is just too much hassle.

Why did BootIt NG let you Paste to the extended partition (you sure?!).
Assuming it did, perhaps it just made the assumption that you meant the
first volume, I guess anyone could program that logic into the program, it
seems a viable assumption. But technically, it should make you point to the
first volume. Could this have something to do w/ your problems? Beats me,
as I said, I can't reproduce it here, so your guess is as good as mine. But
using the procedures outlined above, I've had no such problems. Could *my*
procedures be *avoiding* the problems you're having?! Maybe.

Jim

 

[Alex Nichol]

CD-R disks. No, I'm not using Floppies! Each of these nine
disks contained 703 MB of data--all nine of them--for 2.5
or so worth of data. Something is clearly wrong with this
picture!

When I wrote the images to a data partition instead, I had
no troubles whatsoever. I now have about 5 GB of data on
my OS partition, but this backed up to only 6 image files,
which I burned to CD using BINGBurn. So, the question
remains--what was BING writing to these CDs that exceeded
the actual content of the disk?

That looks as if it was trying to back up all the empty space as well -
not very constructive. And possibly uncompressed too. I can see no
setting in BING for this in relation to Image/paste to CD or file, but
if you do an Image/paste or a copy/paste to free space, as a partition,
there is a box for 'Data only' which I have always left checked. It may
be that this is unset, and is affecting Images to CD too, so you might
try investigating (it comes in with a resize or slide too). And take
the point up with David at (e-mail address removed)

 

[Guest]

I wouldn't use them intentionally either. I may just take
my new image and try it again until it gets it right.

As to the "pasting" question, I was pasting "from" the
extended partion, not to it. But that in itself may have
been the problem all along. When I did my "image/paste"
from the VOLUME instead (which shows the same number of GB
as the Extended), all went as advertised, although I still
have not tried this writing direct to disk. I have a
feeling, though that this explains my initial problem
(based on comments I've received offline from another
user).

Oh--and I did do my partitioning with BING, but it's
possible I overlooked something stupid there too, and that
in turn confused Windows.