Soluţie NAS pentru acasă

Depinde de datele pe care le ai. În zi de azi ai opțiuni de deduplicare, cu care mai economisești din spațiu, iar pentru backup ai variante ieftine în cloud.

Rulez eu un script open source (nici să mor nu-mi amintesc cum îi zice) care face deduplicare și arhivă incrementală, apoi duce delta-ul într-un bucket S3 la BackBlaze. Cei vreo 90GB de userdata (din care vreo 65GB mailuri) s-au redus inițial la vreo 23GB, care s-a uploadat în câteva ore. Din noiembrie până acum, spațiul total consumat e 45GB, care mă costă 0,65$ la fiecare 3 luni, iar upload-urile automate sunt foarte mici.

PS: backup are ca scop primordial să ajute readucerea unui sistem la starea funcțională după un incident. De-aia ai backup incremental cu versiuni pe ultimele câteva săptămâni, ca în caz de corupere a datelor să poți merge gradat în urmă în timp până găsești o copie fără integritatea bușită (și de preferat mai recentă decât RPO). Dar un sistem de backup e calificat să țină datele un timp limitat, gen 7 săptămâni. Stocarea datelor pe timp mult mai îndelungat (10 ani, 50 ani etc.) se face prin sisteme de arhivare, cu stocare lentă și acces extrem de rar, dar cu funcții suplimentare de indexare, catalogare, metadata management, conversie de format pe parcursul anilor, access logging și altele. Nu e doar stocare chioară și nu e backup.

Tocmai am avut un bid pentru un sistem universal de arhivare pentru petabytes de date medicale, cu retenție 7 ani de la decesul pacientului, cu implicații legale, și a fost un subiect foarte interesant. Informatica merge bine pentru date structurate dar au o licențiere per utilizare a sistemului, poate să devină scump; OpenText e bun la date nestructurate, dar scump. Mai ai variante DIY în Azure sau AWS cu stocare tot acolo sau în Google Cloud. Sunt și alte soluții open source, gen IRODS, dar depinde de tipul de date și nevoile de arhivare.
 
Last edited:
Cand ai cantitatea aia de date din exemplul respectiv, imi cam imaginez ca nu ai mailurile personale pe care le duci in S3. In esenta la volumul acela de date as zice ca mai degraba el insusi este locul de stocare al backupurilor.
 
Daca tot se discuta despre backups, o chestie care nu e mentionata prea des e verificarea lor. 2 exemple:

- un tip se plangea ca a fazut backup pe BackBlaze si cand a avut nevoie sa faca restore a descoperit ca viteza nu e simetrica, cea de backup e mult mai mare decat cea de restore si ce credea el ca o sa dureze la restore a durat cu cateva zile mai mult
- ultimul Cumulative Update (16) pentru MS SQL Server 2019 schimba ceva in formatul de backup comprimat si criptat, ceea ce il face incompatibil cu orice versiune inferioara de SQL 2019. Intrucat asta nu s-a mai intamplat niciodata in trecut, a fost o surpriza masiva pentru unii, in special pentru cei care facusera o testare sumara si au vazut ca un backup simplu merge, unul comprimat merge, unul criptat merge, dar nu au incercat combinatia. Si intrucat unii au facut update la sistemul principal, dar nu la cel de DR, s-au trezit ca le pica testul de DR. Noroc ca era doar un test si solutia era simpla, au facut update si la sistemul ala.

Mai stiu ca erau unii care aveau backup pe ani in urma, dar nu il verificasera niciodata si cand au avut nevoie sa faca restore, o parte era corupt. Au descoperit ca "best practices" sunt bune doar daca le urmezi, nu si cand le ignori.
 
De-aia se zice că ai un sistem de backup nu atunci când salvezi datele pe el, nici când le verifici, ci doar după ce le-ai și restaurat cu succes.
 
AdrianB1 said:
- un tip se plangea ca a fazut backup pe BackBlaze si cand a avut nevoie sa faca restore a descoperit ca viteza nu e simetrica, cea de backup e mult mai mare decat cea de restore si ce credea el ca o sa dureze la restore a durat cu cateva zile mai mult
Click to expand...
Ăsta este și unul dintre motivele pentru care este greu să verifici un backup pe care-l faci direct acolo. De-aia este preferabil să faci backup on-prem, testezi apoi dai upload și stai liniștit că ce-i acolo funcționează.
 
