Re: [Bacula-users] Fwd: no fsf on restore?

[Dan L. <da...@la...>]

Peter Much wrote:
> <da...@la...> aka Dan Langille  schrieb
> mit Datum Fri, 08 Feb 2008 07:15:06 -0500 in m2n.bacula.users:
> 
> |Peter Much wrote:
> |> <dre...@gm...> 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.

Does the Bacula doc say that?

If not, what resources?  (he asked, hoping it wasn't his)

 > 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...

Any changes you make to the tape config should be followed by a full btape 
test.  To Do The Right Thing.

> |You are manually adjusting the Catalog?
> 
> Only during evaluation. Afterwards I create a daemon to do it.

I meant manually as in 'Bacula is not doing it'.

Adjustments to the Catalog outside Bacula is, umm, not recommended.

> |> 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.

Sounds pretty normal.  At least within Bacula.

Now I know what you meant by "directly".

> 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...

That's quite possible.  I suggest starting a new thread.  In it, please 
describe the problem (Catalog errors after tape migration) and indicate the 
Catalog situation before and after your correction.  That might be enough 
for us to know the cause and cure of the problem.

Of course, if you already know the cure, just bypass the above and post to 
devel@.  :)

-- 
Dan Langille - http://www.langille.org/
BSDCan - The Technical BSD Conference: http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:    http://www.pgcon.org/