Backup af VPS: kontroller, at filerne kan gendannes
En backup af VPS er først nyttig, når du kan hente den uden for serveren og gendanne de rigtige filer. Denne øvelse pakker en statisk side og en Nginx-konfiguration, kopierer dem til en anden computer og verificerer indholdet uden at ændre et aktivt websted.
VPSuntu · Opdateret · Ca. 5 min. læsning
I denne guide
Afgræns øvelsen
Brug Bash, GNU tar, sha256sum og OpenSSH på Ubuntu samt en separat Linux- eller WSL-computer. Behold én terminal til serveren og én til klienten, så variablerne fra tidligere trin fortsat findes. Stop efter enhver kommandofejl.
Der oprettes to øvelsesfiler under din hjemmemappe. De ændrer ikke Nginx, firewall eller aktive webfiler. Arkivet udpakkes aldrig som root eller i /. Et helt websted kan også kræve database, redirects, includes, DNS og andre afhængigheder; de indgår ikke automatisk her.
Lav to øvelsesfiler på serveren
Kør som din almindelige administratorkonto. mktemp opretter en særskilt mappe, og umask begrænser nye filers rettigheder. Nginx-konfigurationen er en inaktiv fil, der kun skal arkiveres.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"Den engelske tekst Recovered static page er testfilens overskrift og bruges senere til indholdskontrol. Gem den udskrevne mappesti til overførslen. Ingen live-filer overskrives.
Opret arkiv og kontrolsummer
Fortsæt i samme serverterminal, hvor øvelsens mappevariabel findes:
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"Indholdslisten skal vise site/, nginx/, de to valgte filer og SHA256SUMS. Lad indholdet være uændret mellem beregning og pakning. Den ydre kontrolsum kontrollerer det overførte arkiv; manifestet inde i arkivet kontrollerer de gendannede filer.
Kontrolsummer autentificerer ikke kopien, hvis nogen kan erstatte både data og forventet kontrolsum. Beskyt derfor destinationskonto og opbevaring.
Flyt kopien til en anden computer
Kør i din lokale Linux- eller WSL-terminal. Sæt remote_backup til den præcise export-mappe, serveren viste. REPLACE er en pladsholder, ikke det tilfældige suffix fra mktemp. Erstat konto, IP og nøgle med din fungerende adgang.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Verificér serverens værtsnøgle via en betroet kanal ved første forbindelse. Hvis SSH fejler, følg fejlsøgningen frem for at deaktivere nøglekontrollen.
SCP beskytter overførslen gennem SSH. tar.gz er komprimeret, ikke krypteret i hvile. Brug passende rettigheder og lagringskryptering. En anden mappe på samme VPS er ikke en uafhængig kopi.
Kontroller arkivet før udpakning
Fortsæt i samme lokale terminal:
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"sha256sum skal vise OK. Undersøg derefter de arkiverede stier. Ved afvigelse skal årsagen eller overførslen undersøges; omskriv ikke kontrolsummen for at få fejlen til at forsvinde. Et uventet eller ubekræftet arkiv udpakkes ikke.
Gendan i en ny tom mappe
Udpak det betroede arkiv i en ny mappe. --keep-old-files afviser overskrivning af eksisterende filer, og --no-same-owner undgår at genskabe arkivets ejerskab. Brug ikke sudo.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"Forvent OK for både site/index.html og nginx/first-site.conf samt testfilens overskrift. Det viser, at de valgte filers bytes blev gendannet. Det beviser ikke produktionsrettigheder, ACL’er, serviceadgang eller alle webstedets afhængigheder.
Adskil filgendannelse fra gendannelse af tjenesten
Den gendannede konfiguration er stadig en inaktiv tekstfil. På en separat erstatningsserver skal stier, includes, moduler, rettigheder og certifikater vurderes, og den samlede Nginx-konfiguration valideres før genindlæsning. Kontroller derefter HTTP/HTTPS udefra. En syntakstest af den uændrede live-server tester ikke denne kopi.
Arkivet indeholder ikke TLS-private nøgler. Planlæg genudstedelse eller en særskilt beskyttet kopi. Brug databasens understøttede metode til konsistent backup og gendannelse; kopi af aktive databasefiler med denne tar-opskrift er ikke tilstrækkeligt.
Snapshots kan hjælpe ved maskinfejl, men undersøg opbevaring, fejldomæne og gendannelsesprocedure. At et snapshot findes, beviser ikke, at eksportfiler kan gendannes på en ny vært.
Sæt mål og registrér resultatet
RPO angiver accepteret datatab målt i tid; RTO er målet for, hvor hurtigt tjenesten skal være tilbage. Et eksempel kunne være 24 timers RPO og 60 minutters RTO. Det er forretningsmål, ikke målte resultater fra denne øvelse. Daglige backups hjælper kun, hvis de lykkes og kan gendannes.
På en lille skærm kan du rulle tabellen sidelæns.
| Registrér | Hvad oplysningen viser |
|---|---|
| Tidspunkt og release-ID | Hvilken version der kan gendannes |
| Uafhængigt opbevaringssted og retention | Hvor kopien overlever, og hvor længe den findes |
| Arkivets og filernes kontrolsummer | Om de valgte bytes blev gendannet |
| Start- og sluttid | Tid til de definerede gendannelsestrin |
| Manglende filer, rettigheder og afhængigheder | Hvad der mangler før tjenesten virker |
| Ekstern HTTPS-test på erstatningsserver | Om webstedet reelt er tilbage |
Mål hele processen, inklusive adgang, ny maskine, konfiguration, certifikater og DNS. Hurtig udpakning er ikke en måling af samlet nedetid. Bevar passende historik og reager på fejlede backupjob. Vurder udbyderens gendannelsesvilkår sammen med planen.
Spørgsmål og svar
Skal originalen slettes for at bevise, at kopien virker?
Nej. Gendan i en separat tom mappe og test den fulde tjeneste i et særskilt miljø.
Betyder korrekt kontrolsum, at alt er med?
Kun de filer, manifestet nævner, er kontrolleret. En udeladt database, nøgle, DNS-indstilling eller fil opdages ikke automatisk.
Er øvelsen en fuld produktionsbackup?
Nej. Den viser filkopiering og kontrol. Produktionsbackup kræver fuld inventarliste, tidsplan, overvågning og applikationsspecifik gendannelse.