Diskspace is cheap, bandwidth usually isn’t
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!