search for: 4800gb

On Wed, May 6, 2015 2:46 pm, m.roth at 5-cent.us wrote: > Alessandro Baggi wrote: >> I list, >> I'm new with backup ops and I'm searching a good system to accomplish >> this >> work. I know that on centos there are bacula and amanda but they are >> too >> tape oriented. Another is that they are very powerfull but more complex. >> I >>

...using XFS on LVM, on CentOS 6.latest... That backup raid is mirrored to an identical server in a seperate building via drbd for disaster recovery. I keep 12+ months of monthly full backups, and 30+ days of daily incrementals. The deduplicated and compressed backups of all this take all of 4800GB, containing 9.1 million files and 4369 directories. The full backups WOULD have taken 68TB and the incrementals 25TB without dedup. I'm very happy with it. its a 'pull' based backup, no agents are required for the clients... it can use a variety of methods, I mostly use rsync-over...

...g of those two LUN''s. The "con" here is that there is no ZFS self-healing capability, though we do gain the other ZFS features. We rely on tape backups for any block-level corruption recovery necessary. The "pro" is there is no RAID-Z space overhead; ~4800GB available space. (2) Same two h/w RAID-5 groups as (1), but configured as some larger number of LUN''s, say 5-9 LUN''s each. Setup a ZFS pool of two RAID-Z groups consisting of those 5-9 LUN''s each. We gain some ZFS self-healing here for block-level issues, b...

...M, on CentOS 6.latest... That backup raid is > mirrored to an identical server in a seperate building via drbd for > disaster recovery. I keep 12+ months of monthly full backups, and 30+ > days of daily incrementals. The deduplicated and compressed backups of > all this take all of 4800GB, containing 9.1 million files and 4369 > directories. The full backups WOULD have taken 68TB and the > incrementals 25TB without dedup. > > I'm very happy with it. > > its a 'pull' based backup, no agents are required for the clients... it > can use a variety of me...