Verschil tussen VPS snapshot, backup en clone

Wat een snapshot, een backup en een clone daadwerkelijk zijn

Een VPS-snapshot is een schijfkopie van uw server, beheerd door uw provider, op de infrastructuur van uw provider en binnen uw account. Een backup is een onafhankelijke kopie van uw gegevens die u elders kunt terugzetten, zonder hulp van de provider die de originele gegevens beheerde. Een clone is een nieuwe instantie die vanuit een snapshot wordt uitgerold; deze begint als een exacte kopie van het origineel, inclusief de identiteit.

Ze lossen verschillende problemen op. Een snapshot draait een mislukte upgrade binnen enkele minuten terug, maar biedt geen bescherming als een account wordt afgesloten. Een backup overleeft het verdwijnen van een provider, maar het herstel duurt langer omdat u eerst de machine opnieuw moet opbouwen. Een clone levert in één stap een tweede draaiende server op, maar zorgt er ook voor dat twee machines denken dat ze dezelfde machine zijn.

Waarom een VPS-snapshot geen back-up is

Het probleem is het storingsdomein, niet de kwaliteit van de image. Een snapshot bevindt zich op het opslagplatform van uw provider, meestal in dezelfde regio als de server waarvan deze afkomstig is, en altijd binnen hetzelfde account. Eén gebeurtenis kan zowel de server als de bijbehorende snapshot vernietigen.

• Het account wordt opgeschort, een betaling mislukt of iemand steelt de inloggegevens.
• Een persoon of script met API-toegang verwijdert de instantie. Bij veel providers worden bij het verwijderen van een instantie ook de snapshots verwijderd. Lees de documentatie van uw provider voordat u ervan uitgaat dat dit anders is.
• De regio heeft een storing en alles daarin is tegelijkertijd onbereikbaar.
• Iets dat als root op de server draait, vindt het provider-API-token dat u in /root heeft achtergelaten en verwijdert de snapshots voordat de schijf wordt aangepast.

Een back-up is de kopie die alle vier deze scenario's overleeft. De test is één vraag: als uw provideraccount vanmiddag zou ophouden te bestaan, wat zou u dan nog kunnen herstellen en waar zou u dat herstellen? Alles wat niet aan die vraag voldoet, is een hulpmiddel voor een rollback. Blijf snapshots maken, want niets herstelt sneller. Bewaar daarnaast een tweede kopie op opslag die niet door uw provider wordt beheerd.

De oude regel blijft van kracht: drie kopieën van de data, op twee soorten opslag, waarvan één buiten het platform. Een provider-snapshot plus een restic back-uprepository op aparte infrastructuur dekt dit af met twee componenten.

Waarom een snapshot van een draaiende database corrupt kan raken

Een snapshot van een provider kopieert het block device zoals het op één specifiek moment is. Het vraagt uw applicaties niet om eerst te stoppen en het heeft geen inzicht in gegevens die nog in de page cache staan. De image is daarom in het beste geval crash-consistent. Het ziet er exact zo uit als de schijf eruit zou zien als iemand de stroomkabel eruit trekt.

Het grootste deel van de stack kan hier goed mee omgaan. ext4 en XFS spelen hun journal opnieuw af bij het mounten, waardoor het bestandssysteem weer opkomt. PostgreSQL speelt zijn write-ahead log opnieuw af bij het opstarten, en het logboek meldt dit ook:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB doet hetzelfde en toont zijn eigen regels voor crashherstel tijdens het opstarten. Dat herstel is de database die werkt zoals ontworpen, dus een snapshot van een enkel volume van een rustige PostgreSQL- of MySQL-database herstelt meestal zonder problemen.

De gevallen waarin crash-consistentie niet volstaat, zijn reëel en kunnen voor grote problemen zorgen. Als uw data over twee volumes is verdeeld, worden de root-schijf en een aparte data-schijf op verschillende momenten vastgelegd. Hierdoor kunnen de databestanden en de logdirectory inconsistent raken en heeft het herstelproces geen correcte gegevens om opnieuw af te spelen. Elk bestand dat een applicatie schrijft zonder fsync aan te roepen, zoals een half ontvangen upload of een queue-bestand, kan afgebroken terugkeren. Alles wat de applicatie in het geheugen houdt en op basis van een timer wegschrijft, staat simpelweg niet in de image.

