Bekijk Volledige Versie : Offsite replicatie backups
Beste Collega's,
Ik zit hier al enkele maanden over na te denken en ter zelfder tijd al even lang te wachten op R1Soft voor ze met een betere integratie komen met hun tool (ze beloven het wel allessinds, maar wanneer ? ) ..
Wij maken onze backups dmv R1Soft / Idera dit werkt perfect en zou niets anders meer willen maar we willen onze backups ook graag offsite gaan bewaren..
Idera biedt nu de mogelijkheid om de disksafe te laten repliceren naar een offsite lokatie, de documentatie daarrond is heel pover en zit daarbij met wat vragen, misschien dat iemand het hier al eens geprobeerd heeft ?
-> Hoe werkt dit exact, repliceert hij telkens de disk safe 1:1 of houd hij op de offsite kant dan ook verschillende versies bij ?
-> Als dit 1:1 gerepliceert wordt (wat ik vrees) wat gebeurt er dan in het geval dat wanneer er tijdens een replicatie een interrupte is in de connectie? Op dat moment is de disksafe corrupt hoe gaat R1Soft daarmee om gebeurt er op dat moment een rollback..
-> Je kan na het repliceren ook een script uitvoeren, je zou hier dan eerst lokaal een replicatie kunnen doen en daarna alles via rsync overduwen. Nadeel hier is dat het telkens wel serieus wat data is en dat je ook hier weer met het probleem zit wat als de connectie weg valt...
Je wilt niet net aan het repliceren zijn dat er brand uitbreekt , je rack affikt en je corrupte backups offsite hebt staan...
Hoe zouden jullie dit aanpakken? Opzich een simpele vraag en simpel te realiseren maar wil het wel deftig doen, wil iets hebben waar we op kunnen vertrouwen..
Wij doen een groot deel via ZFS copy-on-write snapshots, en sturen die met zfs send & receive naar de back-upservers. Deze snapshots zijn incrementeel (dwz, alleen de changes sinds het vorige snapshot). We draaien deze om het uur, dus de back-up loopt maximaal 1 uur achter op de live omgeving, met een retentie van 30 dagen (met een zekere granulariteit).
Wij gebruiken arrays met 24 - 48 disks, maar je kan het ook prima met 2 disks (hdd/ssd) doen. Voordeel is dat je meteen een deel van je RAM als cache kunt inzetten. Of bijvoorbeeld 1 grote array en daar van diverse servers de back-ups naar sturen.
Wij doen een groot deel via ZFS copy-on-write snapshots, en sturen die met zfs send & receive naar de back-upservers. Deze snapshots zijn incrementeel (dwz, alleen de changes sinds het vorige snapshot). We draaien deze om het uur, dus de back-up loopt maximaal 1 uur achter op de live omgeving, met een retentie van 30 dagen (met een zekere granulariteit).
Wij gebruiken arrays met 24 - 48 disks, maar je kan het ook prima met 2 disks (hdd/ssd) doen. Voordeel is dat je meteen een deel van je RAM als cache kunt inzetten. Of bijvoorbeeld 1 grote array en daar van diverse servers de back-ups naar sturen.
Wij hebben een onsite en een offsite backup, onsite 6x per dag, offsite 1x per dag.
Ik heb na zitten denken over een ZFS replicatie van onze storage, uiteindelijk durfde ik het niet aan omdat ik dan volledig moet vertrouwen op ZFS (eerlijk gezegd weet ik niet of dat verstandig is).
Wat wij doen is
6x per dag een veeam replica draaien naar de onsite storage. (instant beschikbaar),
retentie hierop is 7x, dus eigenlijk kunnen we hier 1 dag terug
1x per dag een offsite backup via de normale backup manier,
retentie hierop is 31 dagen, dus maximaal 1 maand terug
Ik ben benieuwd naar je setup, heb je ooit moeten fail-overen, ging dat goed, hoe doe je de tests? Het is namelijk een behoorlijke kosten besparing (veeam is niet extreem duur, maar wel aan de prijs)
24x7hosting
16/01/15, 23:16
Dit soort offsite backups kan je inderdaad uitstekend doen met ZFS snapshots. Zfs compressed en encrypt ook het versturen en pakt de bitjes en bytejes die aangepast zijn en hoeft niet uit te zoeken welke bestanden aangepast zijn. Je geeft het commando en hij gaat direct het verschil versturen.
Sent from my GT-I9505 using webhostingtalk mobile app
We doen dus elk uur één snapshot naar een tweede fysiek gescheiden fileserver. Voor klanten met SLA gaat die 1x per dag nog naar een ander datacentrum. We doen best regelmatig een fail-over. Bijvoorbeeld bij updates aan de fileservers. Je kan dat mooi afscripten.
In principe komt het er op neer: volume read-only maken, snapshot maken, snapshot syncen, read-write op de back-up maken, remounten, klaar. Nu lijkt dat vrij complex, maar eigenlijk is dat erg makkelijk. Voor hele grote fileservers zijn files ongeveer 1 minuut read-only, en heb je een hick-up van 1 seconde tijdens het remounten. Bij de kleinere fileservers is de read-only tijd zelfs nog minder. We doen die read-only trouwens om 100% consistentie op de data te garanderen. Je hebt overigens ook plugins die dergelijke failovers kunnen doen (RSF-1).
24x7hosting
16/01/15, 23:18
Dit soort offsite backups kan je inderdaad uitstekend doen met ZFS snapshots. Zfs compressed en encrypt ook het versturen en pakt de bitjes en bytejes die aangepast zijn en hoeft niet uit te zoeken welke bestanden aangepast zijn. Je geeft het commando en hij gaat direct het verschil versturen. Om die reden is het ook makkelijk om het uurlijks te doen, zelfs over trage links.
Sent from my GT-I9505 using webhostingtalk mobile app
Sent from my GT-I9505 using webhostingtalk mobile app
24x7hosting
16/01/15, 23:20
Ik moet nog wennen aan de vernieuwde app ;-)
Sent from my GT-I9505 using webhostingtalk mobile app
24x7hosting : backuppen jullie ook met Idera of met andere software..
Ik zou de trigger voor het startten van de offsite copy / snapshot willen startten vanuit de backup software zelf en niet met zelf gekozen intervalt want dan heb je mogelijk het probleem dat een disk safe in use is en je maar de helft overzet waardoor je BMR image corrupt is aan de offsite kant...
24x7hosting
17/01/15, 08:57
bibawa : ZFS is een copy-on-write filesysteem. Als een schrijfactie nog niet klaar is tijdens de snapshot dan wordt deze simpelweg genegeerd in plaats van half meegenomen waardoor er geen kans is op corruptie. Hierdoor zijn de snapshots betrouwbaar. Met ZFS heb je ook eenvoudig een lange retentie omdat het niet veel diskspace in neemt. Stel dat er toch het laatste uur iets helemaal fout ging, dan kan je nog een uur eerder herstellen.
Sent from my GT-I9505 using webhostingtalk mobile app
Erg makkelijk zelfs ;) met zfs rollback **snapshot** (of zfs clone als je de huidige /nieuwere sets ook wil bewaren).
Ofwel ben ik niet helemaal mee ofwel denk ik er te hard over na :-)
Dat het wegvallen van de verbinding al gecoverd is is natuurlijk al mooi maar dan zit ik nog met het probleem dat een disksafe tijdens de snapshot 'in use' kan zijn..
Backup naar disk safe 1 en tijdens backup wordt snapshot genomen => disk safe is zo corrupt het maar kan zijn op snapshot kant.. Zoals je zegt heb je dan meerdere versies aan de offsite kant staan maar als je pech hebt zijn ze ook daar allemaal hierdoor corrupt..
Idera adviseert dan ook om de disk safe offline te plaatsen voor een copy actie te doen om er zeker van te zijn dat ze afgesloten is, eventueel is zoiets dan wel te scripten natuurlijk..
Ik denk er teveel over na denk ik :-)
Heeft iemand zoiets draaien met Idera? :-)
24x7hosting
17/01/15, 09:54
ZFS is het filesysteem van je fileserver, niet van je backup server. Als je een backup weg schrijft naar een zfs systeem en dan een snapshot maakt werkt het inderdaad niet. Het gaat er juist om dat ZFS de backup/snapshot maakt en weg schrijft naar een ander systeem.
Sent from my GT-I9505 using webhostingtalk mobile app
ZFS is het filesysteem van je fileserver, niet van je backup server. Als je een backup weg schrijft naar een zfs systeem en dan een snapshot maakt werkt het inderdaad niet. Het gaat er juist om dat ZFS de backup/snapshot maakt en weg schrijft naar een ander systeem.
Sent from my GT-I9505 using webhostingtalk mobile app
Hoezo werkt dat niet? Dat werkt prima. Ik heb zowel de primaire als de back-upservers met ZFS draaien. Ik maak een snapshot op de primaire en stuur die met zfs send/receive naar de back-up. Zo heb ik op beide servers retentie. Ik heb ook wel wat servers die geen ZFS draaien en gewoon alle data rsyncen naar een ZFS server, die daar snapshots van maakt. Werkt prima.
24x7hosting
17/01/15, 11:24
Hoezo werkt dat niet? Dat werkt prima. Ik heb zowel de primaire als de back-upservers met ZFS draaien. Ik maak een snapshot op de primaire en stuur die met zfs send/receive naar de back-up. Zo heb ik op beide servers retentie. Ik heb ook wel wat servers die geen ZFS draaien en gewoon alle data rsyncen naar een ZFS server, die daar snapshots van maakt. Werkt prima.
Als er tijdens een disk safe een snapshot genomen wordt en deze verstuur je, dan heb je daar niets aan omdat de backup nog niet klaar was. Je moet dus wachten totdat je externe backup software klaar is en daarna heb je een goede ZFS snapshot.
Als je zonder externe backup software werkt en ZFS als filesysteem op de live server gebruikt, dan kan het wel.
Sent from my GT-I9505 using webhostingtalk mobile app
Als er tijdens een disk safe een snapshot genomen wordt en deze verstuur je, dan heb je daar niets aan omdat de backup nog niet klaar was. Je moet dus wachten totdat je externe backup software klaar is en daarna heb je een goede ZFS snapshot.
Jip dat is dus het hele punt.. Dat is dus net zo 'achterlijk' als in HP Dataprotector een copy job te doen op basis van 'kopieer alle jobs van de afgelopen 24u..' die trigger moet gewoon uit het backup pakket komen zoals dat bij bv. backup exec gaat, meteen een duplicate job startten na de originele job..
Maar dat ZFS gedoe.. ga het toch eens bekijken, daarstraks eens snel wat over opgezocht ziet er wel handig en eenvoudiger uit dan het huidige manier van werken.. Moet hier binnenkort weer disken toevoegen aan 20TB storage... zal weer wat dagen mogen vingerdraaien voor hij gerebuild is.. dan dat eens bekijken ;-)
Om hier even op terug te komen, niemand die Idera gebruikt hier maakt offsite kopies ? :-)