Hey! Unfortunatelly I already used that trick :), the firmware has been upgraded for both the drive and the autochanger... And it didn't change at all.
I had a bunch of backup launched, and it seems that the further it has to seek on the take to position to append data, the more subject of errors it is. The 5 1st jobs on the tape are usually allright, but then it begins to be unpredictive. To go on, I've noticed that I can update the tape status and put it back from "Error" to "Append", and 50% of the time the job waiting for a new tape starts successfully. I have a pack of 16 tapes, and it seems it's with all of them. Now I have a tape that is stuck to 100G, and can't write anything further, and one that has successfully gone to 130Gb (each test job is 12 Gb). I really like bacula and how it manage the pools, volumes, schedules and clients, and I 'll try to stay with. Now i'm trying to setup a workaround, to use the tapes only once : to write only full bakckups once a week, 'cause that machine is a dedicated backup server with loads of disc space, and incremental are done with "rsync" on disk. Then I can maybe just dump the local filesystem on 2 tapes (i need 1.5Tb for every full backup, so it means 2x LTO4 800Gb-1.6TB). For Hayden : the "cap" is a command of the "btape" utility, that shows every configuration option set in the storage config file for that device. Just type "cap" in btape... Regards Yvan Broccard Thomas Bennett wrote: > It might help to update your firmware if it is not current. > > While setting up Bacula for the first time with RHEL 5.2 and the TL2000 I ran > btape and then cap which showed the tape was append. I tried to run the > test > and it failed. I ran cap again and it showed !append. This happened every > time I restarted btape without unmounting the tape. Also, it appears that > Yosemite Backup partitioned my tapes. I would run btape erase and it would > run just a couple of seconds. Then I immediatly again and would take over an > hour. After trying several other possible solutions I went to the dell site > and found there was new firmware and a diagnostics and firmware upgrade tool > > ITDT - DELL Customer Release > > which can be downloaded at > > http://support.dell.com/support/downloads/index.aspx?c=ca&l=en&s=gen&SystemID=PWV_TL2000 > > just choose your OS and Language. I updated the TL-2000 firmware and ran the > ITDT diagnostics which wrote to tapes with no problem. After that, the test > in btape ran fine. Then I had an issue with my backups running but after > upgrading to PostgreSQL 8.4 backups ran fine. > > > Here are my confs if that might help. > > >From bacula-dir.conf > > #Definition of LTO-4 storage > Storage { > Name = TL2000 > Address = 192.168.0.1 # N.B. Use a fully qualified name here > SDPort = 9103 > Password = "xxxxxxxxx" # password for Storage daemon > Device = TL2000 # must be same as Device in Storage daemon > Media Type = LTO-4 # must be same as MediaType in Storage daemon > Autochanger = yes # enable for autochanger device > } > > >From bacula-sd.conf > > Autochanger{ > Name = TL2000 > Device = LTO-4 > Changer Device = /dev/sg4 > Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" > } > > Device{ > Name = LTO-4 > Drive Index = 0 > Autochanger = yes > Device Type = Tape > Media Type = LTO-4 > LabelMedia = yes > Archive Device = /dev/nst0 > Always Open = yes > AutomaticMount = yes > RemovableMedia = yes > RandomAccess = no > } > > > By the way, there seems to be some disagreement between btape and bacula-sd > when using the -t switch for testing > > using > Storage { # definition of myself > Name = xyz-sd > WorkingDirectory = "/var/bacula/working" > Pid Directory = "/var/run" > Maximum Concurrent Jobs = 20 > SDAddresses = {ip={ > addr = 192.168.0.1; port= 9103} > } > } > > btape complains about SDAddresses format. > > Thomas > > > > > > On Friday 08 May 2009 03:24:56 yvan wrote: > >> Hi, >> here is the configuration file. >> Yesterday I blanked 2 tapes, and assignated one to a pool "Daily" and >> one to the pool "Weekly". I ran btape fill and test with successs. >> I then started full backup jobs of 12Gb in loop. Got that result: >> >> Job A Daily, EOD 12GB ok >> Job B Weekly, EOD 12GB ok >> Job A Daily, EOD 24GB ok >> Job B Weekly, EOD 24GB ok >> Job A Daily, EOD 36GB ok >> Job B Weekly, EOD 36GB ok >> Job A Daily, Starting, unloading tape from JOB B and i got the "MTEOM" >> error at this point. (Could not append to end of data) >> >> 08-May 09:16 setmseblx0007-sd JobId 181: Error: Unable to position to >> end of data on device "IBMLTO4" (/dev/nst0): ERR=dev.c:1354 ioctl MTFSF >> error on "IBMLTO4" (/dev/nst0). ERR=Input/output error. >> >> This morning I updated the status of that volume from the console, >> putting it to append again, and the job started and finished successfully ! >> There is a "sleep 60" after the load in my mtx-changer script, and a >> "sleep 180" after the unload. Should be enough no ? when I do it >> manually with "mtx" it takes something like 15 seconds. >> >> Now the 4th "Job B" sent me the MTEOM error as well at the same position >> on the tape. >> >> Here is the configuration file : >> >> Device { >> Name = IBMLTO4 >> Media Type = LTO4 >> Device Type = tape >> Archive Device = /dev/nst0 >> Autochanger = yes >> #Changer Device = /dev/sg3 >> #Alert Command = "sh -c 'tapeinfo -f %c | grep -i tapealert'" >> Label Type = IBM >> Check Labels = yes >> LabelMedia = No; >> Random Access = No; >> RandomAccess = No; # which one is the correct >> syntax ? >> AutomaticMount = yes; # when device opened, read it >> RemovableMedia = yes; >> AlwaysOpen = yes >> Requires Mount = no; >> >> #Maximum Job Spool Size = 2G # default is unlimited >> #Spool Directory = "/export/shared/spool" >> >> # things to try: >> TWO EOF = No # tried but append test fails. default is >> No #Offline On Unmount = no # default is No >> Hardware End of Medium = no # default is Yes >> BSF at EOM = No; # default is No >> #Backward Space Record = no # default is Yes for >> tape device >> #Backward Space File = no # >> # Use MTIOCGET = Yes # only need to no on >> some ***BSD systems >> Fast Forward Space File = no # tried, not better, got >> MTFSF error >> # This line required if above HEOM is >> set to "No" >> Volume Poll Interval = 300 # Poll the drive to seek the status >> } >> >> Autochanger { >> Name = TL2000 >> Device = IBMLTO4 >> Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" >> Changer Device = /dev/sg3 # already set in the device resource. both >> are possibles >> } >> >> Thank you all for your help ! >> >> Hayden Katzenellenbogen wrote: >> >>> Yvan, >>> >>> Could you paste a copy of your bacula-sd.conf. The device and auto >>> changer sections. >>> >>> I have found that if I load the tape into the drive then run the fill >>> test it will not give the WEOF error, but when it loads the second tape >>> it will give the WEOF error. >>> >>> If I have any other tape in the drive before I start and btape loads tape >>> one for the fill test I get the WEOF error on both the first and second >>> tape. >>> >>> The btape test runs 100% including the append test. Here is a snippet of >>> the last fill test I ran. I had already loaded tape 1 into the drive >>> before start. I also did an erase on both tapes using John's two mt >>> commands. >>> >>> Also would it make a difference that I am running this on Ubuntu 8.0.4 >>> LTS and using a fiber channel drive? >>> >>> H >>> >>> r...@archive:~/bacula/etc# ../bin/btape -c bacula-sd.conf /dev/nst0 >>> Tape block granularity is 1024 bytes. >>> btape: butil.c:285 Using device: "/dev/nst0" for writing. >>> 05-May 15:40 btape JobId 0: 3301 Issuing autochanger "loaded? drive 0" >>> command. 05-May 15:40 btape JobId 0: 3302 Autochanger "loaded? drive 0", >>> result is Slot 1. btape: btape.c:383 open device "Drive-1" (/dev/nst0): >>> OK >>> *fill >>> >>> This command simulates Bacula writing to a tape. >>> It requires either one or two blank tapes, which it >>> will label and write. >>> >>> If you have an autochanger configured, it will use >>> the tapes that are in slots 1 and 2, otherwise, you will >>> be prompted to insert the tapes when necessary. >>> >>> It will print a status approximately >>> every 322 MB, and write an EOF every 3.2 GB. If you have >>> selected the simple test option, after writing the first tape >>> it will rewind it and re-read the last block written. >>> >>> If you have selected the multiple tape test, when the first tape >>> fills, it will ask for a second, and after writing a few more >>> blocks, it will stop. Then it will begin re-reading the >>> two tapes. >>> >>> This may take a long time -- hours! ... >>> >>> Do you want to run the simplified test (s) with one tape >>> or the complete multiple tape (m) test: (s/m) m >>> Multiple tape test selected. >>> Wrote Volume label for volume "TestVolume1". >>> Wrote Start of Session label. >>> 15:44:05 Begin writing Bacula records to first tape ... >>> Wrote blk_block=5000, dev_blk_num=4999 VolBytes=322,495,488 rate=80623.9 >>> KB/s Wrote blk_block=10000, dev_blk_num=9999 VolBytes=645,055,488 >>> rate=92150.8 KB/s Wrote blk_block=15000, dev_blk_num=14999 >>> VolBytes=967,615,488 rate=96761.5 KB/s Wrote blk_block=20000, >>> dev_blk_num=4499 VolBytes=1,290,175,488 rate=86011.7 KB/s Wrote >>> blk_block=25000, dev_blk_num=9499 VolBytes=1,612,735,488 rate=76796.9 >>> KB/s Wrote blk_block=30000, dev_blk_num=14499 VolBytes=1,935,295,488 >>> rate=80637.3 KB/s >>> >>> >>> Wrote blk_block=13055000, dev_blk_num=15500 VolBytes=842,204,095,488 >>> rate=70625.1 KB/s 19:02:52 Flush block, write EOF >>> Wrote blk_block=13060000, dev_blk_num=4000 VolBytes=842,526,655,488 >>> rate=70598.9 KB/s Wrote blk_block=13065000, dev_blk_num=9000 >>> VolBytes=842,849,215,488 rate=70608.1 KB/s Wrote blk_block=13070000, >>> dev_blk_num=14000 VolBytes=843,171,775,488 rate=70611.5 KB/s Wrote >>> blk_block=13075000, dev_blk_num=3500 VolBytes=843,494,335,488 >>> rate=70603.0 KB/s Wrote blk_block=13080000, dev_blk_num=8500 >>> VolBytes=843,816,895,488 rate=70612.3 KB/s 05-May 19:03 btape JobId 0: >>> End of Volume "TestVolume1" at 1226:13010 on device "Drive-1" >>> (/dev/nst0). Write of 64512 bytes got -1. 05-May 19:03 btape JobId 0: >>> Re-read of last block succeeded. >>> btape: btape.c:2360 Last block at: 1226:13009 this_dev_block_num=13010 >>> btape: btape.c:2394 End of tape 1226:0. VolumeCapacity=844,107,844,608. >>> Write rate = 70595.3 KB/s 05-May 19:03 btape JobId 0: End of medium on >>> Volume "TestVolume1" Bytes=844,107,844,608 Blocks=13,084,509 at >>> 05-May-2009 19:03. 05-May 19:03 btape JobId 0: 3307 Issuing autochanger >>> "unload slot 1, drive 0" command. 05-May 19:04 btape JobId 0: 3301 >>> Issuing autochanger "loaded? drive 0" command. 05-May 19:04 btape JobId >>> 0: 3302 Autochanger "loaded? drive 0", result: nothing loaded. 05-May >>> 19:04 btape JobId 0: 3304 Issuing autochanger "load slot 2, drive 0" >>> command. 05-May 19:04 btape JobId 0: 3305 Autochanger "load slot 2, drive >>> 0", status is OK. 05-May 19:04 btape: Fatal Error at dev.c:1705 because: >>> dev.c:1704 Attempt to WEOF on non-appendable Volume >>> Wrote Volume label for volume "TestVolume2". >>> 05-May 19:04 btape JobId 0: Wrote label to prelabeled Volume >>> "TestVolume2" on device "Drive-1" (/dev/nst0) 05-May 19:04 btape JobId 0: >>> New volume "TestVolume2" mounted on device "Drive-1" (/dev/nst0) at >>> 05-May-2009 19:04. Done writing 0 records ... >>> Wrote End of Session label. >>> Wrote state file last_block_num1=13009 last_block_num2=11 >>> >>> >>> 19:04:42 Done filling tapes at 0:13. Now beginning re-read of first tape >>> ... 05-May 19:04 btape JobId 0: 3307 Issuing autochanger "unload slot 2, >>> drive 0" command. 05-May 19:05 btape JobId 0: 3304 Issuing autochanger >>> "load slot 1, drive 0" command. 05-May 19:05 btape JobId 0: 3305 >>> Autochanger "load slot 1, drive 0", status is OK. 05-May 19:05 btape >>> JobId 0: Ready to read from volume "TestVolume1" on device "Drive-1" >>> (/dev/nst0). Rewinding. >>> Reading the first 10000 records from 0:0. >>> 10000 records read now at 1:5084 >>> Reposition from 1:5084 to 1226:13009 >>> Reading block 13009. >>> >>> The last block of the first tape matches. >>> >>> 05-May 19:06 btape JobId 0: 3307 Issuing autochanger "unload slot 1, >>> drive 0" command. 05-May 19:07 btape JobId 0: 3304 Issuing autochanger >>> "load slot 2, drive 0" command. 05-May 19:07 btape JobId 0: 3305 >>> Autochanger "load slot 2, drive 0", status is OK. 05-May 19:07 btape >>> JobId 0: Ready to read from volume "TestVolume2" on device "Drive-1" >>> (/dev/nst0). Reposition from 0:0 to 0:1 >>> Reading block 1. >>> >>> The first block on the second tape matches. >>> >>> Reposition from 0:2 to 0:11 >>> Reading block 11. >>> >>> The last block on the second tape matches. Test succeeded. >>> >>> * >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: yvan [mailto:y...@skywalker.is-a-chef.com] >>> Sent: Thursday, May 07, 2009 6:15 AM >>> To: Win Htin >>> Cc: bacula-users@lists.sourceforge.net >>> Subject: Re: [Bacula-users] Tape MTEOM error with Dell TL2000 (IBM > >>> TS3100) >>> >>> Hi ! >>> >>> Yes, doing that at the moment. It takes a long time to reset all my >>> tapes, erase them, and start some tests on them .... it takes days ... >>> More to come soon ... >>> >>> By the way, what is the best way to erase a tape ? I tried a >>> "dd if=/dev/zero of=/dev/st0" but I had to stop it after 24h (maybe I >>> should use bigger block size to increase speed ?) >>> mt -f /dev/st0 erase gives me some error : Input/Ouput error after a few >>> seconds... >>> >>> Le 05.05.2009 14:12, Win Htin a écrit : >>> >>>> Did you erase the tapes before re-running the backups? >>>> >>>> I would recommend first to completely erase the tape(s), run "btape" >>>> to make sure everything is working fine and then start testing the >>>> actual backups. Capture the output while running "btape" and go >>>> through it line by line to make sure you don't have even a single >>>> error. >>>> >>>> BTW, I forgot to mention I'm running Bacula version 2.2.6 on RHEL4 and >>>> 2.4.3 on RHEL5.2. >>>> >>>> HTH, >>>> Win >>>> >>>> >>>>> Message: 7 >>>>> Date: Mon, 04 May 2009 13:13:45 +0200 >>>>> From: yvan<y...@skywalker.is-a-chef.com> >>>>> Subject: Re: [Bacula-users] Tape MTEOM error with Dell TL2000 (IBM >>>>> TS3100) >>>>> To: bacula-users@lists.sourceforge.net >>>>> Message-ID:<49fecde9.8050...@skywalker.is-a-chef.com> >>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>> >>>>> Hi, >>>>> >>>>> thank you for the advices. We have very similar configurations, and I'm >>>>> sure I'm not too far from the solution. I tried to use your settings in >>>>> the storage daemon config file, and the "mt" options as well, than I >>>>> didn't try so far. >>>>> >>>>> But, as soon as I put those settings, I have another error >>>>> >>>>> Hardware End of Medium = No # defaut is Yes >>>>> Fast Forward Space File = No # This line required if above >>>>> >>>>> which is : >>>>> 3-May 02:20 setmseblx0007-sd JobId 170: Error: Unable to position to >>>>> end of data on device "IBMLTO4" (/dev/nst0): ERR=dev.c:1354 ioctl MTFSF >>>>> error on "IBMLTO4" (/dev/nst0). ERR=Input/output error. >>>>> >>>>> Strange that it works for you then ... I issued all the "mt" commands >>>>> you wrote. Tapeinfo gives me the samed infos as you have, but it's >>>>> MTFSF error or MTEOM ... >>>>> >>>>> Regards >>>>> Yvan Broccard >>>>> >>> ------------------------------------------------------------------------- >>> ----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! >>> Your production scanning environment may not be a perfect world - but >>> thanks to Kodak, there's a perfect scanner to get the job done! With the >>> NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with >>> all image processing features enabled. http://p.sf.net/sfu/kodak-com >>> _______________________________________________ >>> Bacula-users mailing list >>> Bacula-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bacula-users >>> >> --------------------------------------------------------------------------- >> --- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >> production scanning environment may not be a perfect world - but thanks to >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK >> i700 Series Scanner you'll get full speed at 300 dpi even with all image >> processing features enabled. http://p.sf.net/sfu/kodak-com >> _______________________________________________ >> Bacula-users mailing list >> Bacula-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bacula-users >> > > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
