Hoe een Effectieve Back-up Strategie te Kiezen

Introductie

Back-ups zijn zeer belangrijk voor cloudservers. Of u nu een enkel project uitvoert met al zijn gegevens opgeslagen op een enkele server, of rechtstreeks implementeert vanuit Git naar VM’s die worden opgestart en afgebroken terwijl een minimum aan logs behouden blijft, u moet altijd plannen voor een scenario met fouten. Dit kan veel verschillende dingen betekenen, afhankelijk van de applicaties die u gebruikt, hoe belangrijk het is om onmiddellijke failover te hebben, en wat voor soort problemen u verwacht.

In deze handleiding verkent u de verschillende benaderingen voor het leveren van back-ups en gegevensredundantie. Omdat verschillende gebruiksgevallen verschillende oplossingen vereisen, zal dit artikel u geen one-size-fits-all antwoord kunnen geven, maar u zult leren wat belangrijk is in verschillende scenario’s en welke implementaties het meest geschikt zijn voor uw operatie.

In het eerste deel van deze handleiding bekijkt u verschillende back-upoplossingen en beoordeelt u de relatieve voordelen van elk, zodat u de aanpak kunt kiezen die bij uw omgeving past. In het tweede deel verkent u redundantieopties.

Deel 1 — Wat is het verschil tussen redundantie en back-uppen?

De definities van de termen overbodig en back-up overlappen vaak en worden in veel gevallen verward. Dit zijn twee verschillende concepten die gerelateerd zijn, maar verschillend. Sommige oplossingen bieden beide.

Overbodigheid

Overbodigheid in gegevens betekent dat er directe overschakeling plaatsvindt in geval van een systeemprobleem. Een overschakeling betekent dat als een set gegevens (of een host) niet beschikbaar is, er onmiddellijk een perfecte kopie wordt ingezet om zijn plaats in te nemen. Dit resulteert in vrijwel geen waarneembare downtime, en de toepassing of website kan blijven verzoeken verwerken alsof er niets is gebeurd. In de tussentijd heeft de systeembeheerder (in dit geval jij) de mogelijkheid om het probleem op te lossen en het systeem terug te brengen naar een volledig operationele staat.

Een redundantieoplossing is echter meestal geen back-upoplossing. Redundante opslag biedt niet noodzakelijk bescherming tegen een storing die de hele machine of het systeem treft. Als je bijvoorbeeld een gespiegelde RAID geconfigureerd hebt (zoals RAID 1), zijn je gegevens redundant omdat als één schijf uitvalt, de andere nog beschikbaar zal zijn. Als de machine zelf echter uitvalt, kunnen al je gegevens verloren gaan.

Met redundantieoplossingen zoals MySQL Group Replication wordt elke operatie doorgaans uitgevoerd op elke kopie van de gegevens. Dit omvat kwaadwillige of accidentele operaties. Volgens de definitie moet een back-upoplossing u ook in staat stellen om te herstellen vanaf een vorig punt waar de gegevens als goed bekend staan.

Back-up

Over het algemeen moet u functionele back-ups van uw belangrijke gegevens behouden. Afhankelijk van uw situatie kan dit betekenen dat u toepassings- of gebruikersgegevens, of een volledige website of machine, back-upt. Het idee achter back-ups is dat u in geval van een systeem-, machine- of gegevensverlies uw gegevens kunt herstellen, opnieuw kunt implementeren of anderszins kunt openen. Herstellen vanaf een back-up kan downtime vereisen, maar het kan het verschil betekenen tussen beginnen vanaf een dag geleden en helemaal opnieuw beginnen. Alles wat u niet kunt veroorloven te verliezen, moet volgens definitie worden back-upt.

Wat methoden betreft, zijn er verschillende niveaus van back-ups. Deze kunnen worden gelaagd zoals nodig om rekening te houden met verschillende soorten problemen. Zo kunt u bijvoorbeeld een configuratiebestand back-uppen voordat u het wijzigt, zodat u kunt terugkeren naar uw oude instellingen als er een probleem ontstaat. Dit is ideaal voor kleine wijzigingen die u actief in de gaten houdt. Deze setup zou echter falen in het geval van een schijfprobleem of iets complexers. U moet ook regelmatig geautomatiseerde back-ups naar een externe locatie hebben.

Back-ups op zich bieden geen automatische failover. Dit betekent dat uw storingen u mogelijk geen gegevens kosten (ervan uitgaande dat uw back-ups 100% up-to-date zijn), maar ze kunnen wel de uptime kosten. Dit is een van de redenen waarom redundantie en back-ups vaak in combinatie met elkaar worden gebruikt.

Deel 2 — Back-up op bestandsniveau

Een van de meest bekende vormen van back-ups is een back-up op bestandsniveau. Dit type back-up maakt gebruik van normale hulpprogramma’s voor het kopiëren op bestandsniveau om bestanden naar een andere locatie of apparaat over te brengen.

