Prev: What prevents mounting of USB devices?
Next: Want it? Give
From: vr on 11 Apr 2010 21:50
On Sun, 11 Apr 2010 19:30:14 -0500, Ron Johnson <ron.l.johnson(a)cox.net>
wrote:
> On 2010-04-11 18:49, thib wrote:
>> Ron Johnson wrote:
>>> Yes, "wire" is slang for network cables, but SATA cables are actual
>>> wires too and orders of magnitude slower than CPU/RAM transfer.
>>
>> This is true, but isn't relevant to what you suggested.
>> Think about it some more.
>>
>> ...
>>
>> Oh yes.
>>
>> We'll never talk about this again, I promise.
>>
>> -thib
>>
>> PS I'll tell you something embarrassing about me if you find a SATA
>> controller that can inflate.
>>
>
> You're absolutely correct. This time...
>

I've used dd to push a copy of a working system onto larger drives in the
past. So my misuse of the term "migrate" is me actually doing a copy of the
working system to a new, larger device and then zap the original.

I'd hoped there was a block by block way to do it so I didn't have to set
up the partitions & filesystems ahead of time but I suppose that part won't
be too painful.

The system is relatively idle during these types of surgeries because I
boot from a live CD so the data on disk isn't churning.

Thanks to all who responded, it gave me a lot to consider for this type of
project. Like doing proper diffs afterwards to make sure everything landed
on the new device properly!


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/f6af5a3f47ea48bd1e0f695949793313(a)192.168.0.66
From: Stan Hoeppner on 11 Apr 2010 23:10
vr put forth on 4/11/2010 8:49 PM:

> I've used dd to push a copy of a working system onto larger drives in the
> past. So my misuse of the term "migrate" is me actually doing a copy of the
> working system to a new, larger device and then zap the original.
>
> I'd hoped there was a block by block way to do it so I didn't have to set
> up the partitions & filesystems ahead of time but I suppose that part won't
> be too painful.
>
> The system is relatively idle during these types of surgeries because I
> boot from a live CD so the data on disk isn't churning.

The last system (server) I migrated was from a 40GB IDE to a 500GB SATA on a
new add-in PCI SATA card. Once I got the sata_sil and libata drivers
squared away, new partitions created on the new drive, I stopped all the
necessary potential problem child daemons, and used "cp -a" to move
everything over, one directory at a time. I chose this method based on
advice I received here. I confirmed correct copying of each dir as I went.

I even did this in runlevel 2 via an SSH session instead of single user mode
(I don't like the limited 80x25 physical console). Last thing I changed was
/etc/fstab on the new drive, ran LILO, powered down, decabled the old drive,
powered up, changed the boot device order, the system booted from the SATA
drive, and everything worked, with a couple of exceptions in /dev/ which
aren't actually created automatically on each boot as I'd previously
thought. Once I manually created these devs everything worked fine and has
since. Previously the system was basically just a Postfix firewall/gateway,
and now I've also got Dovecot, Lighty, Samba, and all other kinds of servers
running successfully. It's amazing what new life a fresh fast big disk can
breath into an old server. Due to an unknown problem with the old IDE drive
I was only getting 7MB/s transfer rate out of it. I'm getting 80MB/s with
the new drive. :) The machine has a completely different character now,
quick and responsive.

I was actually very surprised at how smoothly the "cp -a" migration went.
This easy migration is just one of the many reasons I love Linux. And I
find more reasons all the time. ;)

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BC28ED0.7050207(a)hardwarefreak.com
From: thib on 11 Apr 2010 23:50
vr wrote:
> [snip]
>
> I'd hoped there was a block by block way to do it so I didn't have to set
> up the partitions & filesystems ahead of time but I suppose that part won't
> be too painful.

Well, as I said in another branch of the thread, you can shrink most
filesystems, including all extfs (I think the only bad boy here is XFS),
look at resize2fs(8) from e2fsprogs for these.

Again, the solution is not necessarily better nor simpler, just different.

> The system is relatively idle during these types of surgeries because I
> boot from a live CD so the data on disk isn't churning.

That's good, and I'd say that's even necessary if you don't have
snapshotting tools (LVM2 is good at it).

> [snip]

-thib


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BC29707.8050703(a)stammed.net
From: Mark on 12 Apr 2010 02:30
On Sat, Apr 10, 2010 at 2:12 PM, vr <debian-user(a)iotk.net> wrote:

> What's the best mechanism to migrate a working bootable system from one
> drive to a smaller capacity drive?
>

How about Clonezilla, clone mode, not image mode?

Mark
From: Sjoerd Hardeman on 12 Apr 2010 08:40
Ron Johnson schreef:
> On 2010-04-12 03:14, Sjoerd Hardeman wrote:
>> Ron Johnson schreef:
>>> On 2010-04-11 15:54, Sjoerd Hardeman wrote:
>>>> Ron Johnson schreef:
>>>>> On 2010-04-11 08:11, Clive McBarton wrote:
>>>>>> Sjoerd Hardeman wrote:
>>>>>>> mount the new device (mount -odev /dev/newdevice), and do a
>>>>>>> rsync -ax / /media/newdevice.
>>>>>> What exactly is the advantage of this approach over "cp -a" or "mv"?
>>>>>>
>>>>>> I would have suggested mv. It has the useful property that you can
>>>>>> easily spot aborted transfers by the fact that the original device is
>>>>>> not empty afterwards.
>>>>> One note is that I've had issues where symlinks remain pointing to
>>>>> the old drive. (That was a long time ago, though, and maybe I did
>>>>> something
>>>>> wrong.)
>>>> I thought symlinks keep point via a file location memo, like "look at
>>>> /usr/share/the/file/you/want", which is the old location just after
>>>> copying, but the new location when you boot from your new device and
>>>> that becomes root.
>>>>
>>>
>>> Note how at the bottom or this example bar/shoe still points to
>>> ../snuffle/shoe/. When you try to "cp -axv / /some/new/root" the
>>> same thing will happen. In /usr/bin all the symlinks to
>>> /etc/alternatives will still point to the *current* /etc/alternatives
>>> not to /some/new/root/etc/alternatives.
>> As expected, thus. So when change your fstab to let /some/new/root
>> become / then all the symlinks are as they should be.
>>
>
> There's only one way to find out...
Well, I once migrated with these options from an almost broken hard
drive to a working one, and I didn't run into problems with symlinks. SO
most likely, "it just works"

Sjoerd


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: What prevents mounting of USB devices?
Next: Want it? Give