Offline adattárolás/archivalas

CD-R, CD-RW, DVD, és más optikai tárolók

"Nagyobb" mennyiségű (30-50TB) adatot szeretnék archiválni, évi rendszerességgel kellene adatot visszaállitanom. Ki, mit ajánlana? Amiket néztem:

- sima HDD -> nem tudom hogy mennyire tolerálják, ha adott esetben hónapoking vagy évekig állnak a polcon

- Bluray/Mdisc -> alacsony kapacitás, sérülékeny, drága, cserében azt mondják hogy hosszú életű

- LTO -> drága drive, de relative olcsó a kazetta, megbizható

 

Ki mit ajánl/használ? 

( kruska v | 2022. 01. 13., cs – 11:39 )

Az LTO-nak párja nincs szerintem, főleg ekkora adatmennyiséghez. Linuxban mtx/mt/tar és te vagy a világ mentéseid ura.

LTO 4/5/7-es tape library-k vannak kezem ügyében, soksok szalaggal. Egyetlen kivétellel kifogástalanul működött minden. Az pedig, hogy véletlenül egy felmágnesezett páncélszekrénybe tették be megőrzésre a szalagokat, nem a backup rendszer hibája :)

Pont most hoztam vissza egy mentést egy 2009-ben kiírt LTO4-es szalagról. 

Szerintem legalább LTO5-öt (2010) vegyél, de inkább LTO7-et (2015).

Linux alatt nem kell semmi extra. Ha elvagy parancssorral, akkor nagyon egyszerű: mt-vel a szalagot tudod kezelni, tar-ral pedig írni/olvasni. Általában /dev/[n]st0 eszközként tudod elérni, de dmesg/lsscsi megmondja. Ha lsscsi st0-ként mutatja, ez a visszatekerős üzemmód (minden írás/olvasás után automatikusan kiad egy rewind-ot), a párja pedig az nst0 (non-rewinding), amikor az írás/olvasás után ottmarad a szalagpozíció.

Egy szalagra több filet lehet kiírni egymás után, amíg be nem telik a szalag. Én tar-ral írok, komplett könyvtárakat összepakolva egy szalagos file-ba. Nem érdemes tömörítéssel pazarolni az időt/erőforrásokat, a drive hardveresen egész jól tömörít. 

Kis gyorstalpaló:

mt status - megmutatja hányadik file-ban vagy (file number), illetve státuszállapotokat (BOT, EOD stb.)

mt eom - további íráshoz áll be, az eddig kiírt fileok után.

mt rewind - visszatekeri a szalagot az elejére

mt fsf x - x file-t lép előre

tar cf /dev/nst0 /backup/fs/20220101 - kiírja a szalag aktuális pozíciójától kezdve a megadott könyvtárat/filet

tar df /dev/nst0 /backup/fs/20220101 - összehasonlítja a szalag aktuális fileja és a megadott könyvtár/file tartalmát

cd /restore; tar xf /dev/nst0 - visszaállítja a szalag aktuális pozíciójában a file tartalmát az aktuális könyvtárba

Az sg_logs -a /dev/nst0 kimenetet érdemes nézegetni, van benne sok érdekesség, kiolvassa a drive és a betöltött szalag legfontosabb információit (minden szalagban van egy kis memória, amit a driveok tudnak olvasni):

  Total native capacity [MB]: 6000000
  Total used native capacity [MB]: 2147291
  Volume serial number: MJ90YHP8M1                      
  Volume personality: Ultrium-7

Bocs sose dolgoztam szalagos egységgel, ezért érdekelnek az alábbiak:

Mit csinálsz ha nem fér el 1 fájl a szalagon? (VM image nagyobb 1T)

Hány írást bír ki?

Mi a gyakorlati sebesség?

Léteznek ebből elérhető áron önnáló szalagos egységek is? Új áron 2milka, abból kisebb stroge is kijön...

 

https://en.wikipedia.org/wiki/Linear_Tape-Open