Hoe de cp-opdracht te gebruiken

In theorie zou u een Linux-machine, zoals uw cloudserver, kunnen back-uppen met de cp-opdracht. Hiermee worden bestanden van de ene lokale locatie naar de andere gekopieerd. Op een lokale computer zou u een verwijderbaar station kunnen aankoppelen en vervolgens bestanden ernaar kopiëren:

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

In dit voorbeeld wordt een verwijderbare schijf, sdc, aangekoppeld als /mnt/my-backup en vervolgens wordt de map /etc naar de schijf gekopieerd. Vervolgens wordt de schijf ontkoppeld, die ergens anders kan worden opgeslagen.

Hoe Rsync te gebruiken

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvP is een typische set Rsync-opties. Een uitsplitsing van wat elk ervan doet:

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

U kunt andere rsync-opties bekijken op zijn man-pagina.

Natuurlijk zou u in een cloudomgeving normaal gesproken niet telkens bestanden naar een gemounte schijf kopiëren en monteren. Rsync kan ook externe back-ups uitvoeren via een netwerk door SSH-stijl syntaxis te bieden. Dit werkt op elke host waar u naar kunt SSH’en, zolang Rsync aan beide kanten is geïnstalleerd. Omdat Rsync wordt beschouwd als een kernhulpmiddel voor Linux, is dit bijna altijd een veilige veronderstelling, zelfs als u lokaal werkt op een Mac- of Windows-machine.

