(mis)Avonturen met LTO-tapes

Ik heb een beetje een probleem/hobby: het bouwen en onderhouden van mijn homelab. In de afgelopen jaren heb ik geleidelijk een home-serveropstelling gebouwd die ik gebruik om een handvol diensten self-hosten, en om te experimenteren en te leren over netwerken, systeembeheer en andere "hands-on" aspecten van hoe het internet en andere moderne technologieën functioneren.

Deze hobby betekent dat ik soms eindig met een stapel tweedehands enterprise-apparatuur op mijn werkbank, met slechts een vaag plan en weinig idee waar ik moet beginnen. Dat is precies waar ik me eerder dit jaar in bevond: ik wilde mijn homelab-opstelling upgraden om LTO-tapes te kunnen gebruiken als onderdeel van mijn back-upstrategie.

Dit is een beetje een "DenverCoder9"-scenario, waarbij ik vooral dingen wil opschrijven waar ik tegenaan liep, zodat anderen die hiernaar zoeken mogelijk oplossingen kunnen vinden. Maar op een nog realistischer niveau is het bedoeld zodat ik over een paar jaar, wanneer ik ben vergeten wat ik heb ontdekt, aantekeningen heb om op terug te grijpen.

Als aanvullende kanttekening: dit is niet bedoeld als handleiding. Ik ben absoluut geen expert in deze zaken en geef eerlijk toe dat ik het gewoon ga uitzoeken terwijl ik bezig ben. Maar hopelijk kan ik zaken belichten die ik ben tegengekomen en die nuttig kunnen zijn voor anderen in de toekomst.

Wat is LTO-tape?

Magnetische tape is niet uit de mode! Hoewel we geen cassettes meer gebruiken voor onze muziek of floppy disks voor dagelijks computergebruik, blijft magnetische gegevensopslag zeer populair vanwege de levensduur en kostenefficiëntie.

Het Linear Tape Open (LTO) formaat bestaat sinds de jaren 90. De meest recente versies van de standaard (LTO-10) kunnen 30 of 40 TB aan gegevens op een enkele tape-cartridge bevatten — een enorme groei ten opzichte van LTO-1, die 0,1 TB per tape vasthield. LTO-tape is ontworpen voor archivering met een levensduur van 15 tot 30 jaar.

Benjojo heeft een uitstekend overzicht van LTO-tapeopslag, inclusief een handige calculator om de kosten te benaderen en het "break-even"-punt te bepalen waarbij tape goedkoper is dan een array van harde schijven.

Zelf heb ik een Synology NAS met 4 bays en een uitbreidingsunit van 4 bays, maar ik heb net minder dan 20 TB aan bruikbare opslag. En die beschikbare ruimte slinkt snel.

Waarom heb ik een LTO-drive gekocht?

Omdat ik een slechte impulsbeheersing heb wanneer ik door eBay-advertenties scrol.

Maar serieuzer genomen: het was allang tijd om mijn back-upsysteem(en) te herzien en ervoor te zorgen dat ik meerdere kopieën van belangrijke gegevens bewaarde. Ik ken de 3-2-1 back-upregel al lang, maar heb hem zelden echt gevolgd. Hoewel ik meerdere kopieën van (het grootste deel van) mijn gegevens bewaarde, was dit allemaal op hetzelfde type medium: harde schijven. Door sommige kopieën naar LTO-tape te verplaatsen, kan ik ervoor zorgen dat niet alles afhankelijk is van één medium. (Hoewel ik, om eerlijk te zijn, nog steeds niet volledig aan de 3-2-1 regel voldoe, aangezien ik nog geen off-site back-up heb.)

Daarnaast vind ik het gewoon leuk. Ik ben altijd geïnteresseerd in het werken met de fysieke "spullen" die onze moderne, tech-centrische wereld laten draaien.

De Hardware

Dit is waar ik uiteindelijk mee ben geëindigd:

