> On Apr 26, 2007, at 8:16 AM, Ryan Novosielski wrote: > > This has been rejected before, and the reason being that you really > > don't want to have to have a database in order to read your tapes.
I would disagree with you here. What I want is to get back to a controlled restore process that non-system admin people can run as quickly as I possibly can. I need to get the tool working ASAP, then I can hand it over to the operators to do the rest of the restores while I go fix other important stuff, without worrying that they'll mount the wrong tape or restore the wrong stuff. Handling the storage of the database contents is what the standalone utilities are for. Dump the database to a separate pool of tapes, possibly with the binaries and DBMS engine. In a disaster, use brestore (or tar, if one has been really paranoid), manually insert the tape containing the database and binaries, restore those, bring up the database, and start the full restore. Brestore already takes command line arguments for all the necessary information for the database restore; once that's back, then you've got the data you need to run normally. Extra points if the client configuration data is also stored in the database: I get an OS booted on the client box, put a Bacula client on it and give it the client ID and address of the database server. Boom, restore, back in business. This is a typical incremental DR bootstrap restore technique for any large organization, nothing unique here. Nothing changes the tape format of the data, and it's simpler than recreating the config files from scratch and recreating the database by reading all the tapes (which may be a LOT of tapes in a large-scale deployment -- I've got more than 5,000 Bacula data tapes in one location alone). With this approach, you only need know which tape holds the latest database backup, rather than what each data tape holds -- it also makes it easier to duplicate it and send it offsite. Prevents accidentally restoring the wrong data, too -- or worst case, you restore an old database backup, which is easily remedied. > > If > > you have an emergency that you need to recover from, the ability to > > put > > the config files in a directory and take off running is rather > > important. So you're either a) recreating the config from scratch, or b) restoring the config from somewhere else. A is likely to cause you problems in large deployments in that it relies on having all the necessary configuration information available, including encryption keys and certificates, in a highly chaotic situation, and isn't B pretty much what I just suggested? This is going to be even more complex with encrypted files and tapes. In that scenario, you may not be ABLE to read the tapes to rebuild the database. Last, how can we get configuration data to incorporate into a CMDB if we have to interrogate every single machine to get a configuration picture? Better we start thinking about that now, if Bacula is going to make it in the enterprise space. > Brainstorming idea: XML with Schema validation? > > * The config would be a plain file and portable. Ugh. "plain XML" is a matter of opinion -- XML of any real complexity couldn't be hand-coded. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
