Stoppen met backuppen....? (!!)

[Shaq_]

Even eens de knuppel in het hoenderhok gooien: ik werk in een omgeving met ongeveer 40 TB primaire storage (Netapp), waarvan nu ongeveer 20 TB in gebruik. Backuppen wordt een steeds hachelijker zaak, zeker nu voor ons petabytes steeds meer over de tong gaan...

Mij is gevraagd eens om met een geheel frisse blik mijn licht te laten schijnen over storage in het algemeen, backupregimes en hierarchische/tiered storagemodellen.

Even helemaal blank geredeneerd: waarom backuppen we eigenlijk? Roll-back/snapshots van data naar elk gewenst tijdstip is mogelijk met 'nieuwe' filesystemen als ZFS. Die draaien we dan op RAID5/6 configuratie met hotspares. De uitvalratio van schijven is behapbaar tot een jaar of 5, daarna moeten we wellicht naar iets anders omzien (of als het bevalt

Ow ja: off-site storage/replicatie (!) wordt in voorzien middels een 10Gbps verbinding naar een andere locatie vlak over de grens in Duitsland en eentje bij Londen.

Kortom: wie heeft goede argumenten om dit wel of juist niet verder te onderzoeken? Welke risico's loop je met een configuratie als boven beschreven? Hoe betrouwbaar is RAID5/6; laat maar komen die horror-stories van reddeloos verloren arrays :-)

[Duinkonijn]

raid is niet een echte oplossing voor backuppen..

wat dacht je van een replicatie die verkeerd gaat doordat er net een bitje omvalt die niet wordt opgemerkt door een foutive controller en vervolgens wordt doorgerepliceerd

of een virus die zich verspreid over je servers en vervolgens op tijd stip x van alle servers het filesystem corrupt maakt

[ Voor 21% gewijzigd door Duinkonijn op 17-01-2007 14:16 ]

[BalusC]

Sja, pas op het moment dat de horror toeslaat zul je blij zijn met backups Tot het zover is moet je het backupleed maar voor lief nemen en eerder blij zijn dat het boeltje zo stabiel is dat je tot dusver nog nooit aanspraak hebt hoeven maken op backups

[Shaq_]

Duinkonijn schreef op woensdag 17 januari 2007 @ 14:15:
raid is niet een echte oplossing voor backuppen..

wat dacht je van een replicatie die verkeerd gaat doordat er net een bitje omvalt die niet wordt opgemerkt door een foutive controller en vervolgens wordt doorgerepliceerd

of een virus die zich verspreid over je servers en vervolgens op tijd stip x van alle servers het filesystem corrupt maakt

RAID is idd geen backup methode/techniek. Ik zie ze eigenlijk meer als aanvullend: de backup is er voor het geval de RAID gefaald heeft. Of inderdaad een virus heeft huisgehouden. Ik vraag me gewoon af in hoeverre RAID daadwerkelijk faalt (in de zin van corruptie) en of je nog wel bang moet zijn voor een dergelijk virus: virus langs geweest en alles gewist om 13:00? Prima, draaien we het filesysteem terug naar 12:59 en gaan we gewoon weer vrolijk verder... Defecte harde schijven vervang je gewoon tijdig, we houden netjes twee RAID controllers op de plank, net als andere zaken die stuk kunnen gaan.

Nogmaals, dit is vooral bedoeld als een teaser-discussie. Even zoveel als mogelijk ingesleten denkbeelden overboord zetten.

Heeft er hier trouwens iemand ervaring met ZFS (zie http://www.opensolaris.org/os/community/zfs/). Heb het al eens (kort) proefgedraaid op mijn linux-bak, net als NILFS (http://www.nilfs.org/en/). Wonderbaarlijk, die twee filesystemen.

Vraagje: wie weet of Google zijn productie'databases' backupt? (ik weet het niet, maar 'men' schat dat ze petabytes aan data hebben)

[ Voor 5% gewijzigd door Shaq_ op 17-01-2007 14:40 ]

[masser120]

offtopic: 40TB!! Wow...

ontopic:
Wat dachten jullie van tapes? Stabiel en lang houdbaar, bovendien ook herschrijfbaar.

[Ozzie]

De TS vraagt niet om een manier om het beste die 20TB te backuppen hoor..

[Shaq_]

masser120 schreef op woensdag 17 januari 2007 @ 14:33:
offtopic: 40TB!! Wow...

ontopic:
Wat dachten jullie van tapes? Stabiel en lang houdbaar, bovendien ook herschrijfbaar.

ALS je backupt zijn tapes inderdaad een goede optie. Die robots staan hier dus ook, maar als je moet gaan nadenken over het backupen van 1 petabyte... Maar het gaat nu juist om de vraag OF je nog wel moet backuppen.

[Dido]

RAID zorgt inderdaad alleen voor bescherming tegen uitvallende/kapotte schijven.

Je bent echter wel je data kwijt als ie om een andere reden corrupt wordt. En dat risico is altijd aanwezig.
Ik zou dus zeker niet stoppen met backups, zoals eerder gezegd: je waardeert de moeite die je ervoor doet pas als je het nodig hebt.
Jij wilt echt niet vandaag adviseren om niet te backuppen en morgen zien dat er data onbruikbaar is geworden

[BalusC]

Shaq_ schreef op woensdag 17 januari 2007 @ 14:30:
Vraagje: wie denkt dat Google zijn productie'databases' backupt?

Is dit een strikvraag En doel je op de Google-Search? Mijn logica zou dan zeggen dat Google al een backup heeft in vorm van het huidige Internet De search/bot/ranking-alogritmen zouden ze uiteraard allang gebackupt hebben.

[Shaq_]

BalusC schreef op woensdag 17 januari 2007 @ 14:40:
[...]

Is dit een strikvraag En doel je op de Google-Search? Mijn logica zou dan zeggen dat Google al een backup heeft in vorm van het huidige Internet De search/bot/ranking-alogritmen zouden ze uiteraard allang gebackupt hebben.

Nee, zo was die niet bedoeld (heb hem net voor jou post ook aangepast :-).

[teigetjuh]

Ik zit hier in een omgeving met nog meer TB's aan data dan de TS, maar hier wordt toch nog alles gebackuped en moeten we door gebruikers-fouten toch ook nog regelmatig wat terughalen. Replicatie en rollbacks op een FS zijn leuk, maar nemen ook (kostbare) ruimte in en worden toch ook overschreven. En het rollback-scenario zoals geschetst met om 13:00 een virus we hallen alles terug van 12:59.... Sorry, het virus heeft ook die data verwijdert.... Dan is een tape(-robot) met je backups toch een perfecte oplossing....

[Pinooo]

Ik denk dat Google alles geclusterd heeft... dus gewoon 2 of meer identieke omgevingen die het van elkaar overnemen als er iets fout gaat.

[Verwijderd]

Een back up maak je voor het geval er iets mis gaat met je productieomgeving. Nu heb jij je data al op verschillende locaties staan die geografisch op voldoende afstand staan. Bij Netapp ga je dus Snapshots bewaren. Die snapshots worden van het ene systeem naar het andere systeem getransporteerd via synchrone of a-synchrone spiegeling. Wanneer je van Netapp snapmirror gebruikt heb je wel een probleem wanneer iemand een snapshot weggooid. Dit snapshot zal dan op beide locatie weggeooid worden. Beter is het om gebruik te maken van Snapvault. Dit is uitermate geschikt voor back up.

Mijn idee zou zo op het eerste gezicht zijn een combinatie van. Dus gebruik blijven maken van je replicatie en eens in de maand of week een dump van je data naar tape. Dit geeft meer ruimte op je filer en je bent verzekerd dat wanneer er ooit een virus opduikt op OnTap je niet alles kwijt bent.

[beascob]

als leek hoor ik een frisse blik te hebben...

in mijn machine zet google al een eerste info neer. (cookie)
Dat is al een vorm van opslag...
Misschien kan bijvoorbeeld een bank dat ook doen.
Zeer gedecentraliseerd bij zijn klanten als een soort infraweb.
Dus XS4Bank als ruil voor gratis bankieren.

Vroeger had ik een spaarbankboekje, in future wordt ik contentsaver voor mijn relaties.

Dit lijkt heel fragmenterend, maar is misschien nog wel het meest robuust.

[Shaq_]

Pinooo schreef op woensdag 17 januari 2007 @ 14:51:
Ik denk dat Google alles geclusterd heeft... dus gewoon 2 of meer identieke omgevingen die het van elkaar overnemen als er iets fout gaat.

Dat zou strikt genomen geen backup zijn, of toch...?

[Duinkonijn]

beascob schreef op woensdag 17 januari 2007 @ 15:09:
als leek hoor ik een frisse blik te hebben...

in mijn machine zet google al een eerste info neer. (cookie)
Dat is al een vorm van opslag...
Misschien kan bijvoorbeeld een bank dat ook doen.
Zeer gedecentraliseerd bij zijn klanten als een soort infraweb.
Dus XS4Bank als ruil voor gratis bankieren.

Vroeger had ik een spaarbankboekje, in future wordt ik contentsaver voor mijn relaties.

Dit lijkt heel fragmenterend, maar is misschien nog wel het meest robuust.

dat is nog al een beetje risico... als een hacker het deeltje kan manupuleren heeft hij in eens veel geld


denk toch dat je iets in de richting moet hebben voor het hebben van je data op een offline medium, die kan ingeval van virussen niet gemanupuleerd worden

[ Voor 10% gewijzigd door Duinkonijn op 17-01-2007 15:39 ]

[Shaq_]

teigetjuh schreef op woensdag 17 januari 2007 @ 14:50:
(...) En het rollback-scenario zoals geschetst met om 13:00 een virus we hallen alles terug van 12:59.... Sorry, het virus heeft ook die data verwijdert.... Dan is een tape(-robot) met je backups toch een perfecte oplossing....

Dat is inderdaad hetgeen me nog het meest dwarszit, dat je rollback-mogelijkheid ook om zeep geholpen kan worden.

Ik ga nog eens kijken hoe organisaties en projecten als het CERN/LOFAR dit doen.

[Duinkonijn]

wordt die volledige 40 tb continu gemuteerd?

[DataGhost]

Duinkonijn schreef op woensdag 17 januari 2007 @ 15:35:
[...]

dat is nog al een beetje risico... als een hacker het deeltje kan manupuleren heeft hij in eens veel geld


denk toch dat je iets in de richting moet hebben voor het hebben van je data op een offline medium, die kan ingeval van virussen niet gemanupuleerd worden

Ook totaal niet betrouwbaar. De verbindingen van consumenten zijn lang niet stabiel genoeg voor productieomgevingen (meerdere variabelen) en de cookies zijn makkelijk te verwijderen/corrumperen. Denk inderdaad ook aan kwaadaardige personen, die desnoods zo diep in het systeem weten te komen dat ze kwaadaardige code kunnen laten uitvoeren bij een restore en je hebt heel wat uit te leggen aan je baas.

RFC 2965
* at least 4096 bytes per cookie (as measured by the characters
that comprise the cookie non-terminal in the syntax description
of the Set-Cookie2 header, and as received in the Set-Cookie2
header)

* at least 20 cookies per unique host or domain name

Dan kom ik uit op 80 kB opslagruimte. Als je 20 TB moet opslaan heb je ongeveer 270 miljoen PC's nodig, dan heb je _GEEN_ redundantie EN moeten al die 270 miljoen PC's verbinding maken met jouw website op het moment dat je je backup terug wilt zetten. Dit is, voor zover al te verantwoorden, nagenoeg onhaalbaar.

[ Voor 30% gewijzigd door DataGhost op 17-01-2007 15:48 ]

[Shaq_]

Duinkonijn schreef op woensdag 17 januari 2007 @ 15:41:
wordt die volledige 40 tb continu gemuteerd?

Nee, zeker niet. Sterker nog: na het schrijven is de data relatief statisch.

[TERW_DAN]

Ik denk dat je zelf zwaar baalt op het moment dat het fout gaat met je productie machine en je het geluk hebt dat je nog een tape hebt liggen.

Ik denk dat het wel belangrijk is af te vragen hoe lang je data moet bewaren.ik kan me voorstellen dat als je bij versie 9 bent je versie 2 niet meer nodig hebt omdat die sowieso outdated is. De hoeveelheid data groeit natuurlijk wel, maar dat moet best haalbaar zijn en waarschijnlijk is het prima te doen de datahoeveelheid terug te dringen (dus dat je niet direct op 1PB zit ofzo).

[Keiichi]

Opzich lijkt het me dat een NAS goed als backup kunt gebruiken. (meeste hoor ik gelijk roepen bij het vallen van RAID dat het niet voor backup geschikt is)

Het is hoe je het gebruikt. Ik zie het zo voor me. Ik heb een x aantal servers. Op een locatie die zowiezo verwijderd van de servers is plaats je de NAS (een tape zou je meenemen, een NAS niet bepaald). Die deel je op in 2 delen. Voor de eenvoud is deel 1 voor de recente backup en deel 2 voor de minder recente. Dit zodat mocht er onverhoopt iets op de recente backup foutlopen dat je altijd nog een backup voorhanden weer hebt.
mijn backups laat ik bv via rsync lopen en hierbij kan ik me niet zo snel iets voorstellen hoe een virus alles om zeep zou kunnen helpen (En zelfs dan zou je deel 2 van je backup als het ware nog hebben)

Wat RAID betreft. RAID moet je onderhouden. Dwz als je een backup gemaakt heb soort van inspectie uitvoeren of alles nog in orde is.

En als je het nog beter wilt hebben, nog een NAS wegzetten die als secundairy backup dient. Ik neem aan als je op tapes backupt dat je niet enkel 1 tape hebt.

[Duinkonijn]

waar je ook nog mee zit is in hoeverre je met je file system terug kan

als een persoon een document+aanvullende zooi in april 2006 maakt. wist het in juni.

en komt vervolgens in augustug 2011 bij een belasting inspectie er achter dat hij het bestand niet meer heeft... kan je dan nog terug met het file system

_{(en ja zulke taktische konijnen heb ik hier werken)}

Keiichi schreef op woensdag 17 januari 2007 @ 15:50:

En als je het nog beter wilt hebben, nog een NAS wegzetten die als secundairy backup dient. Ik neem aan als je op tapes backupt dat je niet enkel 1 tape hebt.

een nas is live, en in mijn mening. alles wat live is kan gemold worden door hackers / virussen

waar ik trouwens net aandacht. je moet ook niet dan maar in 1 land backuppen..

als je kantoor in nederland in de fik staat, dan kan je niet meer terug naar een eerder tijd stip anders

[ Voor 42% gewijzigd door Duinkonijn op 17-01-2007 15:56 ]

[axis]

Snap het probleem niet zo, bijna ieder grote onderneming met veel data heeft tape libraries draaien..

Heb er nog niet veel ervaring mee, pas net eerste Dell PowerVault 124T besteld (6.4TB/12.8TB), maar gooi een doos neer als een PowerVault ML60XX, waarmee je een betrouwbare, bewezen oplossing neerzet, die max 87.2TB backupt, a 2.9TB/h.

Kun je meerdere backups naast elkaar hebben staan, en als er wat kapot gaat, restore je gewoon. Je kunt eventueel nog tape-cartridges eruit halen en in een kluis leggen, en andersom..

[axis]

Keiichi schreef op woensdag 17 januari 2007 @ 15:50:
Opzich lijkt het me dat een NAS goed als backup kunt gebruiken. (meeste hoor ik gelijk roepen bij het vallen van RAID dat het niet voor backup geschikt is)

Het is hoe je het gebruikt. Ik zie het zo voor me. Ik heb een x aantal servers. Op een locatie die zowiezo verwijderd van de servers is plaats je de NAS (een tape zou je meenemen, een NAS niet bepaald). Die deel je op in 2 delen. Voor de eenvoud is deel 1 voor de recente backup en deel 2 voor de minder recente. Dit zodat mocht er onverhoopt iets op de recente backup foutlopen dat je altijd nog een backup voorhanden weer hebt.
mijn backups laat ik bv via rsync lopen en hierbij kan ik me niet zo snel iets voorstellen hoe een virus alles om zeep zou kunnen helpen (En zelfs dan zou je deel 2 van je backup als het ware nog hebben)

Wat RAID betreft. RAID moet je onderhouden. Dwz als je een backup gemaakt heb soort van inspectie uitvoeren of alles nog in orde is.

En als je het nog beter wilt hebben, nog een NAS wegzetten die als secundairy backup dient. Ik neem aan als je op tapes backupt dat je niet enkel 1 tape hebt.

Wij gebruikten ook NAS backups en backups-to-tape, maar op een gegeven moment is het goedkoper om een tape library te kopen. Voor 6000-7000 piek heb je een library die 6.4TB/12.8TB kan backuppen.. Ook al heb je bijvoorbeeld maar 1TB te backuppen, kun je dus wel minstens 6/12 full backups opslaan als je dat zou willen. Zonder uit je luie stoel te komen.

Een betrouwbare en goede (snel, manageble, etc) direct-attached disk server met zoveel storage kun je ook kopen, maar dan ben je al snel veeeel meer geld kwijt. En het neemt veel meer ruimte in, en verbruikt veel meer stroom. Niet onbelangrijk in een datacenter.

[Verwijderd]

Niemand reageert op het ZFS-argument van de TS. RAID is geen backup; daar is de TS wel achter. Maar ZFS biedt ook de 'historie' die een backup biedt; en ook integriteitcontroles en ingebouwde RAID5/RAID6 (RAID-Z genaamd). In die zin kan ZFS dus de taak van backups overnemen, maar er zijn wel verschillen:

- zitten er bugs in de ZFS implementatie, dan kun je alsnog dataverlies krijgen
- geen backup betekent ook geen redundantie op een ander fysieke locatie, dus in geval van brand, ernstige stroompieken en een flinke voeding doorbranding o.i.d. kun je alsnog dataverlies krijgen
- je bent gebonden aan ZFS-funtionaliteit (gelukkig biedt ZFS veel coole features die andere FSen niet hebben)
- je bent gebonden aan operating systems die ZFS ondersteunen (momenteel alleen Solaris en FreeBSD voor zover ik weet)
- ZFS is niet bootable (ook niet op Solaris)

Ben je bekend met deze risico's en hebben ze geen prioriteit voor je, dan staat een overgang naar ZFS je niets in de weg. Zorg wel dat je alles zorgvuldig voorbereid en test en als het kan een tijdje lang ook nog backupt, voor de zekerheid. Test vooral ook met je 'uiteindelijke array' met rebuilden. Dingen zoals hot spares en rebuilds enzo moeten allemaal automatisch werken, anders kun je alsnog veel risico lopen.

[Shaq_]

axis schreef op woensdag 17 januari 2007 @ 15:55:
Snap het probleem niet zo, bijna ieder grote onderneming met veel data heeft tape libraries draaien..

Heb er nog niet veel ervaring mee, pas net eerste Dell PowerVault 124T besteld (6.4TB/12.8TB), maar gooi een doos neer als een PowerVault ML60XX, waarmee je een betrouwbare, bewezen oplossing neerzet, die max 87.2TB backupt, a 2.9TB/h.

Kun je meerdere backups naast elkaar hebben staan, en als er wat kapot gaat, restore je gewoon. Je kunt eventueel nog tape-cartridges eruit halen en in een kluis leggen, en andersom..

Nou, het probleem is dat als je naar petabytes gaat je met de huidige werkwijze door de neus gaat betalen. En nee, we hoeven niet voor een dubbeltje op de eerste rang te zitten (mag wel, uiteraard), maar het kan nooit kwaad om het bed eens goed op te schudden.

Wat bij CERN aan het rondneuzen geweest, kwam CASTOR tegen (toen ik het zag herinnerde ik me dat ik het al eens eerder heb gezien). Affijn: kijk en huiver op http://castor.web.cern.ch/castor/global_statistics.png Ze zitten toch alweer op de 7 petabytes daaro met hun botsinkjes. Zouden ze hier nu echt een backupje van draaien? En volgens mij is de schade wel enorm groot als daar een keer een virus binnenkomt (betalen wij dan weer als belastingbetaler, maar dat terzijde)...

[Shaq_]

Verwijderd schreef op woensdag 17 januari 2007 @ 16:06:
Niemand reageert op het ZFS-argument van de TS.

Gelukkig ben jij er nog :-) Misschien ook net een beetje te nieuw, kweenie.

Je somt inderdaad netjes de vraagstukken rond ZFS op. Enkele zijn geen probleem (bv. niet kunnen booten van ZFS, over het OS valt te praten etc. etc.). De grootste makke m.i. is dat het (nog) geen proven techhnology is, dus eigenlijk je eerste argument.

Misschien moest ik de mensen van CERN maar gewoon eens bellen of een conferentie bijwonen.

Toch ben ik benieuwd wat anderen van dat CERN verhaal vinden. (en ja, daar zitten tapes in, maar die zijn m.i. met name voor goedkope 2nd/3rd line storage, niet om een backupje op te draaien).

[Verwijderd]

Back up is net als een verzekering. Hoe belangrijker de data hoe meer het geld het kost. Tape is een onbetrouwbaar medium maar wel lekker goedkoop. Disk is betrouwbaarder maar duurder. (hoewel de prijs steeds dichterbij komt). Ik ga nog steeds in onze eigen omgeving voor beide. Disk voor snelle restores en (off site) tape voor disaster recovery.

[lpdheinen]

Om even niet-technisch maar meer beleidsmatig te reageren: wat ik vaak zie is dat men gaat backuppen en dan ook alles backupt wat men aan data heeft. Dus hele disk images etc. Terwijl in een hoop gevallen je een selectie van data zou kunnen backuppen dat misschien maar 10% van het hele pakket is. Bijv. in het geval van een klantendatabase van een bedrijf is het niet noodzakelijk om de hele database te backuppen (in super-onhandig formaat), maar je zou exportfiles van partnerdata + transactiedata kunnen backuppen waarmee je in geval van problemen de oude situatie weer kunt opbouwen.

De vraag is wanneer je meer moeite moet doen - wil je alles na crash weer met een paar drukken op de knop terug hebben staan waar het stond, of ben je in zo'n geval bereid om er wat meer tijd in te steken. Ik denk dat het laatste in de meeste gevallen het beste is. Beter meer moeite doen in een geval dat 1% kans heeft dat het in een jaar gebeurt, dan continu meer moeite doen (cq geld uitgeven).

Kortom: mijn oplossing zou zijn: select backuppen.

[Q]

Goede aanvulling, zo drie jaar na de laatste post.

[Skinkie]

ZFS heeft weldegelijk een aantal issues. Je kunt niet opschalen binnen het bestandssysteem en is daarmee dus niet heilig. Wil je opschalen gaat dat je gewoon een nieuwe tree opleveren. Ja je kunt dan heen en weer gaan kopieren 'fijn'.

Er zijn significante performance problemen met send/receive. En met een groot aantal NFS mounts, daar kan de UvA je van alles over vertellen. Momenteel is ZFS op dat gebied O(N^2), kut dus hoe groter je wordt.

Daarnaast heb je nog de problemen waar je feitelijk een single 'head' hebt op je data. Er gaat dus niet meer uit schijvenkomen als je netwerklink (of je pci bus) voor zit met data. En dan mag je gaan bedenken hoe je ZFS gaat opschalen. Datzelfde probleem heb je met vrijwel al die systemen... of het nu een Dell of NetApp is.

[pinockio]

Q schreef op dinsdag 29 juni 2010 @ 19:28:
Goede aanvulling, zo drie jaar na de laatste post.

Ja, zou er in die 3 jaar nog iets veranderd zijn? Het lijkt me dat de prijs van disk storage sneller afgenomen is dan taperobots.

[ Voor 38% gewijzigd door pinockio op 29-06-2010 19:36 ]

[Q]

Geen idee, ik vind het eigenlijk nog wel een leuk onderwerp. Ik zou liever niet meer aan de tapes gaan en op een andere locatie liever gewoon ook een grote disk storage neersmijten. Maar als je een historie wilt, dan moet je al snel met meer opslag aan komen zetten dan je oorspronkelijke storage. Bovendien moet dat net zo hard mee schalen. Mogelijk dat tapes toch nog steeds qua kosten beter uit komen?