DaZZa <[email protected]> writes:
> On Sun, Aug 22, 2010 at 4:54 PM, james <[email protected]> wrote:
>
>> I've spent many hours with pencil and paper, I certain, but am asking in
>> case someone older-n-wiser can offer sage words:
[...]
> Yup, that's the biggest failings with most "commercially acceptable" backup
> regimes.
>
> It's an offset of cost (in tapes) against reliability. If you want to be 99%
> guaranteed[1] to be able to recover any file which was saved, your only
> option is to take a daily full backup. Any grandfather/father/son schema
> will eventually lead to the possibility for files going missing.
*nod* For what it is worth, this is why my usual backup deployment is
wonderful in the common case (backup server is alive), and very, very slow in
the worst case (backup server isn't).
Specifically, I deploy BackupPC or some similar online, disk-based,
deduplicating backup system to provide the vast majority of operations.
This gives me good responsiveness to most failures: lost file or machine?
No problem, since the data is there on disk, and you are not very far from
recovering it to whatever target you need.
For disasters tape is still good: take regular full dumps of the backup
filesystem (or with incrementals, if the cost/benefit works for you) to allow
you to recover the backup server if you lose it.
That makes a full recovery harder: you have to rebuild the backup server, then
build whatever servers are critical. OTOH, it also makes for faster
performance in that second phase of recovery because you are no longer limited
by tape restore speed after that one machine. :)
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
