On interesting stuff
Posts tagged backups
Nieuw netwerk; het nieuwe backup-plan
Mar 1st
Door het toepassen van virtualisatie en rollenscheiding heb ik nu de verschillende services geissoleerd draaien, het backuppen moest hierdoor volledig anders worden ingericht. Ik heb uiteindelijk gekozen voor de volgende opzet;
- rsnapshot voor de configuraties en belangrijke directories per server – ik bewaar 6 hourly’s, 7 daily’s, 4 weekly’s en 12 monthly’s backups. Door de efficiente opzet van rsnapshot kost me dit slechts de ruimte van 1 backup plus mijn wijzigingen sindsdien, en dat valt best mee. Ook in sync-snelheid is dit natuurlijk ENORM handig; 1 daily is bij mij 2.5Gb, de volgende daily zal echter alleen de wijzigingen opslaan, de rest wordt middels een ‘hard-link’ ook in de huidige snapshot geplaatst waardoor ten alle tijde een volledig overzicht van de data op dat moment beschikbaar is. Je hoeft dus niet op zoek naar die ene incremental waar je file in zit, die zit in alle backups (maar neemt slechts 1 keer ruimte in). Middels rsync kan de data met behoud van hardlinks worden gesynchroniseerd waardoor de data ook echt maar 1 keer over de lijn gaat. Op deze manier synchroniseer ik 32Gb aan data binnen 10 minuten over een 50KB/s capped lijn, best relax!
- rsync – onmisbare tool om te backuppen – synced folders over het netwerk (eventueel over een SSH tunnel voor encryptie) en verstuurd alleen de gewijzigde delen van het bestand waardoor de tijd die het kost enorm afneemt. Ik gebruik rsync voor de backups van mijn vaders bedrijf en om mijn eigen OpenVZ-images en rsnapshot-backups te syncen naar Eindhoven.
- Proxmox Backups – Proxmox kan, enkel geconfigureerd vanuit de web-ui, de virtuele machines gescheduled ‘live’ backuppen middels een snapshot van het LVM-volume, hierdoor worden alle vormen van locks en dergelijke omzeild en kan de volledige machine worden gebackupped. De images transfer ik vervolgens met rsync naar Eindhoven, mocht de boel in Ede ooit crashen dan kan ik in minder dan een uur tijd alle machines restoren op een verse Proxmox-machine, is voorlopig goed genoeg
Ik ben nog bezig met het implementeren van MBR-backups en een efficientere sync van de Proxmox-backups; op dit moment transfer ik die nog steeds volledig bij iedere sync en dat is bijzonder inefficient en tijdrovend. Het lijkt nog even te duren voor we hier in Eindhoven op 100Mbit zitten dus ik ga de rsync man-page er nog maar eens op nalezen…
Binnen Nagios is het bijzonder gemakkelijk om zelf scripts te schrijven om allerhande zaken op je systeem te laten controleren, zo krijg ik bijvoorbeeld automatisch bericht als de backupsynchronisatie om wat voor reden dan ook langer dan 24 uur niet lukt. Hier onder een screenshot uit de backup-monitoring;
Nagios Monitoring - Backups
Diskspace is cheap, bandwidth usually isn’t
Dec 3rd
Binnen een goed ingericht backup-proces is het belangrijk dat bij complete vernietiging van één van de locaties een volledige, actuele backup beschikbaar te hebben op een andere fysieke locatie. Het synchroniseren van dergelijke backups verloopt vaak via trage huurlijnen die ook worden gebruikt voor andere doeleinden, het wordt hierdoor erg lastig om de synchronisatie binnen het beschikbare backup-window afgerond te krijgen zonder de volledige bandbreedte op te eissen.
Voorheen maakte ik backups in het .tar.gz formaat, een normale .tar file (tar = meerdere files opslaan in 1 bestand) die vervolgens compressed wordt door middel van gzip (soort zip). Het transferen van deze full backups over de VPN duurde soms bijna 24 uur, wat natuurlijk veel te lang is:
15/11/09 21:17 – 0 – OK – Weekly full backup created successfully (ede-srv-01.full-Sun.tar.gz (7.1G))
16/11/09 17:43 – 0 – OK – Backups finished syncing to 192.168.1.2 successfully
Ik heb dit na wat research binnen mijn netwerk opgelost door de volgende backup-methode te implementeren en een aanpassing door te voeren op het filetype.
- Op de eerste dag van de maand wordt een permanente backup gemaakt, deze blijft in principe altijd bewaard (filename: ede-srv-01.full-Dec09.tar)
- Iedere zondag wordt er een volledige backup gemaakt, deze overschijft de full Sunday backup van vorige week (filename: ede-srv-01.full-Sun.tar)
- Iedere dag wordt er een incrementele backup gemaakt, deze overschrijft de incremental backup van die dag van vorige week (filename: ede-srv-01.incr-Mon.tar)
Met .tar.gz wordt de inhoud van het .tar bestand nog compressed door middel van gzip, het voordeel hiervan is een lagere filesize. Op het eerste gezicht zou je dus zeggen dat dit sneller is. De kracht van de synchronisatie-tool rsync is echter dat het alleen de gewijzigde bits van een bestand copieert. Door gebruik te maken van overschrijvende backups (de normale doordeweekse backups overschrijven die van vorige week) zijn er in de meeste gevallen veel overeenkomsten tussen deze backups op beide servers.
Door vervolgens ook gebruik te maken van een uncompressed backup (.tar ipv .tar.gz) is de uiteindelijke filesize groter (op dit moment 9.6GB voor .tar en 7.1 voor .tar.gz) maar kunnen wel enkel de veranderingen worden gesynchroniseerd, wat in de meeste gevallen dus neer komt op slechts een fractie van het totaal. Tijdens de synchronisatie pas ik vervolgens gzip-compressie toe op de datastroom om de effectieve getransferde data nog kleiner te maken. Hieronder het bewijs:
29/11/09 20:38 – 0 – OK – Weekly full backup created successfully (ede-srv-01.full-Sun.tar (9.6G))
30/11/09 1:17 – 0 – OK – Backups finished syncing to 192.168.1.2 successfully
Zoals je ziet is de backup 15 uur en 40 minuten sneller klaar (77.72% winst!!), een enorme verbetering dus! Ook opvallend is dat de backup zelf eerder klaar is doordat tijdens het maken van het .tar-bestand geen compressie hoeft worden toegepast (20:38 vs 21:17). Alleen op de gewijzigde bits die over het netwerk worden getransfferd wordt vervolgens compressie toegepast, waardoor de effectieve CPU-belasting van de servers ook afneemt.
110KB/s capped sync. Normaal zou dit dus 21 minuten duren, nu slechts 2!
Om de efficiency zelfs voor full Monthly backups (die dus in principe uniek zijn) ook zo hoog te krijgen maak ik gebruik van een simpel maar effectief template-systeem. De dag voor de full Monthly backup wordt op de ontvangende server alvast de vorige Monthly full gecopieerd naar de filename van de toekomstige full backup. Op die manier wordt eenzelfde efficiency behaald als bij de andere backups die de vorige versie sowieso al overschrijven. Diskspace is cheap, bandwidth usually isn’t!