SCIENTIFIC-LINUX-USERS Archives

November 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 1 Nov 2012 09:18:20 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (82 lines)
Thanks Nico for your reply.  Especially the historical context.  I always find I understand something better, know how to make choices, etc., with this information.

Glad to know I'm still cool.  Retro cool, perhaps...but still cool.  :)



On 11/01/2012 04:30 AM, Nico Kadel-Garcia wrote:
> On Thu, Nov 1, 2012 at 3:27 AM, FSG WD Andre Paetzold
> <[log in to unmask]> wrote:
>> On Wed, Oct 31, 2012 at 13:27:49 -0500, Ken Teh wrote:
>>> Do you still use mt and tar for backups on LTO drives or is that so uncool compared to bacula?  Does that mean I'm uncool if I confess I still do?  ;)
>
> "mt" and "tar" are built into most open source tape management
> solutions. I ported Amanda to Solaris long, long, long ago, and it
> still works well. It's also available with commercial support at
> www.zmanda.org"
>
>> Yes, we even still use 'find | cpio' ... ;)
>> But nowadays, when the files become bigger than 8GB, we must switch our scripts to 'tar'
>>
>> To increase the performance of the tape-drive, we use 'tar --blocking-factor=2048' to write
>> with Blocksize of 1MB, but with our new HP LTO5 Tape Blade (connected via SAS)
>> we got input/output errors, so we must switch to Blocksize of 512KB... :(
>> On our HP LTO5 MSL4048 (connected via FibreChannel) it is still possible to use 1MB Blocksize.
>
> Oh, getting down into the guts! I still remember my lamentations that
> the Exabyte drives had no "EOT" marker, the end-of-tape marker used to
> show where writing had stopped, which was usually two "EOF" or
> end-of-file markers in a row. I went nuts writing wrap-arounds to find
> the end of the  tape to write the next dump on a tape I'd just
> inserted!!!!
>
> The problem was that I had a closet full of old magtape with
> irreplaceable research data, the tape drives the oldest tapes were
> compatible with were going away, and I needed the material on new
> media where it would be stored. Enter the "Amanda" software, and a
> chunk of time adapting it to the Exabytes. It very effectively uses
> tar (and now, star for SELinux settings as well) to write the tapes,
> and *the technology is stable*. Unlike many commercial solutions, any
> idiot 10 years from now can still read the tapes even without an
> expensive sotware package that may not run on any OS they own.
>
> These days, I first dump to disk with "rsnapshot", because large,
> consumer grade disk is so cheap now. That lets me keep the last few
> days or weeks of snapshots and make them available to users without
> having to give them tape access, they can just access their NFS shares
> from the cheap storage. And I can run the tape against *that*.
>
>>> Do you still need mt if you use a package like bacula?
>>>
>>
>> We need 'mt' to rewind the tape in case of an error, to retry it, and at the end of
>> the backup to eject the tape from drive, so the operators only have to grab the tape
>> or the see there was an error, if the tape isn't ejected...
>
> Binigo.
>
>>
>>> Thanks!
>>
>> So long,
>>          André
>>
>> --
>>
>> ============================================================================
>> FLENSBURGER SCHIFFBAU-GESELLSCHAFT mbH & Co. KG
>> Batteriestrasse 52, 24939 Flensburg
>>
>> Sitz der Gesellschaft / Place of business : Flensburg
>> Geschaeftsfuehrer / CEO : Peter Sierk
>> Handelregister / Commercial register : Amtsgericht Flensburg, HRA 3140
>> Steuer Nr. / Tax number: 1528040009
>> USt.-Id-Nr. / VAT no : DE 134633705
>> Amtsgericht / District court : Flensburg HRB 2036
>> ============================================================================
>>
>> The information contained in this email message may be privileged and
>> confidential. If you have received this communication in error, please
>> notify the sender immediately by telephoning (+49-461-49400) and return this
>> message to the above address. Thank you.

ATOM RSS1 RSS2