puterfixer said:
De-aia se zice că ai un sistem de backup nu atunci când salvezi datele pe el, nici când le verifici, ci doar după ce le-ai și restaurat cu succes.
Click to expand...
Din ce am studiat până acum Ansible mi se pare absolut godlike pentru automatizarea taskurilor de genul.
 
Anul trecut am avut niște discuții interesante cu niște application manageri ale căror aplicații le migram pe un hosting profi (datacenter dedicat, servicii standardizate) ca să închidem un datacenter vechi on-prem al clientului și să punem stop la degringolada customizărilor pe care le făcuseră anterior - ambele cerințe explicite ale clientului.

Unul.
- Și backupurile ni le migrați?
- Ăăă nu, de ce?
- Păi și dacă se întâmplă ceva, cum facem restore?
- Ah păi de-aia ai task să verifici și să confirmi că datele din sistem nu ți-s corupte înainte de migrare, și dup-aia începem de acolo cu noul sistem de backup. Noi n-avem de unde ști dacă datele ți-s corupte sau nu, putem doar confirma că datele în sistemul migrat sunt identice cu alea din sistemul de unde au pornit.
- Inacceptabil! Vreau să-mi migrați și backup-urile!
- Foarte bine, dar explică-mi cum le vei folosi. Backup-urile tale sunt într-un IBM Tivoli Storage Manager on-prem, cu agenții software aferenți. În datacenterul nou nu mai există IBM TSM, ci EMC Networker cu agenții proprii, care nu poate folosi backupurile IBM.
- Atunci să cumpărați IBM și acolo!
- Cu plăcere. Ridică întâi un Change Request pentru proiect pentru asta și vezi dacă finanțele tale ți-l aprobă la costuri, și apoi și Architecture Board al angajatorului tău e de acord cu excepția la standardul de backup pe care l-au definit pentru viitor și care ne obligă și pe mine și pe tine să-l adoptăm.
- *crickets*

Altul.
- Vezi că noi avem niște policy-uri customizate pentru backup, pentru a le ține 5 ani, și trebuie să fie păstrate tot așa după migrare.
- Nu putem implementa asta, sistemul de backup nou e calificat să rețină datele maxim 35 de zile.
- CUM!? Ne expuneți la risc! Avem obligația legală să ținem datele 5 ani! O să mă plâng la Risk, Compliance și Security!
- O idee foarte bună, chiar și ei ar dori să poarte o discuție cu tine despre motivele pentru care ai decis singur să folosești anterior migrării un sistem de backup în scop de arhivare pentru legal compliance, când sistemul de backup nu a fost calificat să ofere vreo garanție pentru îndeplinirea acestui scop diferit. Ah și ar mai vrea să știe cum poate fi susținut SLA-ul aplicației din categoria "business critical" cu servere stand-alone și fără vreun load balancer sau cluster.
- (dacă o mutră ar putea exprima împărțirea la zero, aia a fost)

Altul.
- Cum adică backupul e un serviciu opțional, suplimentar, contra cost?
- Păi așa poți alege dacă vrei sau nu backup zilnic sau la 4 ore la toate sistemele sau doar la unele. Ce rost are backup automat zilnic la mediul de dezvoltare unde aveți proiecte active doar 2 săptămâni oe an și-n rest e neatins? Ține-l oprit acolo, mai economisești niște bani.
- Dar fără backup nu putem aplica disaster recovery plan!
- (internal facepalm) Care-s valorile RPO și RTO din documentația aplicației?
- Ăă, ce-s alea?
 
puterfixer said:
Rulez eu un script open source (nici să mor nu-mi amintesc cum îi zice) care face deduplicare și arhivă incrementală, apoi duce delta-ul într-un bucket S3 la BackBlaze.
Click to expand...
Seamănă mult cu restic
hulubei said:
Cand ai cantitatea aia de date din exemplul respectiv, imi cam imaginez ca nu ai mailurile personale pe care le duci in S3. In esenta la volumul acela de date as zice ca mai degraba el insusi este locul de stocare al backupurilor.
Click to expand...
Omul a zis că stochează linux ISOs pe NAS-ul respectiv. :smile: Nu cred că o fi chiar sfârșitul lumii dacă pierde ceva date.

