George Georgalis wrote:
What are people doing for off site backup? I know there is a lot
of options, my only requirement is to mitigate risk, which is
kinda vague. There is about 60Gb which may double in a year. It
would be desirable to have on line access to the older data.
Typically I do frequent rsync with hardlinks into dated folders on
HD, so local snapshots are available at the site.
This data is highly private, so that must be part of the formula.
I was thinking of a system similar to the local backups, doing a
pull from a colo machine; and at the same time making cd/dvd or
tapes at the main site which would go into a (bank) safe deposit
box or some other facility.
My tendency is to think an off site raid mirror functioning as a
copy of the local raid mirror snapshots is pretty comprehensive.
It is difficult for me to focus on the benefits of dated tape, hd,
or cd/dvd in a storage facility. What is the real benefit of that?
Very quick disaster recovery is not necessary, but 3 days would
defiantly be better than a week to recover. How do I find the
sweet spot of medium, interval and rotation? Is off line medium
really necessary here?
// George
We try to cover for fire, hardware failure, and operator error ("Oops I
deleted xxx, can you get it back?"). We use Bacula,
http://www.bacula.org, backing up to hard disks in removable bays on a
dedicated backup server. We are lucky enough to have two buildings
close to each other and one has a fire-resistant vault. So saving off
site is pretty easy. We rarely have to do a full recovery so we only do
full backups once a month, onto a set of disks in a hierarchical tree of
retention periods. The tree of disks may not be worth the effort but is
quite cheap and can help recover from multiple simultaneous failures..
We do incrementals every night and two months' worth are saved onto
another removable disk so there is some redundancy. Bacula keeps track
of all the retention periods and recycles volumes (files, in this case)
when their retention periods expire.
Total is about 60GB after compression.
Karl Cunningham
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