Maak daarom een dump naar schijf voordat u de snapshot neemt. De image bevat dan één bestand waarvan u weet dat het intern consistent is, ongeacht de status van de live databestanden.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction geeft een consistente dump van InnoDB-tabellen zonder schrijfacties te blokkeren, omdat de dump binnen één repeatable-read transactie draait. Dit geldt niet voor MyISAM-tabellen; daarvoor is een lock of een gestopte server nodig. Controleer of de dump niet leeg of afgebroken is voordat u deze vertrouwt: tail -n 1 /var/backups/mysql-$(date +%F).sql op een volledige mysqldump eindigt met een Dump completed commentaar.

Als u een apart datavolume heeft, kunt u dit bevriezen voor de seconden die de snapshot nodig heeft:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

Bevries alleen een datavolume. Bevries nooit /. Een bevroren root-bestandssysteem blokkeert elke schrijfactie op de server, inclusief de shell die u zou gebruiken om het unfreeze-commando in te voeren. U sluit uzelf dus buiten en moet wachten op een harde reset.

De offsite-helft: restic of Borg

De snapshot is de snelle helft. De offsite-kopie is de helft die uw provider overleeft. restic is een goede standaardkeuze omdat het dedupliceert, aan de clientzijde versleutelt en schrijft naar S3-compatibele objectopslag, SFTP of een eenvoudige map. Een storage VPS als offsite-doel werkt hier goed, omdat backup-repositories eerder capaciteit dan IOPS vereisen.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

Kopieer die passphrase nu naar een wachtwoordbeheerder, op een apparaat dat niet deze server is. Een restic-repository kan zonder deze passphrase niet worden geopend en er is geen herstelmethode. Als de enige kopie van het wachtwoord op de machine stond die u zojuist bent verloren, is de backup niets meer dan versleutelde ruis.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E behoudt deze variabelen, aangezien root anders een schone omgeving krijgt en restic meldt dat er geen repository-locatie is opgegeven. restic snapshots hoort de run die u zojuist heeft gemaakt weer te geven, inclusief de host en de paden. Controleer de repository zelf volgens een schema en lees daadwerkelijk wat data terug in plaats van alleen de structuur te valideren:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Een ongeteste backup is slechts een aanname. Herstel minstens één keer naar een andere VPS, meet de tijd en noteer deze, want dat getal is uw werkelijke hersteldoel. Borg is het andere solide alternatief en slaat de repository op via SSH in plaats van objectopslag; de afwegingen worden besproken in de vergelijking tussen restic en BorgBackup.

Wat u moet herstellen voordat een gekloonde VPS in productie gaat

Een kloon is een exacte kopie. Dat is het verkoopargument, maar ook het probleem. Alles wat het origineel uniek maakte, is gedupliceerd, en duplicaten botsen met elkaar.

Genereer de SSH-hostkeys opnieuw. De kloon bevat de /etc/ssh/ssh_host_*-bestanden van het origineel, waardoor twee servers dezelfde host-identiteit presenteren. Iedereen die controle heeft over de een, kan zich bij elke client die de sleutel heeft geaccepteerd voordoen als de ander. SSH geeft geen waarschuwing, omdat de sleutel overeenkomt met wat de client verwachtte.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A schrijft een nieuwe sleutel van elk type dat de daemon verwacht. De vingerafdruk van het laatste commando moet afwijken van die van het origineel. Uw huidige sessie blijft actief na de herstart, omdat het herstarten van sshd geen bestaande verbindingen verbreekt. Doe dit voordat iemand verbinding maakt met de kloon. Als u dit uitstelt, krijgt elke client die de overgenomen sleutel al vertrouwde een WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! en moet deze eerst ssh-keygen -R <host> uitvoeren.

Reset de machine-ID. /etc/machine-id is een unieke identificatiecode die systemd eenmalig genereert bij de eerste keer opstarten; de kloon neemt deze over.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

Een leeg /etc/machine-id-bestand instrueert systemd om bij de volgende opstart een nieuwe waarde te genereren; daarom maakt u het bestand leeg in plaats van het te verwijderen. Twee zaken raken defect wanneer deze ID gedupliceerd is. Op systemen die hun adres via DHCP verkrijgen, leidt systemd-networkd standaard zijn DHCP-client-ID af van de machine-ID. Hierdoor vragen beide klonen een lease aan als dezelfde client en wijst de server hen hetzelfde adres toe. Daarnaast stempelt journald elk item met de machine-ID, waardoor een centrale logverzamelaar beide servers onder één machine opslaat. Voer na de herstart cat /etc/machine-id uit en bevestig dat de waarde is gewijzigd.