• Tandberg Model 3524 LTO-5 drive: Half Height, Fibre Channel model.
• QLOGIC PX2810403-01 PCIe Dual Port 8GB Fibre Channel Host Bus Adapter (HBA): Ik heb letterlijk op eBay gezocht naar "fibre channel HBA" en gesorteerd op prijs. Uit het weinige onderzoek dat ik heb gedaan, maken vrijwel alle FC HBA's gebruik van dezelfde Qlogic-chipset en zouden ze dus vergelijkbaar moeten werken.
• Een set gebruikte LTO-5 tapes: Ik kon een pakket van 10 kopen voor $75 op eBay. Dit komt neer op een ruwe kostprijs van $2 per TB. Volgens diskprices.com verslaat dit alle harde schijven, zelfs vóór de enorme prijsstijging door de AI-bubbel.

Achteraf gezien denk ik dat ik liever een drive had gekocht die een SAS-verbinding gebruikt in plaats van Fibre Channel. Ik liep tegen enkele problemen aan met de FC-verbinding en moest nachtmerrieachtig kabelmanagement toepassen om alles te verbinden. SAS zou veel eenvoudiger zijn geweest. SAS-drives zijn echter vaak honderden dollars duurder.

Installatie

De server waarin ik dit installeer is erg rommelig. Het is een complete "Frankenstein-monster" van diverse componenten en er draaien een hele mix van verschillende diensten op. Ik koos ervoor om de drive hier te installeren op basis van een zorgvuldige evaluatie van softwaremogelijkheden, CPU-werklasten en netwerkdoorvoer... nee, dat is onzin. Ik heb de drive hier geplaatst omdat er een lege drive-bay vrij was.

Omdat ik een Fibre Channel-drive heb en mijn FC HBA zijn SFP-poorten naar buiten heeft gericht (zoals gebruikelijk), moet ik de glasvezelkabels vanaf het PCIe-slot runnen en ze terug in de behuizing lussen om verbinding te maken met de drive.

Gelukkig is mijn voeding niet correct gemonteerd en past hij niet volledig in dit chassis. Zoals te zien is in de afbeelding, wordt hij op zijn plaats gehouden door een lege, kleine kartonnen doos. Ik weet het, het toppunt van goed systeemontwerp. Maar het maakte het makkelijk om de kabel terug te voeren naar de drive; ik hoefde alleen wat zaken te herschikken om ervoor te zorgen dat de ventilatoren nog steeds lucht door de doos konden trekken.

Maak je geen zorgen, ik heb het probleem met de kaart-inset inmiddels opgelost door een nieuwe PCIe-riser aan te schaffen. Voorheen gebruikte ik de rechthoekige adapter die ik uit een oude Apple Xserve had gehaald (als later project wil ik het oude 1u Xserve-chassis retrofitten met de ingewanden van een moderne Mac Studio). Maar zoals bleek, zat deze adapter ongeveer een inch en een half naar achteren. In het begin bungelde hij dus precair boven de CPU. Ik gebruikte een visitekaartje om te voorkomen dat hij kortsluiting zou maken.

Na een andere eBay-aankoop had ik een correct passende PCIe-rechthoekige adapter. Maar toen kreeg ik te maken met een nieuw probleem.

De drive werkte, maar het besturingssysteem kon hem totaal niet zien.

Ik kon een tape in de drive plaatsen en ik hoorde hem functioneren: verschillende klikken en klappen terwijl de drive de tape oppakte, en daarna de motor die op snelheid kwam om de kop uit te lijnen. Het "ready"-lampje op de drive brandde constant. Maar ik kreeg niets te zien in het besturingssysteem.

Ik heb talloze pogingen gedaan om de SCSI-bus te scannen, maar kreeg niets. Ik controleerde dmesg voor logs gerelateerd aan de QLogic-driver en bleef foutmeldingen zien over een losgekoppelde kabel.

Ik probeerde een andere glasvezelkabel. Nog steeds niets. Ik controleerde de kabel door met een zaklamp in één uiteinde te schijnen — hij was intact en werkte prima. Ik probeerde domweg in de kabel te kijken terwijl één uiteinde was aangesloten op de HBA. Doe dit niet, want je eindigt met een kleine laserstraal in je oog.

Ik vroeg me af of er iets mis was met de drive zelf, dus ik verbrak de "warranty void if opened" zegel en keek binnenin. Het verwijderen van de kap van de drive was een Bad Idea™ en veroorzaakte meer problemen dan het oploste. Ja, ik kon de drive een beetje schoonmaken, maar het was een enorme hoofdpijn om hem weer in elkaar te zetten zonder dat de lintkabel bekneld raakte.

