<[EMAIL PROTECTED]> aka Dan Langille schrieb mit Datum Fri, 08 Feb 2008 07:15:06 -0500 in m2n.bacula.users:
|Peter Much wrote: |> <[EMAIL PROTECTED]> aka John Drescher schrieb |> mit Datum Thu, 7 Feb 2008 20:10:41 -0500 in m2n.bacula.users: |> |> |> Fast Forward Space File = no |> | |> |Here is the problem. Set this to yes (provided your system supports |> |this) and it will skip over the other jobs. |> |> Whew, but that is the official recommendation for FreeBSD from the |> Bacula Users Guide: |> |> Hardware End of Medium = no |> BSF at EOM = yes |> Backward Space Record = no |> Backward Space File = no |> Fast Forward Space File = no |> TWO EOF = yes | |Tapes vary. So do the settings. :) Sure, You're right. Sadly, I did not find much statements about the EXB8505's behaviour on the net. (Maybe they are too outfashioned - while I think they are just perfectly economic :)) But all the ressources on the net say: if you change FFSF to 'yes' on FreeBSD, then do also change eotmodel to 1. And if I do that, then I do not know if my old backup will still work (which is a selfwritten shellscript that does its job for nearly 10 years now, and which also does create many files per tape). So if I now start tuning this thing also, then I will get just too many open issues, and slowly but certainly loose view on what I'm changing and what it implies. Currently I have already seven or eight issues where I might need to optimize Bacula behaviour in order to get what I want. So, one after another... |You are manually adjusting the Catalog? Only during evaluation. Afterwards I create a daemon to do it. |> And, I have just noticed, that if I would write the backup directly |> to tape, then the catalog entries are created correct! | |What do you mean? Ehh...? Well, the supposedly "normal" way of doing a backup is, when the FD transfers the files to the SD and the SD will write the data onto a physical tape in a tape drive. And this is what I do *not*. I let all backup data be written onto *Files* storage pools on a disk. And at a later time I run jobs with "Type=Migrate" - and they copy the data to the tapes and delete it from the Files pools. This is the way all the major companies run their backup solutions. The main advantage is: if you want to restore a file, and the file is less than two days old, you get it *immediately*, without a tape mount. And nevertheless you do not need to *know* whether your file is on disk or on tape: the storage system will just fetch it for you. And the fascinating thing is: Bacula seems to have all these building-blocks for an enterprise-style storage solution - only some seem not yet all too well tested... rgds, PMc ------------------------------------------------------------------------- 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