Wijzig de hostnaam.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl schrijft /etc/hostname en past de naam direct toe. Het wijzigt /etc/hosts niet, dus pas de regel in 127.0.1.1 aan zodat deze overeenkomt. Slaat u dit over, dan wordt de nieuwe naam nergens opgelost en wacht elke sudo-aanroep op een mislukte opzoekactie, waarna sudo: unable to resolve host web-02: Name or service not known wordt afgedrukt.

Roteer alle in de image ingebakken inloggegevens. De kloon bevat de geheimen van het origineel, waardoor nu twee machines als het origineel kunnen optreden. Loop de SSH authorized_keys-bestanden, API-tokens voor providers en DNS, .env-bestanden van applicaties, databasewachtwoorden, TLS-privésleutels, tokens voor monitoring-inschrijvingen en het wachtwoord voor de restic-repository na. Dit commando vindt de meeste daarvan:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

Als de kloon een testkopie is die nooit verkeer zal afhandelen, trek de gegevens dan in in plaats van ze te roteren. Een staging-omgeving met een actief productie-API-token is een productieomgeving met slechter patchbeheer.

Schakel taken uit die nu dubbel worden uitgevoerd. Twee servers die dezelfde crontab draaien, benaderen op dezelfde minuut dezelfde externe systemen.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

Het geval van restic is het vermelden waard, omdat dit uw retentiebeleid corrumpeert in plaats van alleen luidruchtig te falen. restic voorziet elke snapshot van een hostnaam-tag en restic forget --keep-daily 7 past zijn beleid per host toe. Twee machines die dezelfde hostnaam rapporteren, worden als één host behandeld. Hierdoor kunnen zeven "dagelijkse" snapshots allemaal afkomstig zijn van de kloon, terwijl de snapshots van het origineel worden verwijderd. Herstel de hostnaam vóór de eerste back-up of stop de timer op de kloon. Het geval van certbot is eenvoudiger: twee servers die dezelfde namen vernieuwen, bereiken de limiet van de certificaatautoriteit voor dubbele certificaten. De mislukte poging geeft een foutmelding over te veel uitgegeven certificaten voor die specifieke set namen. Een kloon waarvan het domein nog naar het origineel wijst, kan sowieso geen HTTP-challenge doorstaan, dus schakel vernieuwing daar uit.

Beheer de monitoring-agent. De meeste agents identificeren zich op basis van hostnaam of een ID-bestand dat bij installatie is aangemaakt. Twee agents die als één host rapporteren, voegen hun statistieken samen in één reeks. CPU-grafieken tonen dan waarden die door geen enkele machine afzonderlijk zijn geproduceerd en waarschuwingen gaan flapperen. Stop en verwijder de agent op de kloon, of schrijf deze opnieuw in onder de nieuwe hostnaam volgens de gedocumenteerde procedure van uw leverancier.

Controleer de netwerkconfiguratie op het adres van het origineel. Als de image een statisch adres in netplan bevat, claimt de kloon een IP-adres dat toebehoort aan een andere machine.

ip -br addr
sudo grep -r addresses /etc/netplan/

Wis de cloud-init-status als deze kloon een template wordt.

sudo cloud-init clean --logs

Dit verwijdert de status van cloud-init onder /var/lib/cloud, zodat bij de volgende opstart de modules voor de eerste opstart opnieuw worden uitgevoerd. Dit omvat ook het genereren van SSH-hostkeys als deze ontbreken. Sommige versies bieden ook een vlag om de machine-ID te resetten. Voer cloud-init clean --help uit op uw eigen image om te zien wat uw versie ondersteunt, in plaats van te vertrouwen op een lijst met vlaggen van elders.

Wanneer gebruikt u welke methode

Een risicovolle upgrade terugdraaien: maak een snapshot. Maak deze enkele minuten voor de wijziging, voer de upgrade uit en herstel de image als er iets misgaat. Herstellen verwijdert alle schrijfacties sinds het snapshot, dus bij een server die live verkeer verwerkt, moet u eerst een database-dump maken en precies weten welk tijdsbestek u verliest. Voor een do-release-upgrade op een server die u tien minuten offline kunt halen, is een snapshot het volledige plan.

