4 ms·

I recently started looking into using an LTO-7 tape drive that I got handed down, along with a few dozens of pristine LOT-6 tapes, for archiving purposes. I got

by c0l0 5y ago

I recently started looking into using an LTO-7 tape drive that I got handed down, along with a few dozens of pristine LOT-6 tapes, for archiving purposes. I got to play around a bit with SAS HBAs, and was kinda shocked how much of a difference that can make in the user (or shall I say sysadmin?) experience: LTO-6 tapes are spec'd to transfer rates of around 150MB/s, so well within the reach of even the the first SAS gear generation. However, the very first SAS HBA with external SFF-8088 connector I managed to get my hands on (an LSI SAS1068e) topped out at a disappointing 80MiB/s, no matter what I tried in terms of blocking and buffering. Switching to a more modern (but still old) LSI SAS2008-based HBA got me close to the theoretical maximum. Then there's the (to me, still open) question of how to best use the actual tape storage capactiy... Since my hardware is newer than LTO-5, LTFS (https://github.com/LinearTapeFileSystem/ltfs https://github.com/LinearTapeFileSystem/ltfs) is an option for convenient access, especially listing tape contents, but that could make it hard for other people down the line to restore data from the tapes I create. It's probably safest to assume that tar will always be there, at least wherever there's tape, too. GNU tar also handles multi-volume/-tape archives, which seems like a necessity if you need to back up amounts of data that exceed a single tape's capacity. Then again, if you want to use encryption with actual tar (important for the kind of data I need to archive), your only option seems to be piping the whole archive through something to compress the stream, which will make accessing individual records in the archive opaque to the drive itself... and you can't just dispose of individual keys to make select parts of the archived data go away for good, either. Also, I would like to conserve as much tape as (conveniently) possible in my archiving adventure. There's "projects" (i.e., top-level directories of directory trees) that consume more than one tape of their own, and then there's smaller projects that you can bin-pack together onto tapes that can fit more than one such project. I've started implementing a small python wrapper around GNU tar to solve a number of these problems by bin-packing projects into "tape slots" and also keeping track of tape-to-file mappings in a small sqlite database, but a workable solution for the encryption problem(s) is not something I managed to come up with yet... If someone has an idea (or better yet, a complete and free implementation of what I am trying to hack together :)), please be so kind and let me know!

__d 5y ago
Using a multi-tape archive increases your chance of failing to restore. Rather than having one possible tape that can be corrupt, you know have more than one. Any single failure will corrupt the whole archive, and you've lost (easy access to) the data. Better to break up the source volume somehow, and have each tape self-contained.
ndespres 5y ago
I think what you are describing is a feature of the Amanda backup system, which might be worth a look. It supports writing to a library of "virtual tapes" which can then be backed by real tapes, tape libraries, hard disks, etc. and will handle the splitting/overflow problem that you are dealing with. https://www.zmanda.com/downloads/ https://www.zmanda.com/downloads/
TheCondor 5y ago
LTFS has been reasonably well supported and it’s fairly open. (I think it’s totally open and published, but I haven’t drilled deep in to it) I haven’t manually restored files but I have switched vendors and it was transparent. It makes tape almost shockingly good, if you can identify by name what you want to recover you can recover it quite quickly. I had previously used Blu-ray for backups, I think they are fairly durable if you have a dry, cool place to store them, but if you have to find date spread over 20 discs, it’s quite a pain. Now it would feel better if Redhat or Suse or somebody cooked ltfs in to their products as a first class thing. I think the catastrophic recovery process would involve building enough of a system to download and install ltfs to access the tapes. I could also create a “recovery system” and then just tar that on to a tape too. My advice strategy has been to keep things relatively warm and when ltfs starts to feel like a liability then I’m going to move the whole archive to something else, fortunately it’s not 100s of br discs, it’s tens of tapes so it will take some hours but it’s mostly waiting on data to stream.
- deleted 5y ago
  [deleted]
bsdice 5y ago
LSI 2008 or 2308 (PCIe 3.0) with IT-mode firmware are good and cheap adapters for LTO. Card's chip will run hot though, so make sure you get a slight air breeze towards it to cool it. Really any fan like 92mm 800rpm within 10cm distance is good enough. LTFS seems dead and tar will not nearly extract all possible good stuff from LTO technology. Plug: I repackaged the open-source Bareos tape software for Arch Linux a couple of days ago. Here are some screenshots of the web interface to give an idea: https://seitics.de/files/bareos/screenshots/ https://seitics.de/files/bareos/screenshots/ One up in the tree are AUR build files and quite a few moderately complex new examples, covering scripting to run ZFS snaphot create/delete around jobs, how to turn on/off external tape units using a USB box to cut down on power and noise (involves drilling a hole on the backside of your formerly 2000 USD drive!), how to write disaster recovery files to tape as well, in case that's all you got left, etc. Software is AGPL3, being a Bacula fork, my contributions here are CC0. Been running it on Arch since around 2017 with multiple LTO drives.

by c0l0 5y ago

__d 5y ago

Using a multi-tape archive increases your chance of failing to restore. Rather than having one possible tape that can be corrupt, you know have more than one. Any single failure will corrupt the whole archive, and you've lost (easy access to) the data. Better to break up the source volume somehow, and have each tape self-contained.

ndespres 5y ago

I think what you are describing is a feature of the Amanda backup system, which might be worth a look. It supports writing to a library of "virtual tapes" which can then be backed by real tapes, tape libraries, hard disks, etc. and will handle the splitting/overflow problem that you are dealing with. https://www.zmanda.com/downloads/ https://www.zmanda.com/downloads/

TheCondor 5y ago

LTFS has been reasonably well supported and it’s fairly open. (I think it’s totally open and published, but I haven’t drilled deep in to it) I haven’t manually restored files but I have switched vendors and it was transparent. It makes tape almost shockingly good, if you can identify by name what you want to recover you can recover it quite quickly. I had previously used Blu-ray for backups, I think they are fairly durable if you have a dry, cool place to store them, but if you have to find date spread over 20 discs, it’s quite a pain. Now it would feel better if Redhat or Suse or somebody cooked ltfs in to their products as a first class thing. I think the catastrophic recovery process would involve building enough of a system to download and install ltfs to access the tapes. I could also create a “recovery system” and then just tar that on to a tape too. My advice strategy has been to keep things relatively warm and when ltfs starts to feel like a liability then I’m going to move the whole archive to something else, fortunately it’s not 100s of br discs, it’s tens of tapes so it will take some hours but it’s mostly waiting on data to stream.

deleted 5y ago
[deleted]

bsdice 5y ago

LSI 2008 or 2308 (PCIe 3.0) with IT-mode firmware are good and cheap adapters for LTO. Card's chip will run hot though, so make sure you get a slight air breeze towards it to cool it. Really any fan like 92mm 800rpm within 10cm distance is good enough. LTFS seems dead and tar will not nearly extract all possible good stuff from LTO technology. Plug: I repackaged the open-source Bareos tape software for Arch Linux a couple of days ago. Here are some screenshots of the web interface to give an idea: https://seitics.de/files/bareos/screenshots/ https://seitics.de/files/bareos/screenshots/ One up in the tree are AUR build files and quite a few moderately complex new examples, covering scripting to run ZFS snaphot create/delete around jobs, how to turn on/off external tape units using a USB box to cut down on power and noise (involves drilling a hole on the backside of your formerly 2000 USD drive!), how to write disaster recovery files to tape as well, in case that's all you got left, etc. Software is AGPL3, being a Bacula fork, my contributions here are CC0. Been running it on Arch since around 2017 with multiple LTO drives.