Ik was klaar om op te geven en te accepteren dat ik honderden dollars had verspild, toen ik een reactie vond op een forum waar werd gevraagd naar tools om paren glasvezelkabels eenvoudig te wisselen. Het antwoord was dat je de kabels meestal gewoon met de hand uit kunt klikken en weer terug kunt klikken.

En dit was het moment waarop alles klikte. Het was het klassieke probleem van het nodig hebben van een crossover-kabel om twee apparaten direct met elkaar te verbinden. Wanneer ik de HBA direct met de drive verbond, was de verzendpoort (transmit) aan de ene kant verbonden met de verzendpoort aan de andere kant, in plaats van met de correcte ontvangstpoort (receive). In veel andere omgevingen worden FC-apparaten verbonden via een Fibre Channel-switch, wat betekent dat de verzend- en ontvangstdraden correct zijn uitgelijnd. Maar zoals blijkt, is het simpelweg omwisselen van de twee kabels een eenvoudig proces en loste dit het probleem onmiddellijk op.

Het blijkt dat als je dingen gewoon correct aansluit, het beter werkt!

Tape-operaties

LTO-tape is niet zoals andere block storage-apparaten (harde schijven, SSD's, enzovoort). Ik bedoel dit in de zin dat het letterlijk geen block storage-apparaat is. Apparaten zoals harde schijven en SSD's splitsen gegevens in blokken van vaste grootte die vervolgens over een fysiek medium worden verdeeld. Op een draaiende schijf is het geen probleem als de delen van een bestand overal verspreid staan, omdat de schijf ronddraait en de verschillende delen overal gelezen kunnen worden.

LTO is daarentegen een medium met sequentiële toegang, wat betekent dat er een duidelijk begin en einde van de tape is. Als je iets wilt lezen aan het einde van de tape, moet je de tape langs alles spoelen wat eraan voorafgaat. Tape-drives zijn over het algemeen traag in het ophalen van specifieke bestanden (vanwege de zeer hoge "seek time"), maar kunnen zeer snel zijn bij het lezen van grote volumes continue gegevens zodra het startpunt is bereikt. Dit maakt het zeer effectief voor langdurige archivering en data-back-ups waarbij de ophaalsnelheid minder belangrijk is dan factoren als kosten en capaciteit.

Hoewel er moderne utilities zijn zoals LTFS die tape-gegevens toegankelijk kunnen maken op een manier die lijkt op schijven of removable flash-drives, is de realiteit dat het schrijven van gegevens naar een tape iets ingewikkelder is.

In Linux verschijnt de drive als twee apparaten: /dev/nst0 en /dev/st0. Als ik meerdere tape-drives had, zouden er extra apparaten zijn die oplopen vanaf 0.

Zowel /dev/nst0 als /dev/st0 zijn dezelfde fysieke drive, maar nst0 is een "non-rewinding" (niet-terugspoelend) tape-apparaat, terwijl st0 de tape na elke operatie volledig terugspoelt. Dit betekent dat ik in vrijwel elke situatie /dev/nst0 wil gebruiken. Ik heb dit ingesteld als een omgevingsvariabele in mijn shell:

export TAPE=/dev/nst0

Normaal gesproken moet je bij elk commando het apparaat opgeven:

• mt -f /dev/nst0 status — controleer de status van de drive
• mt -f /dev/nst0 rewind — spoel terug naar het begin van de tape
• mt -f /dev/nst0 eject — werp de tape uit

Door de TAPE variabele in te stellen, kan ik dat deel overslaan. Ik heb een "spiekbriefje" gemaakt voor enkele veelvoorkomende tape-operaties:

• mt eom — Verplaats de tape naar het einde van de geldige gegevens
• mt asf X — Spoelt de tape terug en gaat naar file marker X
• mt fsf X — Ga vooruit X file markers
• mt bsf X — Ga terug X file markers
• mt bsfm 2 — Als je bij file marker 4 bent, ga terug naar het BEGIN van filemarker 3

De tape houdt bij hoeveel verschillende bestanden je hebt geschreven, dus je kunt deze commando's gebruiken om eenvoudig over de tape te bewegen en jezelf op de juiste plek te positioneren om nieuwe gegevens te lezen of te schrijven.

Om daadwerkelijk te schrijven (en later te lezen), zijn dit enkele commando's:

• tar czvf - ./ | mbuffer -m 5G -P 80 -s 524288 -o /dev/nst0 — schrijft de inhoud van de huidige directory (of een andere gespecificeerde) als een gecomprimeerde tarball naar de tape. De -s 524288 vlag wordt gebruikt om een grote blokgrootte op te geven, wat beter samenwerkt met de fysieke lay-out van de tape.

Het is ook belangrijk om mbuffer te gebruiken bij het schrijven van gegevens om "shoe shining" te voorkomen. Dit gebeurt wanneer de drive de tape vele malen vooruit en achteruit moet zoeken, wat kan gebeuren bij het schrijven van korte bursts aan gegevens. Mijn drive kan 140 MB/s aan dataoverdracht aan, maar het kan voor het besturingssysteem moeilijk zijn om die hoeveelheid gegevens zo snel te leveren bij het lezen vanaf schijf of over het netwerk. Door gegevens in het RAM te bufferen (ik gebruik een buffer van 5 GB), kan de drive in bursts werken.

• mbuffer -m 5G -P 80 -s 524288 -i file.tar.gz > /dev/nst0 — Als ik al een tarball heb, kan ik dit gebruiken om deze as-is naar de tape te schrijven (opnieuw via mbuffer).
• mbuffer -m 5G -s 524288 -i /dev/nst0 | tar tzvf - — Zodra de tape in positie is, leest dit commando de inhoud van de tarball en lijst deze in de terminal. Dit is handig om te controleren wat er op de tape staat, maar vereist dat de tape over het gehele bestand gaat.
• mbuffer -m 5G -s 524288 -i /dev/nst0 | tar xzvf - — Zodra de tape in positie is, leest dit commando de inhoud van de tarball en pakt deze uit in de huidige werkmap.

Enkele andere nuttige commando's om metadata te lezen uit de geheugenmodule in elke tape-cartridge:

• sudo sgreadattr -f 0x0000 /dev/nst0 — Resterende capaciteit van de tape (zoals gerapporteerd op de tape MAM)
• sudo sgreadattr -f 0x0001 /dev/nst0 — Totale capaciteit van de tape
• sudo sgreadattr -f 0x0220 /dev/nst0 — Totaal aantal geschreven MiB in het leven van de tape
• sudo sgreadattr -f 0x0221 /dev/nst0 — Totaal aantal gelezen MiB in het leven van de tape
• sudo sgreadattr -f 0x0806 /dev/nst0 — barcode van de tape ophalen

Backup-operaties

Ik heb momenteel een ingewikkelde opstelling waarbij een handvol verschillende machines regelmatig gegevens backuppen naar mijn NAS. Vervolgens kopieer ik op semi-regelmatige (en momenteel handmatige) basis die kopieën van de NAS naar tape. Ik houd alles bij in een spreadsheet — het is niet super geavanceerd, maar het werkt.

Als volgende stap (of item op mijn to-do lijst) ga ik beginnen met het schrijven van een kort header-manifestbestand aan het begin van de tape. Dit is iets wat ik in mijn backup-scripts kan integreren, en ik denk dat het de moeite waard zal zijn.

Uiteindelijk wil ik kopieën opslaan van mijn Time Machine-back-ups voor de macOS-machines in mijn netwerk. Maar dat kan ik nog niet, omdat ik er somehow voor moet zorgen dat ik niet naar de tape schrijf op hetzelfde moment dat Time Machine probeert naar hetzelfde bestand te schrijven.

Mijn NAS ondersteunt geen btrfs (een bijproduct van het kopen van oudere hardware), wat me in staat zou hebben gesteld om snapshots te gebruiken voor deze functionaliteit. Ik kan dit nog steeds oplossen via enkele slimme trucjes om de Time Machine-shares uit te schakelen (door SMB-toegang tot de Time Machine-share in te trekken), een schone kopie van de sparsebundle te maken en die naar tape te schrijven. Maar het probleem blijft dat ik genoeg vrije ruimte moet hebben om 2x mijn Time Machine-back-ups op te slaan — dus het is hetzelfde probleem van het tekort aan opslagruimte. Wat betekent dat ik een hypotheek moet afsluiten en een nier moet verkopen. Dus, misschien een andere keer...