[conspire] conspire Digest, Vol 48, Issue 4

[Rick Moen]

Quoting Edmund J. Biow (biow at sbcglobal.net):

> Or if you already have an extended partition, you simply resize it and
> create your new partitions, bypassing all the tedious backing up and
> restoring.

Copying data (e.g., across the local LAN to another host) is quite quick
and requires a single command -- and my default assumption is that one
actually _likes_ one's files and would prefer to keep them.  Thus, the
desirability of making a safety copy before performing partition
surgery.

Novice users persist in thinking that _actually bothering_ to perform
backups must be incredibly arduous and time-consuming -- having, in
general, never bothered to try.  Those same novices are the ones I see
crying piteously when something goes wrong in "non-destructive"
partition operations and they lose everything.

> I have already paid my Microsoft tax, I'm not going to junk Windows
> XP, even if I don't use it very often.

http://en.wikipedia.org/wiki/Sunk_cost

> ...my winmodem...

http://en.wikipedia.org/wiki/Sunk_cost

> It's all Black Magic to me, I don't know why anything works, but I'll
> give you my experience.  I used DD to clone my server's disk a few
> weeks ago, then ran up against the 4 primary partition snafu, gparted
> wouldn't let me claim more drive space, either by expanding hda4 or
> creating a new partition.

1.  Copy one partition's data elsewhere for safekeeping.
2.  Delete that partition.
3.  Create an extended partition in its place.
4.  Create the desired number of logical drives within that partition.
5.  Copy the data back.

The nice thing is that you have a safety copy of data at all times, and
can use ordinary, reliable tools (no gparted required) and arrange your
partitions exactly as required.

> So I zapped the last two partitions and created new, bigger ones and
> rsynced over just those two partitions from my old drive, leaving the
> MBR and first two partitions intact from my DD enterprise.  It worked.

Sure.  That would.  But it would have been a lot simpler to just have
copied the data off to elsewhere, make partitions of the desired size on
the new HD, then copy the data back over.

> I was actually very surprised that the DDed MBR worked fine with my
> new, bigger partitions, since I thought it would have been confused by
> the difference in cylinder boundaries.  

I'm not.  The only disadvantage is that one of the partitions declared
its final cylinder to be one long before the actual end of the drive.
You later fixed that by deleting it and making a new partition.

> I was just pleased that I didn't have to chroot and reinstall the MBR.

Rewriting your first-phase bootloader in the MBR is no big deal.  This
is another reason why you should keep a maintenance boot disk around:
Having that, you no longer need worry about something clobbering the
bootloader, since you can easily reinstall it.

> I suppose if you were ambitious and technically inclined you could
> edit the MBR or an extended partition boot record with a hex editor,
> but as Ted Kennedy said at Chappaquiddick, I'll drive off of that
> bridge when I come to it.

Er, _wrong_, wrong tool.

> DD, by the way, works like a charm if you have two identical hard
> drives.

Sure, including bit-copying existing partition damage, absolutely
verbatim.  It's really good at that.

(That's sarcasm, by the way, in case the tone-of-voice problem prevents
it from coming across correctly.)

> I just cloned my new system for a friend who got the same motherboard
> & HD, changed the passwords, hostnames, IP setup and wiped my personal
> data and he was good to go.  And DD seemed to be faster than RSYNC.

Yes, it's faster because it's doing _raw-mode bit-copying_, with all
the disadvantages attendant thereto.  Any corruption in the original is
precisely and meticulously preserved.
  
> Because it takes forever to transfer large dollops of data and only a
> couple of minutes to resize a partition and make a new one.

If by "large" you mean 500 GB, then you have a point -- and, at minimum, 
it's a scheduling issue.  For systems of a few gigs: horsepocky.
Anyway, if there are hundreds of gigs of data of my data at stake, I'm
sure as hell _not_ going to entrust them to a "non-destructive"
partition resizer, and am absolutely going to insist on making a safety
copy, instead.

For the same reason, I'd then insist that my data end up living on newly
constructed partitions made using reliable, standard tools, not suspect
ones copied over using dd or worked over by partition resizers.

> When I RSYNCed my primary data partition last month, it took all night
> and a big chunk of the next day to transfer over 100 GB.  And I forgot
> to use a verbose option, so I had to trust it was actually doing
> something and hadn't just hung up (well, actually I did check with TOP
> that most of my minuscule CPU was being devoted to the task).

If you were doing this on a system with a minuscule CPU, that was likely
your problem, as rsync is CPU- and RAM-intensive compared to obvious
alternatives.  (If you used the "z" option out of habit, that would have
worsened the problem.)

There's an art to picking the right tool for the task, Edward.