Immutable backups; hoe zit dat nou eigenlijk?

Bij Ekco merken we dat er de laatste tijd veel te doen is rondom immutable backups. Het blijkt dat er veel verschillende verwachtingen zijn met betrekking tot de werking hiervan en wat dit bijvoorbeeld doet met storage gebruik. Tijd om daar verandering in te brengen. Dus ga er even voor zitten!

Geschreven door: Frank Wijmans

In de basis is het allemaal niet zo verschillend van elkaar, ‘gewone’ repositories en immutable repositories. Sterker nog, het zijn identieke servers met dezelfde storage op de achtergrond. Het enige wat eigenlijk verschilt is dat Veeam op de immutable repository backup bestanden markeert als ‘immutable’. Daardoor zijn de bestanden niet te wijzigen en niet te verwijderen. Dit simpele feit heeft natuurlijk wel enige impact, met name op de backup methode die vereist is en dat storage gebruik omhoog kan gaan.

Eerst even een paar feitjes op een rij, voordat we er verder induiken:

• De immutability periode (7 dagen) wordt ingesteld op de target backup repository.
• Het is een vereiste dat er gebruikgemaakt wordt van de GFS retention policy, dat betekent dus wekelijkse full backups. Wat ook inhoudt dat men dus gebruik moet maken van de backup methode Forward Incremental* en dat Forever Forward Incremental** niet ondersteund wordt.
• Er zal hoogstwaarschijnlijk een toename zijn in de backup storage. De laatste 7 dagen kunnen immers niet gewijzigd, verwijderd of gemerged worden volgens de ‘normale’ regels van de retention policies.
• De retention policies voor lokale backups én voor de backup copy jobs mogen van elkaar afwijken.
• Het is niet verplicht om zowel lokaal als offsite immutability te gebruiken.
• Bij een Active full backup wordt er een full backup gemaakt en geüpload. Een Synthetic full maakt aan jouw kant een incremental welke bij de SP omgebouwd wordt tot een full backup op basis van de chain die daar al staat. De Active full gebruikt dus veel meer bandbreedte. Om deze reden wordt de Synthetic full het meest gebruikt.

*Forward Incremental: deze methode maakt elke week een full backup (active of synthetic) plus zijn incrementals aan de hand van het aantal ingestelde restore points.

** Forever Forward Incremental: deze methode maakt maar één full backup en verder altijd incrementals aan de hand van het aantal ingestelde restore points.

Goed, nu we dat uit de weg hebben…hoe ziet een backup chain er nu precies uit als we een immutable periode van 7 dagen hanteren? Nou, dat ziet er bijv. zo uit als we voor het gemak een retentie van 3 dagen hanteren:

• De full backup file van een actieve backup chain is aangemaakt op 12 januari. De eerste incremental is aangemaakt op 13 januari. De tweede en laatste incremental is aangemaakt op 14 januari;
• De immutability periode op de backup repository is ingesteld op 7 dagen;
• De full en de incremental backups zijn vervolgens immutable tot 21 januari: de datum van het laatste gemaakte restore point (14 januari) + 7 dagen.

Oke, still with me? So far so good? We zijn al halverwege hoor!

Het laatste punt wat ik aan wil stippen is dan storage gebruik. Hier is de meeste ruis in het verhaal en er gaan verschillende cijfers de ronde. De één roept ‘Storage neemt toe met ongeveer 10 tot 25%’ en de ander roept ‘De storage gaat omhoog met een factor 3 of 3.5!’. Dat is nogal een verschil, vind je niet?

Wat we goed moeten onthouden is dat je pas iets zinnigs kan zeggen over de toename van de storage, als je weet waar de organisatie vandaan komt. Wat bedoel ik hiermee? Simpelweg komt dat op het volgende neer: maakt men gebruik van de Forever Forward Incremental methode (1 full backup + incrementals) of van de Forward Incremental methode (elke week een full + incrementals). Als men de Forever Forward Incremental methode gebruikt, schiet je storage omhoog omdat je meer full backup files gaat krijgen. Bij de Forward Incremental is dat niet het geval, omdat je die full backup files al hebt.

Meer informatie

Wil je meer weten over immutable backup? Neem dan contact met ons op.