On Tue, Oct 30, 2012 at 08:37:39PM +1100, Tim Connors wrote: > Just make sure the sum of the zvols remains below 80% of the total > disk usage, I guess.
yep, that's well documented. for read-mostly usage, it's not a problem...but write performance can really suck on ZFS as the disk gets close to full. > I'm actually regretting my move to zfs because of it - I can hardly > afford to repeat the month it took to rsync the backuppc pool to zfs > in the first place. IMO, backuppc and zfs (or btrfs) are not a good mix. admittedly, i don't like backuppc much (my personal experiences with it have been pretty bad), but that's just my subjective preference. the real problem is that backuppc is creating squillions of hard links in order to retain a backup history - which made sense in the days before filesystem (btrfs, zfs) or volume level (lvm) snapshots were available. in other words, it's solving a problem that isn't actually a problem with these filesystems. you've got a multi-year investment in backuppc and obviously don't want to lose your backup history....my suggestion is that you investigate ways to convert your existing backuppc archive into a series of zfs snapshots. i doubt very much that there's an existing tool to do this, but it's probably not difficult to write a shell script to automate the process of iterating through the list of backuppc "snapshots", restore each one individually to a zfs filesystem, and snapshot. repeat until they're all done. write the script so that it can be stopped and started at will (e.g. skip any restores that have already been done) so you can run it only during idle times (or just use ionice to make it a very low priority IO job). once it has completed, you'd use rsync+snapshot for your backups. unless you used ZFS de-duping (with all the hardware requirements - massive amounts of RAM and L2ARC) you'd lose multi-host de-duping, but you'd keep de-duping on a per backup-host base due to the COW nature of ZFS and zfs snapshots. this would, no doubt, take a LONG time to run...probably nowhere near as long as it took you to rsync squillions of hard links (huge numbers of hard-links are a problem for rsync - it has to keep track of them all in memory by inode number). you'd also have to have a second zpool to restore the backups to. craig -- craig sanders <[email protected]> BOFH excuse #350: paradigm shift...without a clutch _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
