Een lezer vroeg me:
Als kleine ondernemer is mijn zakelijke data erg belangrijk. Ik heb een contract met mijn hoster dat ze elke dag een backup maken en die een jaar bewaren. Nu wilde ik de backup van bijna een jaar geleden vanwege wat oudere bestanden, maar ik krijg een backup die bijna een maand minder oud is. Is dat wel in de haak?Dat lijkt mij niet te kloppen, hoewel het natuurlijk afhangt van wat er precies is toegezegd. Een gebruikelijke formulering van zo’n backupclausule is deze:
Opdrachtnemer zal dagelijks van de middels de Dienst opgeslagen gegevens een reservekopie maken. Opdrachtnemer zal deze reservekopieën bewaren voor een termijn van een jaar en op verzoek beschikbaar stellen.Hier kunnen nog zaken staan over kosten en het mogen opvragen van één bestand versus alles ineens, maar dat is minder van belang. De kern is dus: dagelijks en een jaar lang bewaren.
Je zou zeggen dat dan een kopie van bestand X van 3 mei 2025 op te vragen moet zijn. Of dat dan de versie van 02:00 of van 19:31 is, is wellicht nog een vrije keuze. Maar waarom zou je bestand X versie 4 juni krijgen als je om 3 mei vroeg?
De enige reële verklaring die ik kan bedenken is dat de hoster niet elke nacht een volledige backup maakt, maar alleen wat er is gewijzigd sinds de dag er voor. Dat scheelt immers nogal in de opslag, met name omdat je het een jaar lang bewaart.
Een schema van periodiek (bijvoorbeeld tweewekelijks) een volledige backup en dagelijks een beperkte is vrij gebruikelijk. Het zou kunnen dat daarbij niet alle datumstempels correct teruggezet worden, al blijf ik daar vraagtekens bij houden.
Zuiver juridisch zeg ik dus: met dit beding heb je recht op de versie van 3 mei, en is leveren van die van 4 juni niet conform de afspraak.
Arnoud
Langgeleden zette je een backup aanpak op. Bijvoorbeeld eens per maand een volledige backup roterend over ‘n jaar. Dan ‘n delta per week een voor alle veranderingen ten opzichte van de week daar voor. Roterend per maand. En dan een delta per dag roterend per week. Wil je een volledige backup terug dan moest je eerst de laatste maandelijkse terug zetten dan de weken daarvoor etc etc.
Dus in ‘t ergste geval moest 1 m + 3 w + 6 d = 9 backups over elkaar heen in de juiste volgorde terug zetten.
Gelukkig is storage tegenwoordig super goedkoop en lekker groot en kun je vaak een dagelijkse full backup maken.
Is toch nergens voor nodig?
Ik maak één van mijn backups (de dagelijkse) met rsync en hardlinken.
Ik heb elke dag van de afgelopen 5 jaar een snapshot van het systeem, maar alleen gewijzigde bestanden nemen ruimte in. Het backup systeem mount via SMB de schijven waarvan een backup wordt gemaakt.
De kleine backup omvang is juist een dubbel voordeel: Ik monitor op de backuptarget de omvang van de backup. Als een crypto locker de boel versleutelt zie ik dat door een onverwachte toename van de backup size.
Hardlinks nemen wel ruimte in maar dat is niet eenvoudig zichtbaar. Elke hardlink gebruikt een inode. Bij het formatteren wordt er ruimte gereserveerd voor de inodes (een van de redenen waarom een 1 TB schijf minder dan 10^12 bytes beschikbaar heeft). Die ruimte wordt opzij gezet (256 bytes per inode bij ext4) onafhankelijk of je het gebruikt. Als je meer inodes nodig hebt, moet je je data backuppen en de schijf opnieuw formatteren.
De standaardinstelling is om één inode te reserveren per 16 KiB schijfruimte (via bytes-per-inode), dus een 1 TB schijf heeft ongeveer 61 miljoen inodes. Met jouw methode heb je 1825 (=5*365) inodes nodig per bestand. Bij 34k bestanden kom je tekort. Met mijn foto’s en documenten ga ik daar ruim overheen. Je moet daar dus goed rekening mee houden als je dit opzet.
Ik wilde het niet te technisch maken, maar ja het is een speciaal voor dit doel ingerichte RAID6 array met XFS als bestandssysteem (dubbele parity schijf tegen ‘bit rot’).
Als ik het nu op zou zetten zou ik btrfs gebuiken, dat bestandsysteem heeft deze limiet niet en ingebouwde snapshots.
Ik gebruik een vergelijkbaar systeem als Elroy en ben nog niet uit mijn inodes gelopen. Dat komt omdat een harde link een extra directory entry is naar hetzelfde bestand (en dus ook inode). Er wordt door rsync alleen een nieuwe inode (en bestand) aangemaakt als rsync tot de conclusie komt dat het bestand gewijzigd is. Directory entries worden gealloceerd uit de bestandsruimte op de schijf.
Ik heb ervoor gekozen om niet alle dagelijkse backups te bewaren, maar om een schema met 7 dagelijkse, 4 wekelijkse en drie kwartaal backups aan te houden en een “onbeperkte” hoeveelheid jaarbackups. Ik verwacht niet dat ik het ooit nodig heb om een versie van een specifieke dag, meer dan een maand geleden terug te halen. (Ja, het zou mooi zijn als het aantal inodes op een UNIX bestandssysteem dynamisch aangepast kon worden…)
Btrfs heeft dynamische inodes, maar ik had op XFS vooraf al wat meer ruimte gereserveerd en ben ook nog niet tegen de limiet aangelopen.
Dat ik dagelijkse backups bewaar is eigenlijk gewoon gemakszucht. Hoef ik niet in mijn script met rotaties e.d. te gaan werken en omdat ik nooit een backup verwijder kan ik ook niet door een bug de verkeerde verwijderen. Met 5 x 16TB (3x 16TB ex redundantie beschikbaar) kan ik voorlopig wel voort.
Dit doet me de denken aan een uitspraak van iemand op mijn werk. Het zal zeker 30 jaar geleden zijn.
Iedere boerenl*l kan een backup maken. Maar alleen de echte vakmensen kunnen de zaak ook terug zetten.
Gebruikelijk heb je bij je database nog journaling files waarmee je de database vooruit kan rollen naar een datum naar keuze. In journals legt je database management systeem alle mutaties vast die gedaan worden op de database. Bij een backup worden de journaling gereset en begint je database weer opnieuw je mutaties vast te leggen vanaf het moment van de backup. Ik zou het normaal vinden dat je opslagdienst je database weer vooruit rolt of als ze geen toegang hebben tot je omgeving instructies geeft over hoe je de database weer vooruit kan rollen tot de gewenste datum.
Ik vind het op zich redelijk om de interpretatie van de afspraak te maken dat de backup het mogelijk maakt om de status van bestanden tot minimaal een jaar terug te kunnen zetten met een resolutie van 1 dag. Dit maakt backup van wijzigingen mogelijk, maar vereist ook een volledig snapshot als basis. Dit is waarschijnlijk dus ouder dan een jaar.
Bij dit soort schema is het effect namelijk het zelfde als wanneer er per dag een volledige backup is. Maar dan moet er niet vergeten worden om een basis-backup te hebben.