Google a barátod, egyébként meg a számok azok a generációkat jelölik - drive írja a sajátot és olvassa a sajátjánál kettővel régebbi generációs szalagokat is.
Az LTO-4 nyers, tömörítetlen kapacitása 800GiB, a drive tömörítésével optimális esetben rá lehet pakolni 1.6TiB adatot. (Ha jellemzően tömörített nagy fájlokat raksz rá, akkor 1TiB is szűkösen fér rájuk. (tapasztalat...).
Direktben/natívan mt, dd, tar meg bármi :) tudja kezelni, de a darabolást, azt neked kell sw-ből megoldanod.
A kolléga archiválásra kérdezett rá - ott ez mindegy :) archiválásra jellemzően az egyszer írható kazettákat használják, akik tehetik (drágábbak sajnos). Egyébként meg sokszor újra lehet írni egy kazettát - vagy az írásnál fog visítani, hogy hiba van, vagy amikor a kiírt adatokat visszaolvasva ellenőrzöd. (Ha nem olvastatod vissza kiírás után az a Scrödinger backup...).

jelen esetben erősen hiányos a specifikáció, hiszen nem tudjuk, a 30-50TiB-ből mennyit és milyen időközönként szeretne archiválni, illetve hogy menteni és/vagy archiválni szeretne? Nagyon nem mindegy, hogy 50-ből rendszeresen 10-20TiB változik, és azt kell mindenestől archívba rakni, vagy ennél jóval kisebb a delta, és elég azt. És az sincs specifikálva, hogy mekkora a mentési időablak, mennyi idő alatt kell mennyi adatot visszaállítani, ha úgy hozza a sors... De az is fontos lenne, hogy az archiválandó adatmennyiség mennyi idő alatt jön össze? lehet-e havi archívokat csinálni, mondjuk havonta egy LTO-7 kazira?

VM-image-ek archiválására ekkora adatmennyiség esetén én VTL-ben, vagy erős dedup-ot tudó storage-ban gondolkodnék, nem egyedi szalagegységben és 23 tonna kazettában.
 

Eleg egyszeru a keplet. 1x archivalom es utana nem valtozik az adat, tehat polcra felkerul a kazetta es elkepzelheto 1 even belul vissza kell olvasom valamilyen adatot rola, de lehet hogy csak evek mulva. Ha jol ertem LTO5 tamogatja az LTFS-t ami kvazi random hozzaferest biztosit. 

Ezek az LTO számok mit jelentenek?

A generáció számát. Jelenleg LTO9-nél tartunk, ez egy szalagon 18TB nyers adatot tud tárolni, kb. 45TB-ot tömörítve. Bővebben:

https://en.wikipedia.org/wiki/Linear_Tape-Open#Generations

Mit csinálsz ha nem fér el 1 fájl a szalagon? (VM image nagyobb 1T)

Tömörítve valószínűleg elfér még egy LTO4-en is (800G/1.6T), és mégegyszer: nem nekünk kell tömöríteni írás nélkül, egyszerűen csak le kell küldeni a drive-nak, és megoldja. Ha mégsem férne el, vagy nagyobb fileokkal kell dolgozni, akkor nagyobb generáció kell, vagy a mentéseket kell diszken először darabolni, de ez felejtős. Egyébként úgy van, hogy a drive mindig a saját és megelőző 2 generáció szalagjait kell tudnia olvasni, sajátot és megelőzőt pedig írni. Tehát LTO7 drive ír LTO6/7-et, és olvas LTO5/6/7-et.  

Hány írást bír ki?

100+ teljes ciklust LTO7 esetében. Ez több, mint amennyire általában szükség lehet.

Léteznek ebből elérhető áron önnáló szalagos egységek is? Új áron 2milka, abból kisebb stroge is kijön...

Én az LTO library-kat szeretem. Ezek 1U kivitelű eszközök, belepakolható 8 szalag, szépen távolról mtx cserélgeti a szalagokat a drive-ban. Ne a storage-hoz hasonlítsd, teljesen másra való. Itt ha kiírtad szalagra, elrakod egy jó helyre, a következő 10-20 évben nem kell foglalkozni vele (csak mindig legyen egy olyan drive/library, ami az adott szalagot olvassa). 

