Hi,
In a similar situation, we use afio. It is like cpio but much more
efficient.
Yves
John Pettitt wrote:
> Notes on migrating to bigger storage.
>
> Two weeks ago I asked about migrating to my BackupPC pool to bigger
> storage. I got a number of responses and after some experimentation
> re
Notes on migrating to bigger storage.
Two weeks ago I asked about migrating to my BackupPC pool to bigger
storage. I got a number of responses and after some experimentation
reached the following conclusions:
Suggestions:
1) dd the filesystem then expand it on the new storage. It's fast
On Wed, Dec 27, 2006 at 12:42:38PM +0100, Diaz Rodriguez, Eduardo wrote:
> Only check that the size in the new file system has the same size that
> the old system. are this correct?
Yes, you would see a significant increase in used space on the new file
system if the copying went wrong and didn'
Only check that the size in the new file system has the same size that the old
system.
are this correct?
On Wed, 27 Dec 2006 11:10:03 +0100, Tino Schwarze wrote
> On Wed, Dec 27, 2006 at 11:04:06AM +0100, Diaz Rodriguez, Eduardo wrote:
> > I allways move my pools using super complex procedure
>
On Wed, Dec 27, 2006 at 11:04:06AM +0100, Diaz Rodriguez, Eduardo wrote:
> I allways move my pools using super complex procedure
> stop backuppc
> cp -a
> start backuppc
Be sure that cp is a GNU cp or at least handles hardlinks correctly -
otherwise you'll multiple your storage requirements.
Bye
I allways move my pools using super complex procedure
stop backuppc
cp -a
start backuppc
:-D
On Thu, 21 Dec 2006 09:25:31 -0500 (EST), Stephen Joyce wrote
> I've had good results moving storage pools between RAID devices (for
> maintenance) using xfsdump and xfsrestore. I'd recommend that you
On 12/20/06, John Pettitt <[EMAIL PROTECTED]> wrote:
> I'm about to migrate my BackupPC partition to a new raid controller
> (more space and more spindles) - my current thinking is to use
> dump/restore - has anybody done this - what issues did you encounter?
I've used tar over ssh which worked we
I've had good results moving storage pools between RAID devices (for
maintenance) using xfsdump and xfsrestore. I'd recommend that you
investigate the dump/restore commands for your filesystem (I've learned to
avoid ext for anything over ~1TB but YMMV).
For locally attached devices, the rates w
I've has success using PAX to copy ~72GB of data.
pax -r -w /old/path /new/path
It took quite a while, far longer than DD would have, but personally
prefer copying on a file level to a device level. The tail end copy
process in an intense IO seek for to match hard lines.
On Wed, 2006-12-20 at 15:25 -0600, Carl Wilhelm Soderstrom wrote:
> dd bypasses those memory problems. if you want to move it across the
> network, pipe it through netcat. I moved 200GB of backuppc pool across the
> network that way in about 12 hours. once on the new box, I just used the
> reiserfs
On 12/20 10:02 , daniel berteaud wrote:
> To migrate backuppc data, I use the command
>
> rsync -aP -H --stats /source /destination
>
> it's quite long, depending on the number of files, and it can need a
> huge amount of memory, but it's working. For a local migration, you
> can also use GNU cp
Le Wed, 20 Dec 2006 14:56:02 -0600,
Carl Wilhelm Soderstrom <[EMAIL PROTECTED]> a écrit :
> On 12/20 12:26 , John Pettitt wrote:
> > I'm about to migrate my BackupPC partition to a new raid controller
> > (more space and more spindles) - my current thinking is to use
> > dump/restore - has anybo
On 12/20 12:26 , John Pettitt wrote:
> I'm about to migrate my BackupPC partition to a new raid controller
> (more space and more spindles) - my current thinking is to use
> dump/restore - has anybody done this - what issues did you encounter?
it's not unreasonable.
personally, I'd just use dd a
I'm about to migrate my BackupPC partition to a new raid controller
(more space and more spindles) - my current thinking is to use
dump/restore - has anybody done this - what issues did you encounter?
John
-
Take Surveys.
14 matches
Mail list logo
