On 2/3/2018 2:50 PM, Adam Pribyl wrote:
On Fri, 2 Feb 2018, Iturriaga Woelfel, Markus wrote:
I tried the "dump | restore" way,
dump -0 -f - /var/lib/backuppc | restore -r -f -
after few minutes:
restore: cannot write to file /tmp//rstdir1517604355: No space left on
device
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.
seems restore is first writing some files to /tmp.. ok used
dump -0 -f - /var/lib/backuppc | restore -r -T /copy -f -
when it gets to the
DUMP: dumping (Pass IV) [regular files]
it just stays there for 12h with almost nothing copied.
Dump is fast because it copies file system blocks. As restore write files, it
is slow.
You can take dumps relatively fast if you will store the dump in a file instead
of piping it to restore.
Dump of 60G v3 cpool takes about 2 hours, but restore of this dump takes about
1 day.
tar -C /var/lib/backuppc --one-filesystem --acls --xattrs -cf - . | tar
-C /copy -xvf -
How does this deal with hardlinks?
I am running short on ideas how to copy this.
To get rid of hardlinks, consider to upgrade from BackupPC v3 to v4.
This seems to be yet another reason why I want to move this to RAID1 now....
Another option is to move to ZFS and use `zfs send` and `zfs receive`.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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/