Egyébként még egy érdekesség: az LTO írás után automatikusan visszaellenőriz, de mindenki visszaellenőrzi utána explicit mégegyszer :)

Mivel távoli gépre kellett áttólni, ezért nálam a tar így nézett ki:

tar cvf - /mnt/sde1 | ssh -p x a.b.c.d "cat > /dev/st0"

Elkészült hibakód nélkül néhány óra alatt.

Ahogy írtad, df-el megpróbáltam összehasonlítani

tar df - /mnt/sde1 | ssh -p x a.b.c.d "cat > /dev/st0"

A következő hibát kaptam:

tar: Az archívumtartalom olvasásának visszautasítása a terminálról (hiányzó -f kapcsoló?)

( render_elek v | 2022. 01. 13., cs – 17:00 )

Szerkesztve: 2022. 01. 23., v – 13:24

Szeretnék tanulás céljából beruházni LTO-ra. Nem számít a generáció. Sőt, igazából a régebbi jobb lenne. Bőven elég lesz 200-300 GB kamu adatot legyártani többszalagos mentés szimulálásához. Linux (Debian) támogatással hogyan állnak ezek? Ebay-en HP-t találtam LTO1 20E alatt, ott RedHat és Suse van megjelölve támogatott oprendszerként. Tudnátok ajánlani márka/típust?

Szórakozni kvázi bármilyen tape drive megteszi, OS felé ugyanúgy "néznek ki" szerintem. Amit érdemes hozzászámolni, az nulladik körben egy scsi-kártya, meg néhány kazetta plusz egy új(!) tisztítószalag költsége - nem hazai árakon, mert ha meglátod, mennyiért adnak itthon egy LTO1 kazettát, secperc alatt befonod a hajadat...

Tisztító kazi?! Ez komoly?! Régebben rácsaptam annak a kezére, aki a videó magnóba megpróbált ilyen förmedvényt bele tenni. Főleg svhs és umatic magnóba. Kereszfejes csavarhúzó és alkohol. Itt ez nem működik?

Scsi van a régi szerverben, habár az 64 bites. Párezerért az is van pci-e-ben.

Kell a tisztító kazi. A drive nyilvántartja a tisztításokat, és megköveteli amikor kell.

sg_logs -a /dev/nst0 megmondja:

  Cleaning action not required (or completed)

  Lifetime cleaning operations: 2

  Media motion (head) hours since last successful cleaning operation: 92
  Media motion (head) hours since 2nd to last successful cleaning: 367
  Media motion (head) hours since 3rd to last successful cleaning: 623

Így már értem, köszönöm!

 

Szerk:

Nem találom ezeket az infokat, csak ezt: Cleaning action not required (or completed).

A drive status értékét is segítenél értelmezni?

https://pastebin.com/6wFCTTRE

https://pastebin.com/AL9S7XdK

Elvileg egy felújított, tisztított drive-ról van szó.

Köszönöm!

drive status = 1107296256 = 0x42000000
Ebből a 0x40000000-nek van értelme az mt-st forrása szerint:

#define GMT_BOT(x)              ((x) & 0x40000000)

Tehát a szalag elején van, BOT azaz Beginning of Tape. Sajnos a következő bitet nem definiálja (0x02000000)
https://github.com/iustin/mt-st/blob/master/mtio.h

Igazából ami ennél fontosabb, az a file number = 0
Amikor több részletben írsz ki szalagra, akkor ez a file number növekszik. Ezek között lehet ugrálni mt fsf/bsf segítségével, illetve mt eom az utolsó kiírt file utánra ugrik, hogy írhasd ki a következőt.

Az sg_logs-ból ezt érdemes még nézni:

Main partition remaining capacity (in MiB): 200448
Main partition maximum capacity (in MiB): 200448

Ez mutatja, hogy még üres a szalag. Még LTO2-nél is tömörít a drive, tehát itt a ténylegesen a szalagon elfoglalt, tömörítetten kiírt adatmennyiséget méri.

