Hi, 08.02.2008 21:10, Philipp Geschke wrote: > Dear list, > > I have a nice backupserver running with bacula, tls and pki encryption > and everything set up, which works great! But....! > > I'm struggling with this question for quite a few weeks now, without > being able to find a solution that feels "right". > > I want to achieve a 3 Level Off-Site Backup. > Let me put down a little example for you, so you can see, what exactly I > want. > > Let's say I have Client1, which is backed up to file by ServerA. Both > boxes, even if in different fire safety areas, stand in one datacenter.
Ok, just to make sure I understand correctly: You back up to file volumes? > Let's assume I want to be protected against a disaster, in which the > whole datacenter gets destroyed. So I want to copy the Backup of Client1 > to ServerB, wich is located in another datacenter in that city. > But I don't want to pull 2 separate backups, so I want to use the > daytime, to copy the original Backup from ServerA to ServerB. > > To complicate things a little more, I want to protect myself against a > disaster, which would destroy the whole city, or even the whole country, > so I want to copy the backup of Client1 from ServerA to ServerC, which > is located in another country. This is pretty much negligible, since it > will pretty much work the same way my first copy does. > > Now my question is, how would you accomplish this? rsync. > I came up with a few ideas, but none satisfies me completely. > > > 1.) Copy the File-Tapes from ServerA to ServerB, dump the catalog (mysql > database), and safe that dump. This way I could always restore the > director of ServerA with the files on ServerB. Eventually my Backup is > safe, but it is complicated to restore. Not necessarily. You can implement something where you dump the catalog for the catalog backup (which you probably already do) but, instead of deleting that database dump, you keep it. Now, in case of a serious problem in Bacula or your catalog database, after a days backups you have the complete set of data you need to create a new Bacula instance, with all the existing data. If you rsync that whole file set (which would best include your configuration files, bootstrap files, and source code of the Bacula you're running, along with the ./configure line) to your other two sites, you should have what you want: The ability to quickly set up a new Bacula instance with all the data from the original one. In case you only lose your volumes and need to access them, it should be easily possible to either copy the remote volumes to the local site, or even access them remotely. > Plus I don't feel comfortable to > encapsulate the File-Tapes. No need to do that, as you can recreate the existing file structure easily. > Would that become a problem? As far as I > see it, I wouldn't be able to restore client-based. I'd have to restore > a whole tape, and this way, restore all clients backup on ServerA. Erm... no. Unless you're talking about bextract without a bootstrap file. Bootstrap files are important :-) > Not > great, but hey, If my whole live-datacenter gets destroyed, this sounds > like a reasonable kind of work. > > I see another option, which would be to just copy the files via nfs or > iSCSI, or something, which I actually would prefer, because it would > work without encapsulation. I'd end up with a "dumb" backup, with which > I would be able to restore my original director by hand. Yup, that's close to what I suggested, but rsync is a useful tool here as it will not blindly copy unmodified files each time. > Remarks? What do you think? Did I miss something? It doesn't sound great > to me, but would work, as far as my (limited) knowledge goes. Well, the source code, configuration files, and everything else you need to set up a new Bacula instance. If you want to set up a second, emergency, DIR things are only a tiny bit more complicated: I'd do that by setting up a slave catalog database remotely, install and test a Bacula DIR and SD there, sync the volumes and configuration, and only start the DIR and SD when necessary, i.e. when your primary site fails and when you do your routine test (which you run, hopefully :-) The catalog, in such a scenario, should always be up to date without the need to transfer whole dumps continously. > 2.) Backup using a second director, so "split" the backup. > Each of the above mentioned backup servers is going to be a full bacula > install anyway (because it will act as the backupserver for the site it > is located at), so I could use it. Well, that makes things more interesting... basically, I'd recommend to only rune on DIR as it keeps the setup much easier to manage. If, for example due to strict separation between the facilities, you have to run several DIRs, I'd simply multiply my primary layout, i.e. treat all the DIRs as independent instances. You can, though, have SDs local at the facilities and would need only a bit of thought and planning to be able to move the volumes around, in case of an emergency. > I could, let's say, do a weekly full > backup directly to the other server. This way it wouldn't be any kind of > "hand work", but I'd split up my backup, and double my configuration > (actually it would be times three, for 3 servers), because all servers > need the client configuration, and all client's need to know the 3 servers. > > 3.) Clone the backup servers > This is an option I pretty much dismissed already. While it would make > sure that I have a fully working backup system,it conflicts with the > idea of each backupserver being master for it's site, and only copying > *some* but not *all* client's backup. > A slightly modified version of this would be to use 3 directors and > storage demons on each box, having a clone of each dir and sd on each > machine. Still not very much appealing. I'd do it with one DIR, three SDs, and two standby/emergency DIRs with slave catalog DBs. > > > I'm not sure, if I have to be able to restore easily from all servers > but the original box. I mean, the backup is really just for bad bad > baaaaad situations, not for everyday use. But if there is an option that > would include an easy restore, hey, you have my attention! Ok... just make sure that your client addresses work across all three sites, and you have the SD setups you'll need. In case one SD is lost, and you need to restore its data, just change the address it is known under in the DIR configuration and you're ready. Sound's good, right? ;-) > > > So, bottom line is - I can't figure out how I can manage this, I need > some ideas, so please, dear list, fill my brain with ideas that will > give me a murder headache for a bunch of days! Actually, I hope this was clear enough to not push you into a headache :-) Diagrams, images and configuration snippets only for money ;-) Arno > > > Thank you gents, and ladies, of course! > > Best Regards, > Philipp > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
