> -----Original Message----- > From: Ralf Gross [mailto:ralf-li...@ralfgross.de] > Sent: Saturday, November 28, 2009 6:23 AM > To: bacula-users@lists.sourceforge.net > Cc: bacula-de...@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
