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? 

  • 4078 megtekintés

( 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. 

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(:

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.

( cyclops | 2023. 04. 22., szo – 08:51 )

Van egy LTO4-es meghajtóm, meg egy rakás kazettám.

A Volume barcode-ot olvasni tudom:

sudo sg_logs -a /dev/nst0|grep 'Volume barcode'|awk '{ print $3 }'

Tudja valaki, hogyan lehet ezt a Volume barcode mezőt írni? Vannak olyan kazettáim, amin nincs barcode és ez a mező üres.

( end | 2023. 04. 22., szo – 09:43 )

Szerkesztve: 2023. 04. 22., szo – 09:43

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?

( cyclops | 2024. 01. 06., szo – 16:46 )

Szerkesztve: 2024. 02. 25., v – 09:39

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.

( Carter | 2024. 02. 25., v – 16:41 )

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)

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.

Retrieval Time Retrieval Requests
Expedited $10.50 per 1,000 requests
Standard $0.0318 per 1,000 requests
Bulk

$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/

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....

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.
 

( GaLbi | 2024. 02. 26., h – 11:46 )

AAWS helyett javaslom inkább megnézni a WASABI-t. Extra költség nélkül van lehetőség visszaállítani.

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....

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....

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....

Es akkor elokerulnek a pendrivok, ide-oda mentesek, es leszarjak a halozati meghajtot.

É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....

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.

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.

"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."

 

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 :-(

"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."

 

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...)

 

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