Les Mikesell wrote: > Peter Walter wrote: > >> Les Mikesell wrote: >> >>> Peter Walter wrote: >>> >>> >>>> For me, the matter could be resolved if a >>>> way was found to at least backup a backuppc server in a reasonable >>>> fashion without requiring particular filesystems and utilities such as >>>> zfs send/receive. >>>> >>>> >>> But there is a reasonable way: unmount the partition and image-copy the >>> raw disk or partition. Given that the issue with other approaches is >>> that the head has to seek all over the place to access the same amount >>> of data through the filesystem, this solves the problem neatly with one >>> linear pass. Or, get the same effect by raid-mirroring to your backup >>> device so you only have to unmount momentarily to fail/remove the other >>> copy. Zfs improves on this since it has an incremental mode that is >>> still based on the block device. >>> >>> >> Yeah - but you need physical access to do that, and presumes your >> storage devices are "real". My needs are to backup a backuppc server >> where the server doing the backup is at a remote location from the >> backuppc server, and physical access to either server is difficult - I >> am dozens (sometimes hundreds) or miles away from either server. In >> addition, I have access to "cloud storage" I would like to take >> advantage of, but can't because of the hardlink issue. My (klugey) >> solution at present is to use a backuppc server to backup the backuppc >> server, but even incrementals take days to run. >> > > You can always trade bandwidth for access. If you have sufficient > bandwidth you can do an image copy anywhere you want - even to a huge > file in cloud storage. If you don't have the bandwidth - or enough > space for that image file, then you need to use something specialized to > work around your problem, like zfs incremental send/receive. But, if > your backup window permits 2 runs, the easy solution is to just run a > 2nd backuppc server hitting the same targets with rsync and forget about > copying the server itself. > > Terabyte image copies between servers are not feasible with the WAN bandwidth I have available. The second backup server does not (and cannot) backup the original targets directly - the second backup server may only access the primary backup servers remotely, not the targets that the primary backup servers access. Using zfs is not an option because I don't control the configuration of the primary backup server, except that I am allowed to configure backuppc on it.
I am therefore restricted to copying the primary backup server itself. The intent is not to be able to recover the targets directly - the aim is to recover the primary backup server, and, from there, recover the targets. If I had a method of simply backing up the changed files on the backup server, and a method of dumping the hardlinks in such a manner that they could be reconstituted later, then that would suffice. Peter ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
