Hello, and thank you all for your suggestions.
Just to make sure my hardware is still working I installed gtar and dumped
about 10tb to tape, and it completed without errors.
Perhaps I should have included this information in the first email, but I’ve
tried several combinations of parameters in the bacula-sd.conf, and it failed
each time. Here are the parts I’ve changed:
First try:
Offline On Unmount = no
Hardware End of Medium = no
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
Second Try:
Device {
Name = QuantumLTO
Media Type = LTO6
Device Type = Tape
ArchiveDevice = /dev/nsa0
LabelMedia = yes
# Random Access = yes
Requires Mount = no
AutomaticMount = yes
RemovableMedia = yes
Always Open = yes
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = yes
Fast Forward Space File = yes
TWO EOF = yes
Third Try:
Device {
Name = QuantumLTO
Media Type = LTO6
Device Type = Tape
ArchiveDevice = /dev/nsa0
Description = "LTO-6 for FreeBSD"
LabelMedia = yes
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes
RemovableMedia = yes
Offline On Unmount = no
Hardware End of Medium = no
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
Fourth Try:
Device {
Name = QuantumLTO
Media Type = LTO6
Device Type = Tape
ArchiveDevice = /dev/nsa0
Description = "LTO-6 for FreeBSD"
LabelMedia = yes
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes
RemovableMedia = yes
Offline On Unmount = no
Hardware End of Medium = no # Noted as FreeBSD specific
BSF at EOM = no # Noted as FreeBSD specific
Backward Space Record = no # Noted as FreeBSD specific
Fast Forward Space File = yes # Noted as FreeBSD specific
TWO EOF = no # Noted as FreeBSD specific
And today, as I type this I’m trying a btape fill test with:
Device {
Name = QuantumLTO
Media Type = LTO6
Device Type = Tape
ArchiveDevice = /dev/nsa0
Description = "LTO-6 for FreeBSD"
LabelMedia = yes
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes
RemovableMedia = yes
Offline On Unmount = no
Hardware End of Medium = no # Noted as FreeBSD specific
BSF at EOM = yes # Support List Recommendation
Backward Space Record = yes # Support List Recommendation
Fast Forward Space File = yes # Noted as FreeBSD specific
TWO EOF = yes # Support List Recommendation
Minimum Block Size = 64512
Maximum Block Size = 64512
Which is similar to my third try, with the exceptions of Backward Space Record,
Fast Forward Space File, and also the addition of the Min and Max Block Size
directives.
So at this point my question is this: is there a smart way to identify the
correct entries for my hardware? I’ve re-read the docs from quantum but clearly
I’m still flailing. The trial-and-error approach wouldn’t be so bad if it
didn’t take 11 hours to write 2.5tb, then a short while to begin the second
tape, then begin the unfill portion of the test, then eventually fail. It’s
basically a full calendar day with each config file guess iteration.
As an aside, gtar wrote to tape at almost exactly twice the speed that I’m
seeing in the btape test. My disk arrays are showing 300+mb/s for random reads,
so they’re not the bottleneck. Almost immediately after I get this multi-tape
dump and restore working in bacula I’ll be needing to address the horrible
speeds I’m seeing. I do notice a lot of “shoe shining” while running btape
fill, and nothing is being written to the spool directory (which is ssd) so
maybe the real backups will be faster. We’ll see.
Thanks again,
Simon
> On Mar 1, 2016, at 8:42 AM, Martin Simmons <mar...@lispworks.com> wrote:
>
>>>>>> On Tue, 1 Mar 2016 14:07:55 +0100, Cejka Rudolf said:
>>
>> Simon Templar wrote (2016/02/29):
>>> I've set up bacula 7.2 on my FreeBSD server using Postgres as the
>>> backend database.
>>
>> Which FreeBSD version? According to the mt status it seems to be
>> sufficiently fresh.
>>
>>> Device {
>>> ...
>>> Hardware End of Medium = no # Noted as FreeBSD specific
>>> BSF at EOM = no # Noted as FreeBSD specific
>>> Backward Space Record = no # Noted as FreeBSD specific
>>> Fast Forward Space File = yes # Noted as FreeBSD specific
>>> TWO EOF = no # Noted as FreeBSD specific
>>
>> Where did you get this?
>>
>> Try this:
>>
>> BSF at EOM = yes
>> TWO EOF = yes
>> Hardware End of Medium = no # maybe not needed now, but there is no
>> # performance impact, so let's start with it
>> Backward Space Record = yes # not needed, changed to yes is the default
>> Fast Forward Space File = yes # not needed, yes is the default
>
> There is no "correct" value for all hardware. I needed TWO EOF = yes etc for
> DDS drive on FreeBSD 4, but for an HP LTO-1 drive on FreeBSD 8 I needed this:
>
> Hardware End of Medium = no
> BSF at EOM = no
> Backward Space Record = yes
> Backward Space File = yes
> Fast Forward Space File = yes
> TWO EOF = no
>
> __Martin
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
