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 <wbppc AT parplies DOT de>
> wrote:
>
> > Hi,
> >
> > backuppc AT kosowsky DOT 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 AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
