Hello Georg, You can also have your catalog backup in various others places - storages/pools (1 GB is easy to have in lots of different places assuring you will always have your sql dump for a disaster recovery) to avoid the need of using bscan to restore media/jobs/files into catalog.
And yes, you can do the same with tape storage if you have a tape library. You can load volumes into the tape and run your command against an output of a "mtx-changer listall" command :) You´re welcome! Best regards, Ana On Fri, Oct 2, 2015 at 6:41 AM, Georg Altmann <geo...@george-net.de> wrote: > > > Am 02.10.2015 um 11:41 schrieb Georg Altmann: > > > > > > Am 01.10.2015 um 19:58 schrieb John Drescher: > >>> Yes, I know this, but AFAIK this does not apply in a disaster recovery > >>> situation where you have to scan volumes with bscan. > >>> In this situation I figure it would be very useful to find the last > >>> backups of the catalog and the bacula server to feed them to bscan. > >>> With large volumes bscan will sit there for a long time, scanning all > >>> volumes. > >>> > >> > >> Put the catalog backup (and bacula configs) in its own pool so its > >> easy to find. Then restore the catalog (and configs) with bscan and > >> then you should not need to bscan individual volumes. > > > > Yes that would be a solution. > > > > I did a disaster recovery exercise yesterday. After setting up the > > machine and getting bacula up and running with the file storage I found > > it easy enough to scan the last 10 backups or so to find a recent > catalog. > > I know that my catalog backups are relatively small, i.e. < 1 GB. So I > > can avoid scanning the large ones and find the catalog backup quickly. > > This is what works for me: > > > > % cd /vol/bacula > > % ls | tail -n 10 | while read f ; do if [ $(du -b "$f" | cut -f1) -le > > $((1024*1024*1024)) ] ; then bscan "/vol/bacula/$f"; fi ; done > > % > > > > Here /vol/bacula is where the file storage is mounted. tail -n 10 takes > > the 10 latest files by date. The if with du tests for file sizes smaller > > than 1 GB. bscan needs a full path to identify the device. To actually > > add catalog entries use bscan -s. > > > > So unless one has a very large amount of backups/volumes this should be > > practical enough without the need to put catalog backups in a separate > > pool or putting job names in volume labels. I will stick with plain > > numbered volume labels. End of story. Just in case: This approach > > obviously does not work with tape storage. > > > > Thanks for all the input! > > > > > > Regards, > > Georg > > > > -- > PGP-Key: 0x1E320E65 > D150 7783 A0D1 7507 1266 C5B3 BBF1 9C42 1E32 0E65 > > I don't like the idea of secret agencies to analyse and archive > personal communication. GnuPG is available as open source, free as as in > freedom, as a countermeasure. I use http://www.enigmail.net/ for Mozilla > Thunderbird. If you can, please use a frontend of your choice to send me > encrypted e-mail. See http://www.gnupg.org/ for an overview. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel > >
------------------------------------------------------------------------------
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