pedig elolvastam, mégis megkajáltam :)

szépen beállt a file végére, majd szépen vissza is tekert... :)

majd belejövök... :)

A tömörítéssel kapcsolatban írtátok, hogy ne a tar, majd a drive.. Ez pontosan mit jelent? Csak  szalagsebességgel játszik vagy ténylegesen tömörít. Ha tényleges tömörítést végez, akkor a drive vagy a szerver (csak azért kérdezem, mert p3)?

Az LTO driveok hardveres SDLC (LZS alapú) tömörítést használnak. Nem értek mélységeiben hozzá, így találtam:

The compression is part of the LTO standard, called SDLC, and is a variant of the LZS algorithm. It operates on the data in a block fashion. LTO6 and onward apply this compression to larger data blocks to support higher compression rates.

A gyakorlatban azt vettem észre, hogy teljesen felesleges időt/CPU-t pocsékolni a tömörítésre szalagra írás előtt/közben. Ténylegesen tömörít a drive, ráadásul röptében. Persze eleve tömörített fileokat már nem tud tovább tömöríteni.

+1 - amit viszont célszerű csinálni, az nagyon sok fájl esetén valamilyen tömörítés nélküli formátumba összepakolni, és úgy kiküldeni szalagra (mondjuk könyvtáranként egy tar vagy épp cpio fájl), mert nagyon sok fájl esetén (10M+) igen jelentős időveszteséget tud okozni, ha darabonként kerülnek a fájlok szalagra.

Rendben, köszi.

Már csak egy kérdésem lenne:

tar cvf - /mnt/sde1 | ssh -p x a.b.c.d "cat > /dev/nst0" esetében az írás nem folyamatos. "Rángatja" a szalagot, ami nem jó.

A drive max. 80 MBps-ot igényel. A scsi kártya: Ultra 160. Az alaplapi PCI 64 bites. Van benne gigabites lankártya. Tehát ezek elég erősek a drive-hoz.

Top szerint a szűk keresztmetszet a cpu (ssh 100%). Pedig 2 db 1GHz p3 van benne.

Amit próbáltam: arcfour, de az 8-as ssh-nál már nincs. -c none ami openssh-nál nincs. aes128-cbc ez elvileg a leggyorsabb a támogatottak között, de nem segített.

Szóval hogyan lehetne átküldeni hálózaton keresztül? (Hálózat itt nem a netet jelenti. Gigabiter routerből a backupnál -elvileg- kifelé nem megy csomag, csak egyik szerverről a másikra. A backup szerver meg amúgy sem fogad csomagot máshonnan. Valamint csak a mentés idejére van áram alatt.) Tehát sebesség most fontosabb lenne a titkosításnál.

Nem megy, vagy nem próbáltad? Egyébként meg ahogy nézem, RHEL/CentOS vonalon jobb (é. újabb/tovább támogatott OS release-hez van csomag) a támogatása.

Az mondjuk minimum cinkes, hogy 8.4.17-es PG-t hoz magával, bár gondolom, le lehet beszélni arról, hogy azt használja...

Próbáltam:

Preparing to unpack quadstor-vtl-ext-3.0.58-debian-x86_64.deb ...
Kernel build dir /lib/modules/5.10.0-10-amd64/build/ does not seem to be valid. Cannot continue.

szerk.:

Beállítás: quadstor-vtl-ext (3.0.58) ...

Performing post install. Please wait...
Synchronizing state of quadstorvtl.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable quadstorvtl
Created symlink /etc/systemd/system/multi-user.target.wants/quadstorvtl.service → /lib/systemd/system/quadstorvtl.service.
Building required kernel modules
Running /quadstorvtl/bin/builditf. This may take a few minutes.
ERROR: Building kernel modules failed!!!
Reboot this system now if the VTL devices are accessed over Fiber Channel

 

A 9-es Debian a közös nevező. Lehet, hogy játszni felrakom azt.

( coco | 2022. 01. 24., h – 14:20 )

