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/