rsync -azvP /etc/* username@remote_host:/backup/

Dit zal de map /etc van de lokale machine back-uppen naar een map op remote_host gelegen op /backup. Dit zal slagen als u toestemming heeft om naar deze map te schrijven en er ruimte beschikbaar is.

U kunt ook meer informatie bekijken over hoe Rsync te gebruiken om lokale en externe mappen te synchroniseren.

Hoe Andere Back-uphulpmiddelen te Gebruiken

Hoewel cp en rsync nuttig en alomtegenwoordig zijn, vormen ze op zichzelf geen volledige oplossing. Om back-ups te automatiseren met Rsync, moet je je eigen geautomatiseerde procedures, back-upschema, logrotatie, enzovoort creëren. Hoewel dit geschikt kan zijn voor enkele zeer kleine implementaties die geen gebruik willen maken van externe services, of zeer grote implementaties die toegewijde middelen hebben voor het onderhouden van zeer gedetailleerde scripts voor verschillende doeleinden, willen veel gebruikers investeren in een toegewijde back-upoplossing.

Bacula

Bacula is een complexe, flexibele oplossing die werkt op een client-servermodel. Bacula is ontworpen met afzonderlijke concepten van clients, back-uplocaties en directors (het onderdeel dat de daadwerkelijke back-up regisseert). Het configureert ook elke back-uptaak in een eenheid genaamd een “taak”.

Dit maakt extreem gedetailleerde en flexibele configuratie mogelijk. Je kunt meerdere clients naar één opslagapparaat back-uppen, één client naar meerdere opslagapparaten, en het back-upschema aanpassen door knooppunten toe te voegen of hun details aan te passen. Het functioneert goed in een genetwerkte omgeving en is uitbreidbaar en modulair, waardoor het ideaal is voor het maken van back-ups van een site of applicatie verspreid over meerdere servers.

Duplicity

Duplicity is een ander open source back-uphulpmiddel. Het gebruikt standaard GPG-versleuteling voor overdrachten.

Het voordeel van het gebruik van GPG-encryptie voor bestandsback-ups is dat de gegevens niet in platte tekst worden opgeslagen. Alleen de eigenaar van de GPG-sleutel kan de gegevens decoderen. Dit biedt een zekere mate van beveiliging om de extra beveiligingsmaatregelen te compenseren die nodig zijn wanneer uw gegevens op meerdere locaties worden opgeslagen.

Nog een voordeel dat misschien niet meteen duidelijk is voor degenen die GPG niet regelmatig gebruiken, is dat elke transactie moet worden geverifieerd om volledig nauwkeurig te zijn. GPG, net als Rsync, dwingt hash-controles af om ervoor te zorgen dat er geen gegevensverlies is opgetreden tijdens de overdracht. Dit betekent dat wanneer u gegevens herstelt van een back-up, u aanzienlijk minder kans zult hebben op bestandsbeschadiging.

Deel 3 — Block-Level Back-ups

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

Een voordeel van de block-level back-ups is dat ze meestal sneller zijn. Terwijl bestandsgebaseerde back-ups doorgaans een nieuwe overdracht initiëren voor elk afzonderlijk bestand, zal een block-gebaseerde back-up blokken overdragen, wat betekent dat er minder niet-sequentiële overdrachten moeten worden geïnitieerd om de kopieeractie te voltooien.

Het Gebruik van dd om Block-Level Back-ups Uit te Voeren

De meest voorkomende methode om blokniveau-back-ups uit te voeren, is met het dd-hulpprogramma. dd kan worden gebruikt om volledige schijfafbeeldingen te maken en wordt ook vaak gebruikt bij het archiveren van verwijderbare media zoals cd’s of dvd’s. Dit betekent dat je een partitie of schijf kunt back-uppen naar een enkel bestand of een rauw apparaat zonder enige voorafgaande stappen.

Om dd te gebruiken, moet je een invoerlocatie en een uitvoerlocatie opgeven, zoals dit:

dd if=/path/of/original/device of=/path/to/place/backup

In dit scenario specificeert het argument if= de invoer van het apparaat of de locatie. Het argument of= specificeert het uitvoerbestand of de locatie. Wees voorzichtig dat je deze niet verwisselt, anders zou je per ongeluk een hele schijf kunnen wissen.

Als voorbeeld, om een partitie die jouw documenten bevat, die zich bevindt op /dev/sda3, te back-uppen, kun je een afbeelding van die map maken door een uitvoerpad naar een .img-bestand op te geven:

dd if=/dev/sda3 of=~/documents.img

Deel 4 — Versiebeheer Back-ups

Een van de belangrijkste redenen om gegevens te back-uppen is om een eerdere versie van een bestand te kunnen herstellen in geval van ongewenste wijzigingen of verwijderingen. Hoewel alle tot nu toe genoemde back-upmechanismen dit kunnen leveren, kun je ook een meer gedetailleerde oplossing implementeren.

Een voorbeeld van een handmatige manier om dit te bereiken, zou zijn om een back-up van een bestand te maken voordat je het bewerkt in nano:

cp file1 file1.bak
nano file1

Je zou zelfs dit proces kunnen automatiseren door tijdstempel verborgen bestanden aan te maken telkens wanneer je een bestand wijzigt met je editor. Bijvoorbeeld, je zou dit kunnen plaatsen in je ~/.bashrc bestand, zodat telkens wanneer je nano uitvoert vanuit je bash (d.w.z. $) shell, het automatisch een back-up maakt gestempeld met jaar (%y), maand (%m), dag (%d), enzovoort:

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

Dit zou werken zolang je bestanden handmatig bewerkt met nano, maar is beperkt in scope, en kan snel een schijf vullen. Je kunt zien hoe het erger zou kunnen zijn dan het handmatig kopiëren van bestanden die je gaat bewerken.

Een alternatief dat veel van de inherente problemen in dit ontwerp oplost, is om Git te gebruiken als versiebeheersysteem. Hoewel het primair is ontwikkeld om zich te richten op versiebeheer van platte tekst, meestal broncode, regel voor regel, kun je Git gebruiken om bijna elk soort bestand te volgen. Om meer te weten te komen, kun je Hoe Git Effectief te Gebruiken bekijken.

Deel 5 — Back-ups op serverniveau

De meeste hostingproviders zullen ook hun eigen optionele back-upfunctionaliteit bieden. De back-upfunctie van DigitalOcean voert regelmatig geautomatiseerde back-ups uit voor droplets die deze service hebben ingeschakeld. Je kunt dit inschakelen tijdens het aanmaken van een droplet door het vakje “Back-ups” aan te vinken:

Dit zal regelmatig een back-up maken van de volledige afbeelding van uw cloudserver. Dit betekent dat u kunt herimplementeren vanaf de back-up, of het gebruiken als basis voor nieuwe droplets.

Voor eenmalige imaging van uw systeem kunt u ook snapshots maken. Deze werken op een vergelijkbare manier als back-ups, maar zijn niet geautomatiseerd. Hoewel het mogelijk is om een snapshot te maken van een draaiend systeem in sommige contexten, wordt dit niet altijd aanbevolen, afhankelijk van hoe u schrijft naar uw bestandssysteem:

U kunt meer te weten komen over DigitalOcean back-ups en snapshots van de Containers en Afbeeldingen documentatie.

GitOps

Tenslotte is het de moeite waard om op te merken dat er omstandigheden zijn waarin je niet per se back-ups op serverniveau wilt implementeren. Bijvoorbeeld, als je implementatie de principes van GitOps volgt, kun je veel van je individuele cloudservers als wegwerpbaar beschouwen en in plaats daarvan externe gegevensbronnen zoals Git-repositories beschouwen als de effectieve waarheidsbron voor je gegevens. Complexe, moderne implementaties zoals deze kunnen in veel gevallen schaalbaarder zijn en minder gevoelig voor storingen. Je wilt echter nog steeds een back-upstrategie implementeren voor je gegevensopslag zelf, of voor een gecentraliseerde logserver waar elk van deze wegwerpbare servers mogelijk informatie naartoe stuurt. Overweeg welke aspecten van je implementatie niet hoeven te worden geback-upt, en welke wel.

Conclusie

In dit artikel heb je verschillende back-upconcepten en oplossingen verkend. Misschien wil je nu oplossingen bekijken om redundantie in te schakelen.