Re: [Bacula-users] Tape issue: less size than before for LTO-4 tapes
Am 10.03.20 um 15:13 schrieb Martin Simmons: >> On Tue, 10 Mar 2020 09:26:20 +0100, Pierre Bernhardt said: > I suggest checking the bacula log and the syslog to see what it reports when > the tape is marked as full. Thats a problem. I've send only mails in the past. Only after upgrade in feb 2020 i added also local log files :-( The mails does not show relevant message, only tape is full and another from scratch pool has to been used to continue the backups. On one of the last tape full exchanges: 02-Mar 09:06 backup-sd JobId 47481: Writing spooled data to Volume. Despooling 2,147,487,764 bytes ... 02-Mar 09:06 backup-sd JobId 47481: [SI0202] End of Volume "LTO40029" at 551:5309 on device "HP Ultrium 4-1" (/dev/tape/by-id/scsi-32001000e11129ae5-nst). Write of 64512 bytes got -1. 02-Mar 09:06 backup-sd JobId 47481: Re-read of last block succeeded. 02-Mar 09:06 backup-sd JobId 47481: End of medium on Volume "LTO40029" Bytes=548,973,702,144 Blocks=8,509,636 at 02-Mar-2020 09:06. 02-Mar 09:06 backup-sd JobId 47481: 3307 Issuing autochanger "unload Volume LTO40029, Slot 20, Drive 0" command. 02-Mar 09:08 backup-dir JobId 47481: Using Volume "LTO40032" from 'Scratch' pool. 02-Mar 09:08 backup-sd JobId 47481: 3304 Issuing autochanger "load Volume LTO40032, Slot 18, Drive 0" command. 02-Mar 09:09 backup-sd JobId 47481: 3305 Autochanger "load Volume LTO40032, Slot 18, Drive 0", status is OK. 02-Mar 09:10 backup-sd JobId 47481: Wrote label to prelabeled Volume "LTO40032" on Tape device "HP Ultrium 4-1" (/dev/tape/by-id/scsi-32001000e11129ae5-nst) 02-Mar 09:10 backup-sd JobId 47481: New volume "LTO40032" mounted on device "HP Ultrium 4-1" (/dev/tape/by-id/scsi-32001000e11129ae5-nst) at 02-Mar-2020 09:10. 02-Mar 09:14 backup-sd JobId 47481: Despooling elapsed time = 00:03:59, Transfer rate = 8.985 M Bytes/second > It might be a problem with the tape drive. Can you run the manufacturer's > diagnostics? No idea how. It's linux box and as long tapeinfor does not shows an error or an error is reported in syslog/dmesg/log ... > Also, you might try using smartctl to get information about error rates from > the drive. Something like: > > smartctl -a -d scsi -T permissive /dev/nst0 Oh, thats new for me ;-) root@backup:~# smartctl -a -d scsi -T permissive /dev/tape/by-id/scsi-HU1914570A-nst smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-8-amd64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HP Product: Ultrium 4-SCSI Revision: V67B Logical Unit id: 0x2001000e11129ae5 Serial number:HU1914570A Device type: tape Transport protocol: Fibre channel (FCP-2) Local Time is:Tue Mar 10 20:33:02 2020 CET Temperature Warning: Disabled or Not Supported === START OF READ SMART DATA SECTION === TapeAlert Supported TapeAlert: OK Current Drive Temperature: 31 C Drive Trip Temperature: Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 00 0 0 0 0.000 0 write:1552171 1 1 21869758 0.000 0 Device does not support Self Test logging > >> (How can I check it which drive index has been used before and since >> 2020 ? Is there a field which shows me the drive index in the db?) > > This information should be in the bacula log. It looks like it is ever drive 0. Cheers, Pierre ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Tape issue: less size than before for LTO-4 tapes
Am 10.03.20 um 09:26 schrieb Pierre Bernhardt: > Todo: Check a backup so the drive 2 will be used instead of drive 1. > Maybe since 2020 the other drive is used. > (How can I check it which drive index has been used before and since > 2020 ? Is there a field which shows me the drive index in the db?) I made at first a btape rawfill test. But it looks like it was only shows me the actual behavior, means the new tape has been stored only 565 GiByte. By the way it was stored with a rate of 25 MiByte/s so I think it was to slow for the drive so maybe it has been inserted empty areas. Write failed at block 8758373. stat=-1 ERR=Auf dem Gerät ist kein Speicherplatz mehr verfügbar btape: btape.c:411-0 Volume bytes=565.0 GB. Write rate = 25.08 MB/s btape: btape.c:612-0 Wrote 1 EOF to "HP Ultrium 4-1" (/dev/tape/by-id/scsi-HU1914570A-nst) I changed the dev by using the serial number of the tape drive instead of the lun id. I made the btape test on the drive 0 which all backups were made. I will repeat with the other drive. For the moment a backup test on a new tape on the tape drive 1 is running. pcp shows me a write rate between 30 and 50 MiByte/s which is more against the btape test above. Cheers, Pierre ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] New tape drive
Ok, I didn't know if it was being stored internally in the database for the tapes (e.g., tape volume Daily-1 was associated in the catalog with storage device LTO-5). Thanks. Steven Hammond On 3/10/2020 12:38 PM, Gary R. Schmidt wrote: On 11/03/2020 02:26, Steven Hammond wrote: We are currently using a LTO-5 drive. We are upgrading to a LTO-7 drive. I noticed the directive in our pools STORAGE=LTO-5. I'd like the existing pools to use LTO-7 (since it can still read LTO-5 tapes). Can I just change the directive in the pool to use our new LTO-7 tape drive OR will this mess up the existing LTO-5 tapes in the pool. I was wanting to use the existing pools, but I could create new ones if necessary. Thanks. It's just a tag, it has no meaning, you could use "Bilbo-Baggins" and as long as you are consistent it doesn't matter what the contents of the "Storage" directive is. Cheers, Gary B-) P.S. It's considered impolite to change the Subject of an existing thread on a mailing list to start a new discussion, it buggers up MUAs that use the "Reference:" header to group things. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] New tape drive
On 11/03/2020 02:26, Steven Hammond wrote: We are currently using a LTO-5 drive. We are upgrading to a LTO-7 drive. I noticed the directive in our pools STORAGE=LTO-5. I'd like the existing pools to use LTO-7 (since it can still read LTO-5 tapes). Can I just change the directive in the pool to use our new LTO-7 tape drive OR will this mess up the existing LTO-5 tapes in the pool. I was wanting to use the existing pools, but I could create new ones if necessary. Thanks. It's just a tag, it has no meaning, you could use "Bilbo-Baggins" and as long as you are consistent it doesn't matter what the contents of the "Storage" directive is. Cheers, GaryB-) P.S. It's considered impolite to change the Subject of an existing thread on a mailing list to start a new discussion, it buggers up MUAs that use the "Reference:" header to group things. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] New tape drive
We are currently using a LTO-5 drive. We are upgrading to a LTO-7 drive. I noticed the directive in our pools STORAGE=LTO-5. I'd like the existing pools to use LTO-7 (since it can still read LTO-5 tapes). Can I just change the directive in the pool to use our new LTO-7 tape drive OR will this mess up the existing LTO-5 tapes in the pool. I was wanting to use the existing pools, but I could create new ones if necessary. Thanks. Steven Hammond Technical Chemical Company Cleburne, TX ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Tape issue: less size than before for LTO-4 tapes
> On Tue, 10 Mar 2020 09:26:20 +0100, Pierre Bernhardt said: > > Hello, > > since beginning of this year a tape issue has been arrived my backups. > All my LTO-4 Tapes will not fill any more to the ~ 760 GiByte than > before. Only ~ 510-580 GiByte will be stored on the tapes which is > shown by the list volume command. > The latest volume with > 720 GiByte has to been written on the full- > Backups at 06.01.2020. All tapes after that date will only filled > with 500-600 GiByte. I suggest checking the bacula log and the syslog to see what it reports when the tape is marked as full. It might be a problem with the tape drive. Can you run the manufacturer's diagnostics? Also, you might try using smartctl to get information about error rates from the drive. Something like: smartctl -a -d scsi -T permissive /dev/nst0 > (How can I check it which drive index has been used before and since > 2020 ? Is there a field which shows me the drive index in the db?) This information should be in the bacula log. __Martin ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Bacula Release 9.6.3
Hello, This is to announce that we have released Bacula version 9.6.3 to Source Forge and to www.bacula.org. This version primarily has fixed a number of incorrect copyrights. If you are using Bacula 9.6.0, 9.6.1, or 9.6.2, we recommend that you update, but it i not required. The following fixes have been made since version 9.6.2: - Eliminate false error when droping postgres table MAC - Apply Carsten's character set fix for the docs. Many thanks! - Fix logic error in clearing bit on Windows - baculum: Update Portuguese translations - baculum: Update Polish translations - baculum: Add patch to PRADO framework 4.0.1 for supporting PostgreSQL 12 catalog database - baculum: Add support for PostgreSQL 12 catalog database - Enhance failed bpipe to changer error message - Clean up some incorrect copyrights - Correct spelling errors in messages - Add to plugins links - baculum: Add bulk actions for job history and volume tables - baculum: Update DataTables and its plugins - docker: Update copyright headers. - Update BSD copyright on *.conf.in files - docker: Remove unneeded tar binary. - Fix workaround for Sun C++ recommended by Phil Stracchino - baculum: Update Polish translations - baculum: Update Portuguese translations For more details see the ReleaseNotes or ChangeLog files. The binary files should be released within the next week. Thanks for using Bacula. Be happy, Kerm ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Baculum api installs, but throws Error 1000
Thank you, Marcin, you were absolutely right. I wiped my install & started
again with the default version of PostgreSQL, and it works perfectly.
You went above and beyond the call on this one!
On Fri, Mar 6, 2020 at 8:52 PM Marcin Haba wrote:
> Hello Neil,
>
> Thanks for reporting this problem here.
>
> It looks that you are using PostgreSQL 12. I did a test on my side and
> I have noticed that the framework used in Baculum doesn't support
> PostgreSQL 12 yet. I have reported a feature request for that:
>
> https://github.com/pradosoft/prado/issues/708
>
> To have Baculum working in your environment you can wait for new
> Baculum release or you can use a patch attached to the feature request
> above, or eventually you can use PostgreSQL version less than 12 if
> you want to do this effort.
>
> Best regards,
> Marcin Haba (gani)
>
> On Fri, 6 Mar 2020 at 21:39, Neil MacGregor
> wrote:
> >
> > I'm evaluating Bacula for use in my organization. I am a n00b.
> >
> > Last week, I followed the instructions, performing a fresh install of
> Bacula v9.4.4 on new, fully patched CentOS7, via RPM's from the official
> repo. I'm happy to report this went VERY well; built from a new Ansible
> playbook. I've been using the text console - works great, backed up 377Gb
> in our Test environment, in 1h 18m, nice! Works with SELinux set to
> 'enforcing', too: wicked.
> >
> > I'm aware that v9.6.2 of Bacula has *just* been released (but hasn't
> landed in the RPM repositories, yet). Perhaps this is an awkward time, as
> I'm finding a mix of new & old documentation.
> >
> > Today I've been fighting to install the Baculum GUI. I had to come here
> to the mailing list to find the updated documentation:
> https://www.bacula.org/9.6.x-manuals/en/console/Baculum_API_Web_GUI_Tools.html#SECTION00313000...
> Thanks, previous post.
> >
> > So, for the API, I can get all the panels with a "test" button to go
> OK/green, but when I finally get to the query panel eg
> http://localhost:9096/panel/, I get this error:
> >
> > {
> > "output": "Internal error. TDbCommand failed to execute the query SQL
> \"\tSELECT conname, consrc, contype, indkey, indisclustered FROM
> (\n\t\t\tSELECT\n\t\t\t\t\tconname,\n\t\t\t\t\tCASE WHEN contype='f'
> >
>
> THEN\n\t\t\t\t\t\t\tpg_catalog.pg_get_constraintdef(oid)\n\t\t\t\t\tELSE\n\t\t\t\t\t\t\t'CHECK
> (' || consrc || ')'\n\t\t\t\t\tEND AS
> consrc,\n\t\t\t\t\tcontype,\n\t\t\t\t\tconrelid AS relid,\n\t\t\t\t\tNULL
> AS indkey,/n
> > \t\t\t\t\tFALSE AS
> indisclustered\n\t\t\tFROM\n\t\t\t\t\tpg_catalog.pg_constraint\n\t\t\tWHERE\n\t\t\t\t\tcontype
> IN ('f', 'c')\n\t\t\tUNION
> ALL\n\t\t\tSELECT\n\t\t\t\t\tpc.relname,\n\t\t\t\t\tNULL,\n\t\t\t\t\t
> > CASE WHEN indisprimary
> THEN\n\t\t\t\t\t\t\t'p'\n\t\t\t\t\tELSE\n\t\t\t\t\t\t\t'u'\n\t\t\t\t\tEND,\n\t\t\t\t\tpi.indrelid,\n\t\t\t\t\tindkey,\n\t\t\t\t\tpi.indisclustered\n\t\t\tFROM\n\t\t\t\t\tpg_catalog.pg_class
> > pc,\n\t\t\t\t\tpg_catalog.pg_index
> pi\n\t\t\tWHERE\n\t\t\t\t\tpc.oid=pi.indexrelid\n\t\t\t\t\tAND EXISTS
> (\n\t\t\t\t\t\t\tSELECT 1 FROM pg_catalog.pg_depend d JOIN
> pg_catalog.pg_constraint c\n\t\t\t\t\t\t\tON
> > (d.refclassid = c.tableoid AND d.refobjid =
> c.oid)\n\t\t\t\t\t\t\tWHERE d.classid = pc.tableoid AND d.objid = pc.oid
> AND d.deptype = 'i' AND c.contype IN ('u', 'p')\n\t\t\t)\n\t) AS
> sub\n\tWHERE relid =
> > (SELECT oid FROM pg_catalog.pg_class WHERE
> relname=:table\n\t\t\t\t\tAND relnamespace = (SELECT oid FROM
> pg_catalog.pg_namespace\n\t\t\t\t\tWHERE nspname=:schema))\n\tORDER
> BY\n\t\t\t1\":
> > SQLSTATE[42703]: Undefined column: 7 ERROR: column \"consrc\" does
> not exist\nLINE 7:'CHECK (' || consrc || ')'\n
> ^\n
> > HINT: Perhaps you meant to reference the column
> \"pg_constraint.conkey\" or the column \"pg_constraint.conbin\".",
> > "error": 1000
> > }
> >
> > Has anybody else run into this? (That's some wizard-level black magic
> SQL...)
> > Am I doing something wrong?
> >
> >> [root@bac-rec-test-1 ~]# rpm -qa | egrep 'bacula|baculum' | sort
> >> bacula-libs-9.4.4-1.el7.x86_64
> >> bacula-postgresql-9.4.4-1.el7.x86_64
> >> baculum-api-9.6.2-1.el7.noarch
> >> baculum-api-httpd-9.6.2-1.el7.noarch
> >> baculum-api-selinux-9.6.2-1.el7.noarch
> >> baculum-common-9.6.2-1.el7.noarch
> >> baculum-web-9.6.2-1.el7.noarch
> >> baculum-web-httpd-9.6.2-1.el7.noarch
> >> baculum-web-selinux-9.6.2-1.el7.noarch
> >
> > --
> > -Neil
> > 780-492-3155
> > University of Alberta Libraries
> > 4-30 Cameron Library
> > ___
> > Bacula-users mailing list
> > Bacula-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
>
> --
> "Greater love hath no man than this, that a man lay down his life for
> his friends." Jesus Christ
>
> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
> za przyjaciół swoich." Jezus Chrystus
>
--
-Neil
780-492-3155
University of Alberta Libraries
4-30
Re: [Bacula-users] Tape issue: less size than before for LTO-4 tapes
Am 10.03.20 um 09:26 schrieb Pierre Bernhardt: > (How can I check it which drive index has been used before and since > 2020 ? Is there a field which shows me the drive index in the db?) Ok, found a field but it is ever filled by 0: bacula=> select volumename,deviceid,volbytes from media where volumename like 'LTO4%'; volumename | deviceid | volbytes +--+-- LTO40002 |0 | 812678501376 LTO40004 |0 | 812714886144 LTO40009 |0 | 812782107648 LTO40012 |0 | 812686500864 LTO40007 |0 | 812761721856 LTO40016 |0 | 812686758912 LTO40013 |0 | 812738562048 LTO40015 |0 | 812673921024 LTO40006 |0 | 812596248576 LTO40008 |0 | 812671534080 LTO40010 |0 | 812681017344 LTO40014 |0 | 812726369280 LTO40018 |0 | 812729723904 LTO40020 |0 | 812725788672 LTO40019 |0 | 812656180224 LTO40025 |0 | 628959808512 LTO40031 |0 | 552112210944 LTO40003 |0 | 812701596672 LTO40027 |0 | 629233274880 LTO40022 |0 | 812717724672 LTO40023 |0 | 782473273344 LTO40026 |0 | 628718920704 LTO40028 |0 | 579429107712 LTO40011 |0 | 812760173568 LTO40005 |0 | 812693016576 LTO40001 |0 | 812703725568 LTO40017 |0 | 812674050048 LTO40034 |0 | 475099978752 LTO40024 |0 | 336473819136 LTO40032 |0 | 554964544512 LTO40029 |0 | 548973702144 LTO40035 |0 |64512 LTO40033 |0 | 558934032384 (33 rows) bacula=> select volumename,deviceid from media where deviceid != 0; volumename | deviceid +-- (0 rows) Cheers, Pierre ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Tape issue: less size than before for LTO-4 tapes
Hello, since beginning of this year a tape issue has been arrived my backups. All my LTO-4 Tapes will not fill any more to the ~ 760 GiByte than before. Only ~ 510-580 GiByte will be stored on the tapes which is shown by the list volume command. The latest volume with > 720 GiByte has to been written on the full- Backups at 06.01.2020. All tapes after that date will only filled with 500-600 GiByte. | 422 | LTO30097 | Full | 1 | 406,660,746,240 | 406 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-08-08 05:30:51 | 454,457,559 | | 424 | LTO30099 | Full | 1 | 406,697,131,008 | 409 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-08-05 10:38:22 | 454,216,810 | | 425 | LTO30100 | Full | 1 | 406,700,292,096 | 406 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-08-07 10:33:05 | 454,389,293 | | 426 | LTO30101 | Full | 1 | 406,729,451,520 | 406 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-08-05 17:08:29 | 454,240,217 | | 427 | LTO40001 | Full | 1 | 812,703,725,568 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2018-11-05 10:51:08 | 430,630,376 | | 428 | LTO40002 | Full | 1 | 812,678,501,376 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2018-11-06 10:04:59 | 430,714,007 | | 429 | LTO40003 | Full | 1 | 812,701,596,672 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2018-10-08 20:22:19 | 428,245,447 | | 431 | LTO40004 | Full | 1 | 812,714,886,144 | 817 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2018-12-03 12:22:02 | 433,055,030 | | 432 | LTO40005 | Full | 1 | 812,693,016,576 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2018-12-04 10:28:39 | 433,134,627 | | 433 | LTO40006 | Full | 1 | 812,596,248,576 | 815 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-01-07 04:01:50 | 436,049,018 | | 434 | LTO40007 | Full | 1 | 812,761,721,856 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-01-07 18:38:57 | 436,101,645 | | 435 | LTO40016 | Full | 1 | 812,686,758,912 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-02-04 04:23:58 | 438,469,546 | | 436 | LTO40008 | Full | 1 | 812,671,534,080 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-03-04 04:18:59 | 440,888,447 | | 437 | LTO40009 | Full | 1 | 812,782,107,648 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-03-04 19:16:49 | 440,942,317 | | 438 | LTO40010 | Full | 1 | 812,681,017,344 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-04-08 04:15:13 | 443,912,221 | | 439 | LTO40011 | Full | 1 | 812,760,173,568 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-02-04 18:40:48 | 438,520,956 | | 441 | LTO40014 | Full | 1 | 812,726,369,280 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-04-08 18:14:51 | 443,962,599 | | 442 | LTO40012 | Full | 1 | 812,686,500,864 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-05-06 04:26:15 | 446,332,083 | | 443 | LTO40013 | Full | 1 | 812,738,562,048 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-05-06 18:28:43 | 446,382,631 | | 444 | LTO40015 | Full | 1 | 812,673,921,024 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-06-03 19:18:29 | 448,804,817 | | 445 | LTO40017 | Full | 1 | 812,674,050,048 | 812 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-06-04 22:02:59 | 448,901,087 | | 446 | LTO40018 | Full | 1 | 812,729,723,904 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-06-03 18:26:33 | 448,801,701 | | 447 | LTO40019 | Full | 1 | 812,656,180,224 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-07-09 19:34:41 | 451,916,189 | | 448 | LTO40020 | Full | 1 | 812,725,788,672 | 813 | 473,040,000 | 1 |0 | 0 | LTO-3 | 2 |0 | 2019-07-08 17:53:41 | 451,823,729 | | 449 |