Migreren naar een groter abonnement: implementeer een kloon. Bouw de kloon vanaf een snapshot op het grotere abonnement, doorloop de bovenstaande lijst met identiteitsgegevens en test deze vervolgens op het eigen IP-adres voordat er verkeer wordt verplaatst. Verlaag de DNS TTL een dag van tevoren zodat de overschakeling snel verloopt en houd de originele server draaiende totdat de nieuwe server echt verkeer heeft verwerkt. Controleer eerst of het grotere abonnement daadwerkelijk sneller is voor uw workload, met behulp van dezelfde benchmarkmethode op beide servers, omdat meer vCPU's op drukkere hardware niet altijd een upgrade zijn.

Een template bouwen: maak een snapshot van een opgeschoonde machine. Installeer en beveilig één server en verwijder vervolgens alles wat uniek is voordat u de image maakt. Geen host keys, een leeg machine ID, geen persoonlijke authorized_keys, geen inloggegevens, cloud-init opgeschoond. Maak daar een snapshot van. Elke instantie die hiervan wordt uitgerold, genereert bij de eerste boot een eigen identiteit, waardoor de bovenstaande checklist niet meer nodig is. Combineer dit met de standaard eerste tien minuten op een nieuwe VPS, zodat de template al het werk bevat dat u anders zou moeten herhalen.

FAQ

Is een VPS-snapshot een back-up?

Nee, want het deelt hetzelfde storingsdomein als de server waarvan het afkomstig is. De snapshot bevindt zich op de opslag van uw provider, in uw account, meestal in dezelfde regio. Een schorsing van uw account, een gestolen API key of het per ongeluk verwijderen van een instance kan de server en de bijbehorende snapshots in één keer verwijderen. Bij veel providers worden snapshots bovendien automatisch verwijderd wanneer de instance wordt verwijderd. Een snapshot is de snelste manier om een rollback uit te voeren, dus blijf ze maken, maar bewaar altijd een tweede, versleutelde kopie op infrastructuur die niet door uw provider wordt beheerd.

Moet ik mijn database stoppen voordat ik een snapshot maak?

Niet altijd, maar u moet wel accepteren wat u krijgt. Een snapshot van een provider is crash-consistent; dit betekent dat de image overeenkomt met de staat van de schijf na een stroomstoring. PostgreSQL en InnoDB herstellen zichzelf hierna bij het opstarten, waarbij PostgreSQL database system was not properly shut down; automatic recovery in progress logt tijdens dit proces. Herstel is niet gegarandeerd wanneer uw data over twee volumes is verdeeld die op verschillende momenten zijn vastgelegd, of wanneer een applicatie schrijft zonder fsync. Schrijf eerst een pg_dumpall of een mysqldump --single-transaction naar de schijf, zodat de image één bestand bevat waarvan u weet dat het consistent is.

Waarom strijden twee gekloonde servers om hetzelfde IP-adres?

Omdat ze dezelfde /etc/machine-id delen. Bij images die gebruikmaken van DHCP bouwt systemd-networkd de DHCP client identifier standaard op basis van de machine ID. Hierdoor vragen beide klonen een lease aan als dezelfde client en biedt de DHCP-server aan beide hetzelfde adres aan. Maak /etc/machine-id leeg (0 bytes), verwijder /var/lib/dbus/machine-id, maak een symlink terug naar /etc/machine-id en start de server opnieuw op zodat systemd een nieuwe waarde genereert. De andere veelvoorkomende oorzaak is een statisch adres in /etc/netplan/ dat letterlijk is gekopieerd; controleer dit met ip -br addr.

Wat is de snelste manier om te controleren of een kloon veilig in productie kan worden genomen?

Vergelijk vier zaken met het origineel. Voer ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub uit op beide en bevestig dat de fingerprints verschillen. Voer cat /etc/machine-id uit op beide en bevestig dat de waarden verschillen. Voer hostnamectl status uit en bevestig dat de naam nieuw is en correct resolveert, zodat sudo geen waarschuwing geeft. Voer vervolgens systemctl list-timers --all uit en stop elke timer die communiceert met een gedeeld systeem, zoals back-ups, certificaatvernieuwing of een monitoring-agent, totdat u heeft bepaald welke machine verantwoordelijk is voor die taak.