Hi,

> Am Montag 09 Juli 2007 15:25 schrieb Ralf Gross:
> > Krsnendu dasa schrieb:
> > > I have a dedicated disk for BackupPC it is using LVM. Can I use dd to
> > > clone this to a newer harddrive?
> >
> > I've done this a few weeks ago and it worked.

you can 'dd' the LV to a LV (or disk partition) on the new disk. You can
probably 'dd' the PV to a PV of the same size too, but I wouldn't recommend
that. Since there's no 'pvextend' command, I doubt you'll be able to resize
the PV to take advantage of more space on the destination drive.

In both cases make sure to have the file system on it *unmounted* (or mounted
read-only if you must) during the whole operation. Taking an LVM snapshot
should also give you a reasonable (though not clean) file system state.

If you want to find out why you're actually using LVM, use 'pvmove' (note
though that your kernel/dm_mod needs enabled "device mapper mirror support"
(CONFIG_DM_MIRROR) - if in doubt, try it out; 'pvmove' will complain if it
is missing):

1. pvcreate a PV on the new harddisk,
2. vgextend the VG to include it,
3. pvmove the LV (and any other ones if applicable) off the old harddisk and
4. vgreduce the old PV (on the old harddisk) out of the VG.

Refer to the respective man pages. I'm not giving the exact syntax here,
because you should really know what you are doing and what you *can* do with
LVM :).

The advantage of this is that you can do it without unmounting the file
system - during running backups if you like. In theory, it should not even
slow the backups down, though it surely won't speed the 'pvmove' up if there
is heavy disk activity :). No changing device names, no changing minor device
numbers, no risk of confusing source and destination devices.

Matthias Meyer recommended on 09.07.2007 at 22:08:36 [Re: [BackupPC-users] 
/var/lib/backuppc replace HDD]:
> cc -a also works

The C compiler? Promising idea. At least better than suggesting 'cp'.

For the sake of the archives and those searching them: 'cp' will take *long*
for any reasonably sized pool (as reported many times). For a large pool, you
may spend days or even weeks on copying with 'cp' even though you thought it
should be a matter of hours. There is probably no good estimate how long a
specific pool size will take, because it depends on what your file trees look
like. There is probably no good way to check on progress, because the hard
part of the job is re-creating hard links. Having your destination file
system contain 99% of the amount of data it is supposed to contain does not
mean 99% of the copy time has elapsed. You would not be the first person to
abort copying your pool this way after days of waiting for it to complete.

With 'dd', it's a nice linear copy of one disk to another. Modern SATA disks
should give you transfer rates of 30MB/s and more. 'dd_rescue' even shows
its progress and is particularly handy if your source disk is failing. You
can interrupt 'dd'/'dd_rescue' and restart it later, leaving out [a large
part of] what you previously copied, if you get the parameters right :).

'pvmove' also copies below the FS level. I would expect it to be slightly
slower than 'dd'. You can interrupt and resume a 'pvmove' operation if need
be. You basically tell 'pvmove' to "move all extents of LV xxx off a
particular disk", so you don't need to figure out how far it got and where
to continue. You can keep the FS mounted and even run backup or restore
operations during the move. You can seemlessly move a LV from one source disk
to several (eg. smaller) destination disks or vice versa. The only downside
compared to 'dd' (yes, and 'cp') is that you don't get a free backup copy of
your pool file system. Also, I don't know how well 'pvmove' handles disks
with read errors. I'm rather sure 'cp' doesn't handle them well at all,
unless of course they're confined to unused space within the file system.

Regards,
Holger

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Reply via email to