rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] Moving the backup-location to another machine


From: Ron Leach
Subject: [rdiff-backup-users] Moving the backup-location to another machine
Date: Sat, 11 Jan 2014 17:45:50 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

We're replacing our backup server and hit a problem moving our existing backup directory to the new machine. Despite the new machine's disk space being slightly larger than the space on the existing system, we've run out of space on the new machine, and the move is not yet complete. I think we've either approached the moving of the backup incorrectly, or we've not created as large a filesystem as we had intended

I wondered whether any other users have tried something similar; here's what we did:

Existing backup server uses 2 x 2TB disks in a Raid1 config, exported over NFS. Rdiff-backup backs up local disks onto a 'local' destination (which is the NFS export from the backup machine). One partition is exclusively available for backups, and

$ df

reports:

192.168.0.97:/backups 1894289664 1874215424  20074240  99% /mnt/s2backups

ie, 1894289664 1K blocks, 1874215424 blocks used, 20074240 available on the existing backup archive partition.

To move the backup archives to the new machine, I used cp .

address@hidden;/mnt/s2backups$ cp -a -u -v .* -t/mnt/s7backups

That is, copying all the content of /mnt/s2backups, including all the subdirectories, across to a new, empty, LVM occupying a complete 2 x 2TB raid1 drive pair on the new server, exported over NFS and mounted as s7backups. I think it had copied all but around 6%, before reporting no space left on device.

df on the new backup machine is now reporting:

[...]/backupsvg-backupslv 1922726712 1825057796 4 100% /mnt/s7backups

('/dev/mapper' stripped to avoid line wrap)

ie, 1922726712 1k blocks, 1825057796 used, 4 available

This surprised me. First, the new disk, as expected, has more 1K blocks than the existing archive partition (because it uses the whole disk whereas the existing archive is merely one partition on a 2TB raid1 array that also holds other data), But, unlike the existing partition (where all 1K blocks are either used or available), on the new machine, of the 1.9 bn 1k blocks on the disk, some 97m blocks are neither available or used. Also, the blocks that have been used before exhausting the space are fewer, even, than the blocks employed on the old archive, so that archive is never going to fit - unless the missing 97m blocks come back into play.

Could I ask two questions? Was the cp command I used a sensible way to move an rdiff-backup archive to another machine?

Although slightly off-topic for this list, has anyone encountered the problem of 'missing' 1k blocks when using LVM (and, in this case, over whole-disk raid1)? I will look around elsewhere for general comments about this, but I wondered whether anyone else was also using this type of scheme for their backups and had noticed similar effects.

I'd be grateful for any comments, especially if there is a better approach to moving the archive.

regards, Ron



reply via email to

[Prev in Thread] Current Thread [Next in Thread]