Distributed Scalable Backup

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • ruudboon
  • Registratie: September 2001
  • Laatst online: 10-07 07:10
Op verschillende lokaties (4) heb redelijk wat data staan (tussen 200GB en 1,5TB per lokatie)
Tussen deze punten heb ik over het internet een vpn liggen.
Via rsync backup elke nacht lokatie 1 naar 2, 2 naar 1, lokatie 3 naar 4 etc.
De data veranderd niet extreem veel, en rsync pakt alleen de gewijzigde data op.

Graag zou ik bovenstaande oplossing anders willen inrichten om het zo flexibeler te maken. Ik wil graag meerdere systemen kunnen toevoegen en de opslag kunnen uitbreiden. Verder wil ik het in eigen beheer houden en niet gebruik maken van externe partijen.

Ik heb hieronder een ideale situatie gemaakt. Nu zoek ik eigenlijk een stuk software (bij voorkeur opensource), of een combinatie van software met wat scripting die dat kan gaan doen.
  • Op elk systeem(voornamelijk FreeBSD) heb je een dir die meegenomen zal worden in de backup. Deze dir zal regelmatig gechecked worden op verandering. Deze dir zal na verloop van tijd (afhankelijk van de snelheid van de vpn verbinding) 100% gebackuped worden. Alleen veranderingen worden gebackuped. Geen incremental backup.
  • Op elk systeem stel je een stuk ruimte beschikbaar voor backups. Deze distributed ruimte vormt samen met andere systemen een grote backup pool.
  • Nieuwe systemen kan je ook in een later toevoegen aan de pool.
  • Beschikbare ruimte later uitbreiden is geen probleem
  • Je moet een soort van groepen kunnen maken. Als systeem 1 en 2 op lokatie 1 staan dan heeft het voorkeur dat de data van systeem 1 niet op systeem 2 staat, maar op systeem 3 & 4 op lokatie 2
  • Terug halen van een backup uit de pool zal een handmatig actie.
Uiteraard ben ik online ook veel wezen zoeken en kom veel tegen, van private p2p netwerken tot echte distributed file systemen. Ik wil graag weten wat jullie advies is om dit soort dingen te doen. Of moet ik gewoon lekker bij mijn rsync backup blijven.

Acties:
  • 0 Henk 'm!

  • Predator
  • Registratie: Januari 2001
  • Laatst online: 19:30

Predator

Suffers from split brain

Csync2 is gebaseerd op rsync maar is veel geavanceerder.
Het maakt ook deel uit van de FreeBSD ports collection.
Lees het eens. Ik heb er wel zelf nog geen ervaring mee.

Everybody lies | BFD rocks ! | PC-specs


Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Tja, simplistisch gevraagd : Wat is het doel hiervan? En wat mag het kosten?

Wil je enkel uitval van 1 systeem tegelijk kunnen opvangen, dan red je het met groepen en beschikbare ruimte die (grofweg geschat) 2x de te backuppen ruimte is.
2x zoveel ruimte heb je grofweg nodig in een 1 op n distributed systeem op bestandsbasis, 100Mb te backuppen over 100 files valt namelijk perfect gelijkmatig te verdelen onder 100 nodes, maar 1 bestand van 100Mb vult 1 complete node en voor de rest niets.

Dus je zal al snel moeten overgaan van file-based backuppen naar block-based backuppen met een vaste blocksize zodat je verspreiding gelijkmatig zal gaan.

En als je enkel maar de te backuppen ruimte als vrije ruimte reserveert heb je enkel maar 1x een backup verspreid staan, dus als er 2 systemen / groepen uitvallen ( / niet in sync lopen ) dan kan je al compleet niet meer restoren. Enkel je data 1x verspreiden over 100 nodes levert 100 SPOF's op voor het restoren...
Je zal dus extra ruimte moeten reserveren, en ergens nog een algemene redundante ruimte hebben staan om iets van een SLA af te kunnen geven.

Daarnaast moet je het ook nog eens encoderen om te voorkomen dat als iemand er een verkeerd bestandje opzet dat dit gelijk publiekelijk is.

Volgens mij is het veel bouwwerk en kost het onverwacht veel ruimte en is het ook nog eens als je niet oppast redelijk cpu-intensief ( gewijzigde delen opsporen deze in blocks opdelen en encoderen voor verzenden, daarna checksums controleren etc ).
Als je het goed kan bouwen en je de ruimte hebt ( en je het aantal klanten hebt ) dan valt er wel iets van te maken, maar anders gok ik dat je enkel meer POFS genereert.

Sowieso verkijk je niet op de complexe routingsalgoritmen die je moet gaan bedenken je wilt niet dat een 100mb verbinding altijd achterloopt met backuppen omdat het vanwege groepen oid een gedeelte op een 256 kb verbinding kwijt moet.

Zet je het grootschalig genoeg op, dan heb je een kans van slagen. Wil je het kleinschalig doen dan zou ik gewoon zeggen zet wat meer hdd's bij meerdere klanten neer en backup die 1,5 Tb gewoon naar 5 locaties tegelijk, simpelweg 100% redundant... Kosten zijn dan laag ( deze hdd's hoeven namelijk niet op locatie in de backup mee ) en restoren is ook gewoon simpel, ligt klant 1,2,3 en 4 plat dan is het enkel nog maar iemand in de auto zetten die de hdd's bij klant 5 ophaalt ipv met distributed waarbij je dan incomplete restores krijgt...

In wezen is het dan hoe grootschaliger hoe goedkoper de hardware kan zijn, door je 100% redundantie kan je op een gegeven moment zelfs overstappen naar consumenten troep ( a 100 euro de TB ) omdat je dan gewoon iets krijgt als : de kans dat 20 consumenten hdd's tegelijk uitvallen is extreem klein en 1 hdd die uitvalt is niet relevant, je hebt nog 19 redundante kopieeen....