Bacula-users

Re: [Bacula-users] Bacula Full/Inc Questions (Noob)

2010-04-16 20:44:42
Subject: Re: [Bacula-users] Bacula Full/Inc Questions (Noob)
From: Craig Ringer <craig AT postnewspapers.com DOT au>
To: bacula-users AT lists.sourceforge DOT net
Date: Sat, 17 Apr 2010 08:41:44 +0800
On 17/04/2010 3:30 AM, ikkysleepy wrote:
>
>
>> If you really, really, really want to keep only one volume, you can find
>> out how in the manual. But honestly, you're better off with even a RAID0
>> array (!!) on your backup server if that gives you room for two backup
>> sets, rather than just trying to have one. Better again, buy two more
>> disks and use RAID 5.
>
>
> We already have our server set to Raid 0

Er, eek?!?

I was mentioning RAID 0 as an absolute last resort 
can't-afford-anything-else option.

You realize that RAID 0 *masively* increases the chance of total loss of 
data across the entire array if one drive develops a fault, right? It's 
not just "chance_of_disk_failure * n drives" either - the chance of any 
one drive in a set failing is much larger, since you're really computing 
the chance of *no* disk in the set failing.

Because RAID 0 stripes data, if you lose one disk you lose all data in 
the array.

The absolute minimum I'd ever consider is a RAID 5 array - and for more 
than about six disks, that gets pretty dangerous too and I switch to 
RAID 6 for anything important.

If you must use RAID 0, you need to have regular S.M.A.R.T testing 
running on the drives to detect media errors - so you need smartd 
configured and running. You should have that on any RAIDed server 
anyway, but it's utterly crucial for risky RAID 0 setups.

You also need to know that if tomorrow all that data is gone, you don't 
actually mind.

> and want external backups,
> so  we can alternate the drives to take home. I think I am just going
 > to get 2 external HDD, each 1.5 or 2 TB, and plan on
 > having 2 volumes each.

OK, that would've been good to know. You want to manage volumes quite 
differently if you're using removable HDDs.

>> If your file set is fairly static in nature - it's only added to, so
>> there's not much "churn" in old files - you can instead take a single
>> full backup manually, and then do daily incrementals thereafter,
>> consolidating them into differentials say weekly. You never need to
>> replace the full backup. However, this only works IF:
>>
>> - You don't generally delete files; and
>> - *YOU TEST YOUR BACKUPS REGULARLY TO MAKE SURE THE FULL BACKUP
>> VOLUME IS UNDAMAGED AND READABLE*.
>
> so what's the benefits of using a diff if I have all the increments?

You set a (say) 2 week retention period on the incrementals, so they 
expire and get recycled after you have one or two differentials to 
replace them. And you recycle the differentials so you only keep two 
around (plus one ready to write) at any one time.

This won't save much backup in an append-only storage situation, but 
it'll speed restores massively. If you don't care for the complexity, 
you can just retain your incrementals forever instead and not bother 
with differentials.

> The diff seems like it will only do a diff from the full not another
> diff, is that correct?

Yes, that's the point.

> I was thinking Full + Incremental for 3 months.
> Initially I was thinking Full + Inc. Tue-Sun then a Diff on Mondays, but
> I didn't see any benefit from doing a diff on a weekly basics.

There is no benefit unless you're recycling the incrementals on a 
shorter schedule.

--
Craig Ringer

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users