AdrianB1 said:
Daca tot se discuta despre backups, o chestie care nu e mentionata prea des e verificarea lor.
Click to expand...
O altă chestie ce mi se pare că e ignorată/necunoscută la backup-urile în cloud (well, arhivare, nu backup, să nu-l irităm pe puterfixer :smile:) e costul restaurării. Să stochezi 1TB în Glacier costă cam $1/lună. Dacă vrei să restaurezi acei 1TB undeva afară din ecosistemul AWS te costă cam $100.
 
jarod said:
Omul a zis că stochează linux ISOs pe NAS-ul respectiv. :smile:
Click to expand...
Personal dacă ar trebui să redownloadez toate ISOurile Linux și să le redenumesc conform schemei personale ar fi de-a dreptul catastrofă și n-am nici 10% din cât are ăla stocare acolo :D
 
Neo said:
Din ce am studiat până acum Ansible mi se pare absolut godlike pentru automatizarea taskurilor de genul.
Click to expand...
As fi interesat sa aflu mai multe despre a 8-a minune a lumii. Stiu ce e Ansible, dar de acolo si pana la godlike mi se pare un leap of faith cam mare.
 
Totul ține de playbook-ul pe care ți-l configurezi singur. Există și modele, evident, dar ideea este că este cap-coadă configurabil și automatizabil (exista cuvântul ăsta?).
 
Sunt situatii cand nu poti face arhive standard pentru simplul motiv pentru ca nu ai date standard. Si ca sa fii sigur ca poti folosi datele respective, nu strica un backup. Cand mai ai si o chestie precum o SCADA, cam ai chef de backup si se poate sa vrei backups pe bune nu arhive pentru diverse activitati precum simulari. Evident, acestea se pot cataloga drept situatii mai rare si mai speciale. La fel ca cele in care nu ai un departament de IT alocat unei activitati pentru simplul motiv pentru ca ar trebui sa dublezi numarul de angajati si te descurci pe genunchi cu inginerii care ii ai ca doar matematica pe paine au facut si aia candva, in teorie.
 
jarod said:
arhivare, nu backup, să nu-l irităm pe puterfixer :smile:
Click to expand...
Nu-i nici o iritare, e doar precizie în limbaj fiindcă cuvintele au implicații, altfel e ca și când userii se referă la cutia calculatorului drept „modem” sau „CPU”. :)

Există o varietate de tier-uri de storage, și servicii suplimentare care le pregătesc pentru scopuri diferite. OneDrive sau Dropbox nu fac backup, ci fac sincronizare a stocării active, pentru ca să poți folosi direct fișierele tale de oriunde. Un backup pune datele tale într-un format închis, care păstrează mai multe versiuni din ultimele săptămâni dar datele le poți accesa doar prin restaurare (completă sau doar a unor anumite fișiere). O arhivă face și catalogare pentru căutare indirectă, pe ideea că datele directe le vei accesa extrem de rar spre deloc, și e mai importantă garantarea integrității lor timp de decenii (gen, cum te asiguri că un document cu semnătură electronică valabilă 2 ani mai poate fi verificat după 20 de ani că semnătura aia a fost validă).

Realitatea e că diferențele pot fi mai gri, limbajul imprecis nu ajută, și poate fi o lene generală pentru a face curățenie în date. Și eu am poze de acu' 10 ani în Google Photos și fișiere în Google Drive, abandonate sau puse acolo „la loc sigur”, dar asta nu le face nici backup și nici arhivă.

