Hi, 01.11.2007 15:55,, Olaf Zevenboom wrote:: > Hi List, > > I have a quistion about the correctness of the catalog > given a certain moment. I have a somewhat different > setup than most setups with it's pros and cons. > > We are using a centralbackup server running Debian and > Bacula 2.0.0. It has a huge diskspace. Besides that it > is connected to a single slot tapedrive. > > The backup config consists of: > All servers backup to this backupserver either through > Bacula or rsync to two directories called > /home/system/bacula_localstorage and > /home/system/rsync_localstorage
That's not so uncommon as you seem to think :-) > Also the calalogdump and the local system are stored > in /home/system/bacula_storage so that in practice > this dir contains 2 bacula backupfiles and a db dump > of the catalog. Does it really have a catalog dump, or do you refer to the actual database files? Backing these up while the database is running does, usually, not provide you with a useful catalog backup. > After all jobs are executed to backup stuff from the > LAN to these dirs another Bacula job is run to backup > (not copy or clone to my regret) these two dirs to > tape. Ok so far. > We have single tapes (no autoloader) for > monday-thursday which are recycled each week and 6 > friday/week tapes. The rsync/bacula backups from > servers to the backupserver run all 7 days of the > week. > > Advantages: > - network usage / backup time is limited > - restores of data from the previous day is very quick > > Disadvantages: > - we are making a backup of a backup, so no easy and > quick file recovery can be issued when data older than > a single day needs to be restored. > - a lot of diskspace on the backupserver is needed Disk space is cheap :-) > - the catalog seems to be foobar when a bacula restore > from tape is issued. This is my main issue. That is indeed a serious issue. > QUESTIONS > 1. I understand that also in the latest release there > is only a move of bacula-backup from one source (disk) > to another (tape) source is supported but not a copy. > Is this correct and will it be supported in the (near) > future? Your understanding is correct. The answer to the second question depends on your definition of "near future" ;-) I wouldn't expect this in the next few weeks. In a few months - perhaps. In a few years - quite probable. > 2. It seems I have to use tools like bscan etc. as if > I was using a tape which is not in the catalogue. This > seems a bit wierd as most files are not mutated, > (re)moved, so for instance a "thursday-backup" from > one week will be more or less the same as a > "thursday-backup" from another week. Only the data on > disk is mutated, the catalog will be the same after a > restore from tape to the backupserver-disk. I'm not sure I understand you here... in the catalog, there is not only a list of volumes, but also the positions of files backed up inside their volumes is stored there. If the catalog does not represent the actual volume contents, you're in deep trouble. > Yet the > catalog for "thursday" shows up empty from bconsole. > > What am I doing wrong? Where is the flaw in my > assumptions? Should I have restored the catalog as > well? What should have been the correct procedure(s)? I'll assume a certain situation for an explanation: You have a volume "thursday" on disk. This is then backed up to tape, along with the catalog current at that time. Let's call this time t0. So you have some volumes - at least "thursday" from t0 on tape, along with the catalog at time t0. (I assume you back up a catalog dump, not the database files...) A week later, your volume thursday is recycled and reused. You then put "thursday"(t1) and catalog(t1) to tape. A day later you need to restore data from "thursday"(t0). Is this your situation? You now need the "thursday"(t0) back on disk, and usable by Bacula. To achieve this, you restore "thursday"(t0) and the catalog(t0) dump. You now have (at least) three options: - access "thursday"(t0) with the catalog(t1). This will fail, because the catalog does not hold the data about the actual contents of the volume "thursday". - install the old dump of the catalog, thus recreating catalog(t0). Now the catalog is useful for accessing the current "thursday" volume. Unfortunately, the other volume contents are not in sync with the catalog. You can work with "thursday", but using other volumes will not be a good idea. - drop the information regarding "thursday" from the catalog and bscan the contents of "thursday" into it. This will make the catalog consistent with your volumes, but you lose the abilitiy to access "thursday"(t1) now. I wouldn't do any of the above, as it either breaks your Bacula catalog, or you effectively lose access to current backup data. What you'd need, instead, would be to add the "thursday(t0) volume to the catalog without losing information on "thursday"(t1). Trying to rename the restored "thursday"(t0) to another volume name might be one approach; I haven't tried this, but a simple renaming of the file might be all you need. Then bscan this volume. Althernatively, you might try to recreate the information from "thursday"(t0) from the catalog(t0) dump, and only add that information to the catalog. This is probably a really difficult thing... What I'd do in your situation is back up all your clients to the backup server using rsync, and then back up that file set using Bacula. Restore to a different location when you need older files, and you won't screw up your on-disk copies of the current state of your backup clients. Or use Bacula (and possible rsync) to collect data from the clients, but don't store these backups to tape using Bacula. You'd have to re-invent much of the volume management Bacula does to be able to quickly find and restore from the tapes you need, but that could be done. And, finally, what I'd *really* do if I were you: Don't reuse the same volumes on disk as this creates problems when you want to access older generations of them. Instead, use automatic labeling and make sure volumes are not recycled. Once a volume is stored to tape (using Bacula, in this case :-) you can delete it from the catalog or simply disable it. Then you can delete the corresponding disk file and thus reclaim the space the volumes need. In case of a restore from tape, you'd simply restore the file to the usual volume location, where it won't clash with existing volumes as the names are unique. If the information is not purged from the catalog, you could immediately (or after a 'update volume enabled=yes thursday-0006') start a restore from it, without needing to use bscan. The few extra management task could be easily scripted, I think: - Find volume files already backed up to tape (probably only work on the oldest files and stop once you've got enough disk space) - Feed some commands regarding them to bconsole - Delete the volume files Do this as an admin job as the last thing in your backup schedule, and you won't have to do much manually. Sounds like a few hours of work, but that should save you lots of work and many headaches later. > Besides this not so big issue I am quite fond of > Bacula although it took quite some time to get things > to work the way I wanted it. I really wonder if they work the way you want them to work, or only *seem* to do so ;-) > Thanking you in advance, > Olaf Arno > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
