Re: [Bacula-users] RFC: backing up hundreds of TB


> -----Original Message-----
> From: Ralf Gross [mailto:Ralf-Lists AT ralfgross DOT de]
> Sent: Saturday, November 28, 2009 6:23 AM
> To: bacula-users AT lists.sourceforge DOT net
> Cc: bacula-devel AT lists.sourceforge DOT net
> Subject: Re: [Bacula-users] RFC: backing up hundreds of TB
> 
> Kevin Keane schrieb:
> > Just a thought... If I understand you correctly, the files never
> > change once they are created? In that case, your best bet might be
> > to use a copy-based scheme for backup.
> 
> 
> Yes, the files won't change. They are mostly raw camera data. They
> will be read again, but not changed.
> 
> 
> > I'd create two directories on your main server.
> >
> > /current /to_backup
> >
> > Both on the same file system.
> >
> > /current (or whatever you want to call it) holds all the files.
> > /to_backup holds hard links to only those files in current that
> > haven't been backed up yet. You can use a script to identify those
> > current files, for instance by time stamp, a checksum or the like.
> 
> Hm, wouldn't the Accurate Backup feature do the same and be less error
> prone?

I think you may be right. I haven't upgraded to bacula 3.x yet, so I haven't 
looked into that.

In any case, my script-based scheme would result in many smaller (and possibly 
more manageable) backups, instead of accurate backup consolidating everything 
into one huge blob (at least that's how I understand accurate backup to work).

> > The actual backup can be done several different ways. You could use
> > bacula. Or you could simply use cp, scp, rsync or similar. After the
> > backup has completed, you delete the links in /to_backup.
> >
> > That way, you only back up files that have changed, and still have a
> > full set of files on the backup.
> 
> I'm not sure how this will work in case of a restore. In general I
> don't like such "hacks" ;) It could be an additional cause of erorrs
> and it might be hard to check if the backup is really working.

Yeah, I hear you. For this type of data, I would actually prefer to keep it 
outside Bacula (and use cp etc.) for exactly that reason. You won't have to dig 
through the bacula database and hope that all the tapes (or hard disk files) 
match the db or, worse, re-extract terabytes of data with bextract. All you 
have to do is run an ls -lah and confirm that the right files and file sizes 
still exist. Restore would be as simple as copying the correct file back to its 
original location.

Come to think about it - I don't recall exactly what type of disaster you were 
trying to protect against. That may well make a difference in what the best 
strategy is.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users