hulubei cred că nu prea ești familiar cu diferența dintre date structurate, nestructurate sau semistructurate. Toate pot fi arhivate, catalogate și folosite, indiferent dacă sunt tabele din baze de date cu schemă fixă (date structurate) sau dacă sunt fișiere amestecate (Word, mailuri, poze, raw files de la ceva echipamente, streaming de date de la senzori IoT - date nestructurate). Doar că nu există o unealtă universală pentru arhivarea tuturor categoriilor de date într-un mod care să răspundă excelent nevoilor specifice arhivării. OpenText poate face arhivare la fișiere amestecate, poate arhiva la fel de bine și extrase din baze de date, dar e cam sucky la arhivare la nivel de înregistrare din baza de date, accesibilă în arhivă direct, nu ca parte a unui fișier backup cu instrucțiuni SQL sau CSV.

Iar când datele sunt amestecate, devine și mai interesant. Gen, ai o aplicație medicală pentru informații pacienți la o secție de radiologie. Are tabele structurate cu datele pacienților, dar și radiografiile într-un object storage, și referințe încrucișate. Bucățile de date vor fi arhivate în mod diferit, și arhivarea trebuie să poată să le țină cumva legate dar să permită extragerea sau procesarea ca obiecte independente. Asta nu o poți face într-un backup, care poate e doar un fișier imagine a discului sau un container cu blocurile de stocare modificate de la backup-ul anterior. Îți trebuie un sistem de arhivare, integrat cu aplicația medicală, în care să poți trimite zilnic din aplicație radiografiile mai vechi de 5 ani dar aplicația să înțeleagă asta și, dacă vrei să accesezi radiografia cândva, să o poată obține automat din arhivă ca și când ar fi încă în stocarea activă. Sau după 20 de ani de când aplicația sursă nu mai există, să poți face un query în metadata-ul arhivei ca să afli istoricul tuturor radiografiilor unui pacient.

SCADA nu e un scenariu foarte îndepărtat de asta, la fel și ăăăă măsurătorile de senzori IoT de pe tractor pentru analiza solului de pe câmp și agricultură automatizată ținând cont de particularitățile fiecărui metru pătrat din câmp. Sunt tot date structurate și nestructurate cu mijloace specifice de stocare, acces, procesare, backup și arhivare.

Dar cât timp organizația nu are măcar o persoană în rolul de arhivator sau vreun policy pentru asta, e de înțeles de ce pare acceptabil să crezi că a pune la seif un backup la sistemul de stocare se poate numi „arhivare” :)
 
hulubei said:
Multumesc. Ultimul alineat rezuma viata care bate teoria :smile:
Click to expand...
Eu cred ca in multe meserii tehnice se aplica ce spui tu. De fapt tind sa cred ca sunt foarte multi oameni care se supraapreciaza tehnic si de fapt nu vad decat in cel mai bun caz la suprafata.
 
Basic stuffz fata de ce se foloseste pe aici, insa am si eu o problema... :-D
Folosesc pe acasa un amarat de NAS Qnap TS-228, cu 2 HDD-uri, un Seagate de 6TB si un Samsung de 2TB. In general stocare de filme si muzica pentru DLNA pe TV sau pe streamer-ul audio si cam atat.
Configurat frumos serverul de DLNA, cel venit la pachet cu serverul (nu Plex, nu Twonky), mers totul brici o perioada, apoi a inceput pur si simplu sa se deconecteze random, din cand in cand... NAS-ul altfel merge bine pe retea, insa partea de multimedia complet cazuta. Dat reset la soft, facut update la ultimul firmware, niciun rezultat. Pus Plex pana la urma, aceeasi problema, cand se deconecteaza, pica ambele, chiar daca Plex inca apare ca optiune de selectat in lista de device-uri de pe TV. Se rezolva cu restart de NAS, insa nu poate fi o solutie. Cautat peste tot pe forumurile Qnap, nu am gasit nimic real de ajutor.
Singurele solutii la care ma gandesc acum ar fi iau de la eMag un HDD extern de 8TB, sa copiez pe el datele si apoi sa re-initializez NAS-ul cu totul, inclusiv cu stergerea datelor, share-urilor, tot si apoi sa returnez HDD-ul (cam de porc) sau sa iau un alt NAS SH de pe OLX si sa fac o migrare de share-uri (tot Qnap sa fie, model compatibil). Orice alta idee este binevenita, in special daca nu implica parte financiara. :B
 
You must log in or register to reply here.
Back
Top