Hi, Richard Shaw wrote on 2013-07-23 12:43:19 -0500 [Re: [BackupPC-users] Move BackupPC "TopDir" To New Larger Hard Drive]: > On Tue, Jul 23, 2013 at 11:39 AM, Holger Parplies <wb...@parplies.de> wrote: > > > Hi, > > > > backu...@kosowsky.org wrote on 2013-07-23 09:01:09 -0400 [Re: > > [BackupPC-users] Move BackupPC "TopDir" To New Larger Hard Drive]: > > > Aaron Cossey wrote at about 14:13:26 +0200 on Tuesday, July 23, 2013: > > > > Sorry but all those pipes are going to slow the transfer > > > > needlessly. > > > > > > While I too use SIGINFO, I doubt the extra pv pipe will slow anything > > > down given that disk read/write is by FAR the rate limiting step... > > > > well, yes, but the pipes *do* mean data has to be copied around needlessly, > > which does come at *some* cost (possibly CPU load). > > > > My recommendation would be dd_rescue, which shows you progress, handles > > read > > errors, has a less error prone command line syntax ... > > I'm sure there are various opinions on this but I just replaced a hard disk > in my desktop computer which used LVM and it made things REALLY easy and I > didn't even have to reboot nor was the system ever unusable. > > If your old drive is not using LVM then you might want to consider it on > the new drive.
I fully agree, but pvmove only works if you are already using LVM, and if you are, you're unlikely to ask this question in the first place ;-). You can migrate to LVM with 'dd' or 'dd_rescue' much in the same way you would transfer your data to a new partition (or whole disk) - your destination would simply be a LV. You can't use 'dd' or 'dd_rescue' or 'pvmove' if you want to change your FS type or your FS doesn't support resizing (presuming there still are FSes that don't ;-). If that's not the case, you probably shouldn't be copying at the file level (rsync, cp, tar, BackupPC_tarPCcopy ...). The notable exception is a *small* pool on a large disk, where a partition level copy will be slower. You'll have to find out for yourself what "small" means, but it will have something to do with "number of inodes" and "number of directory entries" (i.e. links to inodes). If you run into problems, your pool is not "small". > [...] > After that I grew the volume group to the full size (went from 500GB to 1TB > drive) and then resize2fs. You mean the logical volume :). One thing to keep in mind, though, when using pvmove: you still need to move a lot of data from one disk to another. During the time this takes, your data may be spread over two disks, meaning a failure of any one of the disks could lose all your data. This might not be relevant, because pvmove creates a temporary mirror. I'm not sure whether it would mirror the whole LV in any case or only a smaller portion (under some circumstances). If you are replacing a disk that is failing, dd_rescue might be the better approach. If you are just replacing a full disk which is otherwise ok, you are probably fine with pvmove. Of course, losing your source disk before the end of a copy with 'dd(_rescue)' has the same problems. Regards, Holger ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