Valaki LTFS-t használ? Valamivel egyszerűbbnek tűnik a használata, mint az mt-nek

( coco | 2022. 01. 24., h – 14:54 )

Szerkesztve: 2022. 01. 24., h – 15:03

Mennyire megbizhatóak a log-ok ezekben vagy egyáltalán hogy kell értelmezni? Ha lehet hinni a drivenak, akkor 22e km van benne :) Ami nagyjaból 26e kazetta hossza (egy LTO5 kazetta 850m). Ehhez képest 555 load van benne, ami azt jelenti hogy egy kazira 40km jut (tehát 47 szalagnyi). Tehát mondjuk egy kazit 24x írtak (1 visszatekerés, 1 írás?) 

 

root@pop-os:/home/rezo/ltfs-master# sg_logs -a /dev/nst0 | grep metr
  Lifetime metres of tape processed: 22571363
root@pop-os:/home/rezo/ltfs-master# sg_logs -a /dev/nst0 | grep hour
  Lifetime power on hours: 28015
  Lifetime media motion (head) hours: 1482

root@pop-os:/home/rezo/ltfs-master# sg_logs -a /dev/nst0 | grep load
  Lifetime media loads: 555
 

 

Egyébként bár eléggé elrettentőnek tűnnek a fenti számok, az adatlap alapján túl sok félni valóm nincs:

Description Specification MTBF (100% duty cycle) 250,000 hours

Load/unload life (only valid when the drive is operated Full–height: 120,000 cycles in a standard office environment) Half–height: 80,000 cycles

Population MSBF 100,000 cycles

Head life (typical) 60,000 hours

Reposition life 1,000,000 cycles (media limited)

Lifetime of drive (5 years at 100% duty cycle) 43,800 hours

Maximum cartridge uses 20,000 threads

Cartridge Extraction Force 2.25N to 5.8N (0.5 lbf to 1.3 lbf)

Backup failure rate <0.1%

Restore failure rate <0.001%

Régen egy HP külső cuccban cserélgettem a kazettákat naponta. Abból egyet biztos cseréltünk 5 év alatt.

Most egy Quantum Library van, egy IBM ULTRIUM-HH6 lakik benne. Naponta egy LTO6-os telik be, teszi a dolgát már több mint 6 éve. A szoftver kukul meg néha (BackupExec), a hardver egyszerűen megy.

( coco | 2022. 02. 01., k – 20:38 )

Az LTFS jól működik egészen addig amíg nem akarok nagy mennyiségű adatot visszaállítani. Ilyenkor gyakorlatilag folyamatosan seekel. Van erre valami értelmes megoldás?

( render_elek v | 2022. 02. 03., cs – 19:57 )

Elvileg van egy LTO2-es drive-om 5 szalaggal, ahogy fentebb írtam játszósnak.

Amíg megérkezik olvasgatom a doksikat. Egyikben ezt találtam:

file and directory ownership is not recorded to tape

Akkor az rsync vagy a tar hogyan viselkedik?

Őszintén nem tudom, hogy az LTO2 tudja-e, de kétlem, hogy ebben lenne eltérés. LTO7: 

[ rc0 ]-[root@ltlxc01]-[~] # tar tvf /dev/nst0
drwxr-xr-x root/root            0 2022-02-01 10:42 DEV/saparch/202201/
-rw-rw---- 1000/sapinst 285540352 2022-01-14 19:01 DEV/saparch/202201/backup_logz.1160
-rw-rw---- 1000/sapinst 191102976 2022-01-19 23:00 DEV/saparch/202201/backup_logz.1177
-rw-rw---- 1000/sapinst 218693632 2022-01-27 07:30 DEV/saparch/202201/backup_logz.1201

A szalagra/ról a device-t írni/olvasni tudó userrel tudsz írni/olvasni, tök mindegy, hogy a kiírt fájl kié-mié mié volt. Ha tar-ral, cpio-val írsz rá, akkor a kiírt adatokba belekerülnek a fájlok metaadatai is, és visszaolvasva/értelmezve a bájtok sorozatát, ez az információ is visszajön.