"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?
Hozzászólások
Az LTO-nak párja nincs szerintem, főleg ekkora adatmennyiséghez. Linuxban mtx/mt/tar és te vagy a
világmenté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.
Hmmm, itt relative olcsón lehet drive-ot venni:
HP StorageWorks Ultrium 1760 EH919B LTO-4 SAS BRSLA-0703-DC (interbolt.eu)
Ehhez csak egy mezei PCIe SAS vezérlő kell és kész. Speckó szoftver vagy valami? Ez a szalagos mentés eddig kimaradt az életembő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.
Korábban én is lto streamer párti voltam. De ma már van jobb, személyes használatra https://en.wikipedia.org/wiki/M-DISC
Persze adatmennyiség függő.
"Persze adatmennyiség függő." - No igen... GB-os nagyságrendben tökéletes, de ahol néhány TiB vagy több a tárolandó adatmennyiség, ott nem rúg labdába.
Ezzel a Schrödinger backuppal eszembe juttattad egy régi önszopatásomat, amikor a friss mentést a /dev/null-ta bontottam ki, bízva a tar crc-jében, mert akkor nem lassítom az egészet az összehasonlítással.. A vége egy indexhiba lett,egyik legfontosabb adattáblában, meg annak a kipatchelése(:
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
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.
100+ teljes ciklust LTO7 esetében. Ez több, mint amennyire általában szükség lehet.
É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 :)
Beruhaztam egy LTO5-os drive-ra. Ha jol ertem ket generaciot lehet ugrani olvasassal, tehat mondjuk 10 ev mulva, beruhazok egy LTO7-re, azzal meg tudom majd olvasni az LTO5-os szalagokat.
Így van, de az a tapasztalatom, hogy nagyon nagy ez a piac, még a mai napig simán találsz működő drive-okat bármelyik generációhoz. A szalagok kb 30 évig bírják.
ja, meglájtuk 30 év múlva :) Mindenesetre király, hogyha most archiválok akkor életemben majd csak még egyszer kell majd átemelni egy másik tape-re, utána majd a gyerekeim foglalkoznak vele (vagy nem)
Kérhetnék linket, hogy hol vetted.
Köszönöm.
Interbolt.eu
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ó?)
Annyi hozzá, hogy LTO 5 fölött már van LTFS is amivel nagyon egyszerű a kezelése.
Egyebként pedig mindenképpen valamilyen backup szoftverrel kezelném.
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:
Í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:
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.
Rendben, köszönöm!
A tisztítás akkor történjen, amikor már nem tudom visszaolvasni, vagy fixen minden x üzemórában? De akkor mennyi az x? :)
Tippre:
[ $( sg_logs -a /dev/nst0 | grep -c "Cleaning action required") -gt 0 ] && tisztogatni_kell :-)
"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." - Ha a megfelelő, azaz "n"-nel kezdődő (no-rewind) device nevet használja.
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:
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.
Ha nem akarsz titkositast, akkor nezd meg az rsh-t.
hasznalj netcat-ot, felesleges ss-val bekodolni az adatfolyamot
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Köszönöm, ez bevált.
30-40 % cpu a dual p3-on.
Az egyik procit akár el is adhatnám hajbinak, ha volna időm megkeresni a cpu terminátort ;)
Már csak a bufferen kell egy kicsit kalapálni, és akkor pöpec lesz :)
Esetleg nézd meg ezt a VTL implementációt, a tape sw részét ezzel is tudod próbálgatni:
https://quadstor.com/
De jó lenne...
Kár, hogy deb 11-el nem megy.
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:
szerk.:
A 9-es Debian a közös nevező. Lehet, hogy játszni felrakom azt.
Valaki LTFS-t használ? Valamivel egyszerűbbnek tűnik a használata, mint az mt-nek
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.
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?
Ha nagy mennyiségű adatot kell menteni/visszaállítani, akkor más megoldást kell használni.
Elvileg ez szekvenciálisan bír copy-zni, gyakolatilag azonban nem
ltfs/ltfs_ordered_copy at 42c08710bda914e2bf0ac3749c69d830e9b45577 · LinearTapeFileSystem/ltfs (github.com)
Végülis megoldódott, lehet szekvenciálisan olvasni a fenti scripttel, csak a python modulban a függvények megváltoztak ezt kellett updatelni, ha valakit érdekelnek a részletek
ltfs_ordered_copy is really slow · Issue #334 · LinearTapeFileSystem/ltfs (github.com)
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:
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:
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.
Van egy LTO4-es meghajtóm, meg egy rakás kazettám.
A Volume barcode-ot olvasni tudom:
Tudja valaki, hogyan lehet ezt a Volume barcode mezőt írni? Vannak olyan kazettáim, amin nincs barcode és ez a mező üres.
Szerintem írni nem tudod, legalábbis egykönnyen. Ezzel tudsz generálni nyomtatáshoz saját kódokat :
https://kelvin.nu/barcode
Illetve tudod használni a "Volume serial number" mezőt, ez egy gyári egyedi érték.
Köszi. Sejtettem, hogy nem lehet (egyszerűen) írni. A serial numbert használom, ahol nincs vonalkód, de reménykedtem, hogy nem kell bonyolítani a scripteket.
Kérdésem., mondjuk 2 TB adatmennyiséget, - tömörítés nélkül és nagy fájlokkal számolva, - kb. mennyi idő alatt lehet szalagra írni?
A kérdésed pontosításra szorul.
- Milyen drive? LTO4 vagy LTO9?
- Hány drive van párhuzamosan?
- Hány példányban kell kiírni?
- A forrás mekkora sebességgel tudja küldeni az adatokat a drive felé?
Wikipedia alapján: https://en.wikipedia.org/wiki/Linear_Tape-Open
Általában nem az LTO drive a szűk keresztmetszet. Már az LTO-7 is 300 MB/s sebességet tudna.
Sok helyen elbukhat: SAS/FC kártya, SAS/FC driver, diszkrendszer sebesség, nem megfelelő blokkméret megválasztás.
A kb. 1 évvel ezelőtt beszerzett LTO4-es meghajtóm (IBM LTO Ultrium 4-HH) bedöglött. Nem akarta betölteni a kazettát: próbálkozott percekig, aztán 6-os hibát írt ki a hétszegmenses kijelzőjére. Egyébként 50-100 mentést csináltam ezidő alatt. Vettem helyette egy HP LTO Ultrium 4 1840-at, ez teljes magasságú.
De azért csak szétszedtem az IBM meghajtót és rájöttem, hogy azért nem sikerül a betöltés, mert nem tudja kivenni a leader pin-t a helyéről. Egy hangyányit elferdült a pin kiszedő tengelye, nem volt feltűnő. De miután visszahajlítottam, megjavult. Ez egy gyakori probléma? Vagy csak a fél magasságú drive-okra jellemző? Nem néztem meg HP belsejét, de a mechanizmus ami az IBM belsejében van, elég rosszul néz ki gépészeti szempontból: egy oldalon van rögzítve a pin kiszedő tengelye és úgy mozgatja, a másik oldal kenés nélküli fut egy sínben.
Megkerdezhetem, hogy hany TB osszadatmennyisegrol van szo?
Es hogy a szalagos olvaso+tartalek olvaso+szalagok eddig mennyibe fajtak?
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
kissé offtopic, de valójában ontopic: Ha csak mondjuk 100 gigabájt anyagot kellene archiválni, akkor arra ki mit ajánlana? Az LTO kissé túllövés. Az ssd-ken tárolás úgy, hogy 3 példány van belőle, hátha nem megy szét? Hdd-kből ugyanígy három darabon? Vagy 1 ssd/1hdd/1pendrive?
Ssd jelenleg nem a legideálisabb adatmentésre, ha 2 példány kell. 2 hdd példány fölött meg lehet próbálni, mint további lehetőség.
Én vennék 2-4 darab megbízhatóbb márkájú 3,5" Sata Usb 3.1 külső tápegységes hdd/ssd tartót, majd 2 darab 5 év garanciás Wd márkájú 3,5" Sata merevlemezt: 1 darab Wd Gold (1-24Tb), 1 darab 5 év garanciás Wd valamit még innen, amilyen méret kell. Ha kevesebb a keret, akkor másodiknak 5 év garanciás Wd Red Pro (2-22Tb) vagy 3 év garanciás Wd Red (2-6Tb) simát. Ha különösen fontos, akkor 3. vagy akár 4. példánynak Ssd-re tenni, ami komolyabb, például itt: Ultrastar DC Sata Ssd (120Gb - 2Tb). Én 3-4 példányból csak 1 Ssdt választanék, a többi 5 év garanciális Hdd.
Ha 2Tb vagy kisebb, akkor Mbr, primary partition. File rendszer: Ntfs 4k blokkméret, vagy Ext4, ha Linux alól éred el. Linux esetén lehet van még ideálisabb file rendszer erre, de Ext4 nagy előnye, hogy a helyreállító programok széles körben támogatják. Mindezt, hogy minél könnyebb legyen helyreállítani.
Ha 100Gb az adat, és 2Tb tárolókat veszel, akkor rámásolni különböző mappában legalább 5 példányban mindegyikre. Ha biztonságosan tárolod, például széfben, akkor a titkosítás kihagyható, ha ez nincs meg, akkor Veracrypt vagy hasonlóval titkosítani. Akkor visszont a jelszót nagyon meg kell őrizni, különben bukod az adatot. Ha az a cél, hogy minél jobban megmenthető legyen az adat, de nem titkos, akkor kihagyható ez a Veracrypt, mert ha megsérülne a hdd, sokkal nehezebb egy titkosított adattárolóról menteni, mint egy simán elérhető file rendszerről. Nagy eséllyel ha sérül az adattároló, akkor csak a Hdd esetén fogod tudni visszanyerni részlegesen vagy teljesen az adatot. Nekem ha Ssd elromlott, abból "tégla" lett, hogy a Bios már nem is látta. Tudom, lehetett volna vinni cégekhez, akik komoly összegért életre keltik akár az ssdt, de volt mentésem, és adatvesztés nem történt.
Ha kell konkrét javaslat külső Usb Sata kerethez, mondok nekem bevált márkákat, típusokat. Mert az adott márkán belül is van ami nem az igazi vagy széria hibás.
Ilyenre HDD-t ajánlok. Az SSD-nek az a baja, hogy adatot felejthet hosszú távon. Elvileg, mert gyakorlatilag a legtöbb embernél évek óta nem használt SSD-kről sem tűnt el adat, de az elvi lehetősége megvan.
Szerk.: mivel ez nagy adatmennyiség, ennél már az LTO is megérné, a drive drága hozzá, de kijön párszáz dollárból, a kazetták nem drágák.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sok paraméter kéne még hozzá, de a kapott info alapján pl ez:
AWS S3 Glacier Deep Archive
For long-term data archiving that is accessed once or twice in a year and can be restored within 12 hours
All Storage / Month $0.00099 per GB
Ez most komolyan azt jelenti, hogy 60 gigabájt adatot ~300 forintért tárolnak évente??
Pontosan és van mögötte szolgáltatás, nem a házaddal együtt égnek el a HDD-k,....
Én havi 1,0 USD-t fizetek kb 100GB archive anyagért + ott fut egy minimális (csak család) használtságú statikus weblap. (AWS S3)
Nekem ennyit megér.
van ott azert mas is: https://aws.amazon.com/s3/glacier/pricing/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ehhez kellenének a nem ismert paraméterek is, de az hogy 1x fetöltsd és ott meglegyen az kb. ennyi.
jah hat ha egyszer feltoltsd el ott meglegyen ahhoz nekem is kuldheted en ingyen megteszem! :D ugyan a visszaallitas az 1000$, de hat a tarolas az olcso! :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
egyreszt megvan. Masreszt pedig meg mindig olcsobb, mint egy Kurt kft.
Ezelott van elvileg 2 masik backupod. Ez a harmadik.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
A letöltés is kabátgomb árban van ha kiszámolod. Össze se vethető a HDD-k, az SSD-k és mindeféle _akár szériahibás_ (mint fentebb említették) USB-s enclosure-ök árával)
Kérdés: Egyébként havonta hányszor akarsz _archivból_ visszaszedni _mindent_? Akkor ott valami komoly gond kell hogy legyen.
Ez pont arról szól hogy meglegyen és ha a helyi munkatárolóról és a backupról is "eltűnik" az eredeti file valami bénázás folytán, akkor ez biztosan ott van vésztartaléknak és visszakapod.
Nálam a gépemben egy SSD-n ott van a 100 Gb adat (fotók), van róla egy HDD-s mentésem a szekrényben és a felhőben az archív. Eddig (4-5 év) 2x kellett pár filet visszaszednem onnan.
Helyen kell kezelni, mint mindent.
Ha mar deep archive-bol kell visszahozni az adatot, akkor az ezer dollar lepkefing, meg kituntetest is kapsz erte, ha annyibol megoldottal egy ilyen outage-et.
Hát igen, az átlátható könnyen becsülhető egyértelmű nemapróbetűs kreatívan-értelmezett (vendor vs ügyfél nem ugyanazt érti) klóud elszámolás!
$0.00 per 1,000 requests
Ezt valaki segitene ertelmezni? 1 request az mennyi adat? 1KB, 1MB, 1GB, 1Fajl, 1metaadat?
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Hát, nem állítom hogy be tudnám lőni, hogy mi mennyibe fog kerülni, de pl.:
Request Example:
Assume you transfer 10,000 files into Amazon S3 and transfer 20,000 files out of Amazon S3 each day during the month of March. Then, you delete 5,000 files on March 31st.
Total PUT requests = 10,000 requests x 31 days = 310,000 requests
Total GET requests = 20,000 requests x 31 days = 620,000 requests
Total DELETE requests = 5,000×1 day = 5,000 requests
Assuming your bucket is in the US East (Northern Virginia) Region, the Request charges are calculated below:
310,000 PUT Requests: 310,000 requests x $0.005/1,000 = $1.55
620,000 GET Requests: 620,000 requests x $0.004/10,000 = $0.25
5,000 DELETE requests = 5,000 requests x $0.00 (no charge) = $0.00
Szóval az darabáron van.
https://aws.amazon.com/s3/faqs/
copy /b az összes fájlt 1-be, aztán feldughatják maguknak a per darab tranzakciós (v. kényelmi?) díjukat
köszönöm. mindenkepp erdemes tarozni
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Ja, de ha csak 1 file kell, akkor meg szedheted vissza mind a 100G-t. Ezt is mérlegelni kell.
mobilrol neztem es a 3-bol a kozepsot valahogy atugrottam.
Azaz a retrieval pricing, retrieval request pricing es a provisioned expedited retrieval pricing
-bol valahogy ahogy valtottam a datacenterek kozott, csak a request arakat lattam, es valahogy ugy jott at, hogy valamelyik datacenterbol a gb utan valamelyiknel meg a request utan kell fizetni.
Szoval mea culpa. De igy is kijön egy minimum meret ami alatt nem erdemes feltolteni, mert a sok request pricing megesz reggelire.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Vagy backblaze, telefonról nem fogok utánaszámolni, de vagy igen, vagy nem.
Bár bocs, eleve offline volt a kérdés.
Nekem 1TB-s 3.5" diszkjeim vannak, kopaszon. Van USB 3.0-s dokkoló, ami 2 diszket tud fogadni.Kitolom ugyanazt 1 példányban, majd az USB dokkolóba beteszem a 2. diszket is és megnyomom rajta a copy gombot. Bitről-bitre leklónozza a diszket.
Vagy kivárom és a második diszkre is én másolom fel az adatokat ismét.
Ha nagyon fontos a téma, 3 diszken van jelen és több helyre vannak elrakva a diszkek. Mindez _titkosított_ fájlrendszeren.
Két diszkfiók, mdraid tükör, egyszer kiírni, és diszkeket külön-külön elrakni. Mivel mdraid, így egyedül is tökéletesen használható a diszk, természetesen utána már nem lehet/nem szabad megpróbálni összerakni belőlük a tömböt.
AAWS helyett javaslom inkább megnézni a WASABI-t. Extra költség nélkül van lehetőség visszaállítani.
Ja, csak az egy nagysagrendel dragabb mint a S3 Glacier Deep Archive.
Az csak a mezei "S3"-al van pariban.
100G eseten kemeny 0.7$/ho. ez kurva draga!!! :DDD
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
miota mindent *is* mentenek a kollegak, (erre kene valami ertelmes otlet, hogy egyreszt masoljak fel ami lenyeges, masreszt csak azt masoljak fel).
Noh most 12TB-nal jarok, szerintem 400GB korul lehet a hasznos.
12TB havi 4500Forint a fenntartasi dij.
Ha ki akarom szedni, akkor 800khuf.
Namost egy vinyo most 105ezer forint (brutto), ami 12TB-os, vagy 18TB 125eFt.
Mondjuk vonzo egy teljesen fuggetlen lab. De azert anyagilag nem a hude olcso. Szerintem.
Szoval nem kicsinyleni.
Evekig tartott mire valahogy sikerult ravenni, hogy mentsek fel a fontos dolgokat es ne az asztal legyen 160GB.
Most meg ott jarok, hogy valaki a komplett C meghajtot felmenti a windows konyvtarral egyutt, titkositva. Igy sokaig ki se derult.
Van nalam hianyossag, de a human oldal. Kene valami tutorial, hogy hogyan kene kezelni ertelmesen.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Ezt a koncepciót át kellene gondolni, hogy csak felfelé töltök és nincs szükségem letöltésre. A mentést ellenőrizni is kell néha, és ezért inkább havi szinten rakok bele 12USD helyett 100USD, hogy ez végre lehessen hajtani.
ilyen arazas mellett ez csakis az n+1. backupkent johet szoba. A mentesbol szemezgetve lehet random par fajlt visszaellenorizni, ha nagyon muszaj. A tobbire biztosan nincs keret.
Vagy el kell engedni az amazont.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
igen, ez az amazonos cucc csak akkor jo, ha a tenylegesen nagyonnagyon fontos adataidat akarod menteni es azok kb 1T alatt vannak. felette mar teljesen maskent jelent arban.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
De ez egy archivalo megoldas, nem backup. Legalabbis nem abban az ertelemben, hogy amikor a user leonti kaveval a laptopjat, akkor ebbol allsz vissza.
A deep archive abban segit, amikor peldaul jogszabalyi kotelezettseget 10 evig megorizni az adatokat, vagy amikor mar akkora a baj, hogy leegett az adatkozpont es az offsite backup is.
Lehet ez ellen tenni, csak egy kicsit be kell keményíteni.
Első szabály: a munkaanyagaidat tárold fájlszerveren (amiről van napi mentés), és legyen egy-egy felelős minden szervezeti egységnél, aki időnként ránéz, hogy nincs-e tele tiktokos videókkal, cicás képekkel. Ha vannak szenzitív adatok, akkor azt jogosultság védett mappában kell tárolni, csak azoknak adva hozzáférést, akiknél ez indokolt. Tehát a HR-esnek legyen saját tárhelye, és ne kelljen arra hivatkozva kétévente nagyobb SSD-t kérnie a gépébe, hogy márpedig az szupertitkos, amit tárol.
Második szabály: maszek anyag tárolása tilos a céges gépeken. Néhány random ellenőrzés után a többség megérti, hogy ez nem a főnök hétfő reggeli vicce volt.
Ezek még elég nagy cégeknél is beválnak, csak következetesen be kell tartatni a szabályokat. Nyilván kell némi edukáció a cégvezetés felé, hogy az üzletmenetet mennyire veszélyezteti, ha nincsenek ezek a szabályok megfogalmazva és betartatva.
Es akkor elokerulnek a pendrivok, ide-oda mentesek, es leszarjak a halozati meghajtot.
Volt egy olyan 5letem, hogy hetfonkent automatan ujrahuzom a gepeket, es akkor odavesznek az anyagok, amik nincsenek kimentve. Elkaszaltak. Pedig szerintem jo modszer lenne.
Egyetlen egy mukodo megoldas van, hogy minden uzletmenet egy weboldal moge kerul. Es akkor az amogotti reszt mentjuk.
Van szamlaiktato, dokumentumiktato, gmail, stb. Szerintem efele megy a vilag is.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
És ilyenkor lépnek közbe az Endpoint Security megoldások. Normális cégnél vagy nem engedik a pendrive-t (tiltják több módon is) vagy csak a céges pendrive-okat engedélyezik titkosítással a privilegizált felhasználóknak. Így hiába teszik be idegen gépbe, nem fognak hozzáférni a titkosítás miatt.
A hálózati meghajtó pedig elavult, korszerűtlen megoldás manapság - a rengeteg előnye mellett és egyszerűsége. A világ a Onedrive, Sharepoint, mindenféle dokumentum- és fájltároló megoldás felé halad, amiket enterprise szinten könnyű menedzselni.
Igaz. Kell akkor valahogy beszelnem a felsovezetokkel, mert oket kell elsonek meggyozni.
Mondjuk mar valakinel sajat laptop is megjelent, mert "kenyelmesebb", es nincs lekorlatozva, mint a ceges, igy o inkabb azon dolgozik. Van baj.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Nincs ezzel baj. Kellenek ilyen cégek és cégvezetők is.
Csak ne csodálkozzanak, ha beüt a krach - adatszivárgás, adatlopás, ransomeware stb.
Lehet olyat, hogy a saját laptop csak egy külön AP-re mehet fel, ami nem enged hozzá a céges hálózathoz. Meg lehet Etherneten is mac szűrés, meg hasonlók, és akkor a saját eszközzel max. a publikus internetes szolgáltatások lesznek elérhetőek. Nálunk ez bevált jó ideje laptop, tablet, okosteló esetén egyaránt.
covid ota elvaras, hogy a ceges eroforrashoz kivulrol is hozza lehessen ferni. Rengetegen dolgoznak meg 1/2/3/4 napot homeoffice egy heten.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Igen, erre van az, hogy a dolgozó kap céges laptopot, amit hazavisz, és otthonról mondjuk VPN-en lép be a céghez. És nincs rendszergazda joga a céges gépen, és nem tudja a tűzfalat lelőni, hogy a VPN kapcsolat mellett direktben ki tudjon menni a nyílt internetre is, beszopva minden szart.
"mar valakinel sajat laptop is megjelent, mert "kenyelmesebb", " - Ha a NAC és a végpontvédelem beengedi a hálózatra, akkor hajrá... Ja, hogy ahhoz a céges policy-nek meg kell felenie...? Így járt...
Igen, köszönöm, ez alap, el is felejtettem írni. Az USB port nincs letiltva csak az usb mass storage eszközök, tehát egeret, szkennert, akármi mást lehet használni. Nyilván ezt is lehet hackelni, meg lehet otthoni NAS-ra tolni adatokat, de ha a céges adatvédelmi szabály ezt tiltja, akkor legalább másolás közben bűntudatot érez a felhasználó :-)
Nyilván a végletekig agyonszabályozott tűzfalas és VPN-es megoldásokkal ez is korlátozható, csak egyszer eljön a pillanat, amikor valahol valaki megbolygatja az IP-cím tartományokat, és akkor egy napig áll a teljes cég :-(
Ez igaz, de elég sok cég nem költ ilyesmire. Vagy ha van is ilyen, csak a nagyonmuszáj anyagok kerülnek fel. Az átlagmancika, aki egész nap Word dokumentumokat krampácsol, annak is örül, ha megtalálja az előző napi munkáját, nemhogy még Sharepointra is mentsen. Itt annyit lehet csinálni, hogy az Office alkalmazásokban az ember beállítja, hogy vagy az elsődleges, vagy a backup mentési hely valamilyen szerveren legyen. Vagy a szebb megoldás, hogy lokálisan kialakít egy mappastruktúrát, ami napi ütemezéssel mentésre kerül. Sajnos a Windows még mindig nehezen viseli, ha az user default mappája hálózati tárhely. Elég egy kisebb kiesés, egy befejezetlen fájlművelet, és a felhasználói profil megy a levesbe.
Még azt is meg lehet csinálni, hogy a Windows desktop mappától el lehet venni a felhasználói jogot (feltéve, hogy nem minden user rendszergazda is egyben), és akkor nincs az a veszély, hogy az asztalt telefossa fájlokkal.
"A világ a Onedrive, Sharepoint, mindenféle dokumentum- és fájltároló megoldás felé halad, amiket enterprise szinten könnyű menedzselni." - Kivéve, ha a felügyeletet ellátó hatóságnak a "felhő" szó említésétől heveny lábrázása lesz - mondjuk arra meg ott vannak a privát cloud megoldások... (a sörpont érdekes állatfaj - drága, de legalább remek termékcsapda...)
Hajjajj.
Cég-cég viszonylatban lett volna egy közös projekt. Mindkét fél M$ szarságokat használ, sharepoint, teams.
De hát a teams-ben le volt tiltva a szervezeten kívüli megosztás... sebaj, akkor jött a google drive :D
Erről van gyakorlati tapasztalata valakinek?
https://www.hetzner.com/storage/storage-box/
Van, mi a kerdes? :)
Stabil? Megbízható?
Wasabi? AWS S3 Glacier Deep Archive? Vagy inkább Hetzner?
Nem remlik, hogy barmikor is lett volna problemam vele, de ahogy lentebb irtak, ez egy random szerver, valamilyen RAID-del. Allitolag. Lehet az egyik laba a backup strategiadnak. A Glacierrel szerintem nem osszemerheto, a deep archive arra van, hogy az oda feltoltott adatokat a vegtelensegig ott tarold fillerekert, ez meg csak egy storage szerver, amire ssh-n, meg mindenfele mas protokollon keresztul feldobalhatod a cuccaidat. Nyilvan dragabb is fajlagosan, cserebe nem fel nap, mire szukseg eseten visszakapsz belole valamit.
szerk: illetve hat a thread cimevel ellentetben ez nem offline backup, azt is kalkulald bele
Korábban borg és restic backendként használtam első szintű backupként. Néha kicsit lassúcska, de amúgy nekem eddig megbízható volt.
Önállóan kevés, ez csak egy szerver, sok diszkkel RAID-ben.