VPS-sikkerhetskopi med en kontrollert gjenoppretting
En VPS-sikkerhetskopi må kunne hentes uten den opprinnelige serveren. Her arkiverer du to testfiler, kopierer dem til en annen maskin og kontrollerer innholdet etter utpakking. Nettstedet som er i drift, endres ikke.
VPSuntu · Oppdatert · Omtrent 5 min lesetid
I denne veiledningen
Avgrens øvelsen
Du trenger Bash, GNU tar, sha256sum og OpenSSH på Ubuntu eller en Linux/WSL-klient. Bruk én serverterminal og én terminal på en separat datamaskin. Behold dem åpne, slik at variablene finnes gjennom hele øvelsen. Stopp ved kommandofeil.
Utgangspunktet er to disponible filer under hjemmekatalogen. Konfigurasjonen skal bare arkiveres, ikke aktiveres. Utpakking gjøres aldri som root. For et større nettsted må innhold, omdirigeringer, DNS, sertifikater og andre avhengigheter registreres separat.
Lag testfiler på serveren
Denne blokken lager en privat øvingsmappe, en liten HTML-side og en inaktiv Nginx-tekstfil. Eksempelteksten i kommandoene beholdes fra EN.
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"Valgfritt kan du kopiere akkurat de to filene fra nettsideveiledningen over de disponible testkopiene. Begge må kunne leses av kontoen. Sjekk konfigurasjonen for hemmeligheter og stans publisering mens du samler én konsistent versjon. Hopp over neste blokk for den rene øvelsen.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Kildene leses, men endres ikke. Private sertifikatnøkler og systemmapper tas ikke med. Legg eventuelle andre nødvendige filer bevisst til både oversikt og kontrollsummanifest.
Lag arkiv og kontrollsummer
På serveren beregner du først SHA-256 for filene, lager arkivet med relative stier og beregner deretter kontrollsummen for hele arkivet. Ikke endre testfilene underveis.
(
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"Listen skal inneholde site/, nginx/, de to filene og SHA256SUMS. Arkivets kontrollsum avslører overføringsendringer; manifestet kontrollerer de utpakkede filene. Ingen av delene beviser autentisitet hvis noen kan erstatte både data og forventet kontrollsum.
Flytt kopien til en separat maskin
På klienten setter du remote_backup til den eksakte eksportmappen serveren skrev ut. REPLACE er en plassholder, ikke den genererte mappen. Endre konto, eksempeladresse og nøkkelsti til fungerende SSH-verdier.
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/"Ved spørsmål om en ny vertsnøkkel må fingeravtrykket kontrolleres gjennom en pålitelig kanal. Bruk SSH-feilsøking hvis forbindelsen mislykkes; ikke slå av identitetskontrollen.
SCP beskytter transporten med SSH. Selve tar.gz-filen er komprimert, ikke kryptert. Beskytt lagringskontoen og bruk kryptering i ro når dataene krever det. En annen mappe på samme VPS er ikke en separat serverkopi.
Pakk ut i en ny tom mappe
På klienten kontrollerer du først arkivet. Fortsett bare når sha256sum viser OK. Ved avvik undersøker du eller overfører på nytt; ikke skriv over den forventede kontrollsummen.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Pakk bare ut dette kjente arkivet i en ny mappe. keep-old-files nekter å overskrive eksisterende filer, og no-same-owner hindrer gjenoppretting av arkivert eierskap. Ikke bytt målmappe til / og ikke bruk 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 og den gjenopprettede overskriften. Dette kontrollerer filinnholdet, ikke produksjonsrettigheter, ACL-er, tjenestestatus eller alle avhengigheter.
Test selve tjenesten separat
Den gjenopprettede Nginx-filen er fortsatt inaktiv. På en erstatningsserver må stier, includes, moduler, rettigheter og sertifikater vurderes før konfigurasjonen valideres og lastes inn. Test HTTP og HTTPS utenfra. En syntakskontroll på den gamle serveren validerer ikke den nye kopien.
Arkivet utelater private TLS-nøkler. Planlegg nye sertifikater eller separat beskyttet sertifikatkopi. Ikke bruk denne tar-oppskriften på aktive databasefiler; bruk databasens egen metode for konsistent kopiering og gjenoppretting.
Snapshots kan være nyttige for maskinen, men sjekk oppbevaring, feildomene og gjenopprettingsprosedyre. Et snapshot beviser ikke at nettstedets eksporterte filer virker hos en annen vert.
Dokumenter målet og resultatet
RPO angir akseptabelt datatap målt i tid. RTO er ønsket tid til tjenesten fungerer igjen. For et lite statisk nettsted kan 24 timers RPO og 60 minutters RTO være illustrerende mål; de er ikke målte resultater her.
På små skjermer kan du rulle tabellen sidelengs for å se alle kolonnene.
| Oppføring | Hva den dokumenterer |
|---|---|
| Kopitid og versjons-ID | Hvilken utgave som kan hentes tilbake |
| Separat lagringssted og oppbevaring | Hvor kopien finnes og hvor lenge |
| Arkiv- og filkontrollsummer | Om valgte byte ble gjenopprettet |
| Start og slutt for gjenoppretting | Tid brukt på definerte steg |
| Manglende filer eller avhengigheter | Arbeid som gjenstår før drift |
| Ekstern HTTPS-test på erstatningen | Om nettstedet faktisk er tilbake |
Mål hele erstatningsprosessen, inkludert tilgang, opprettelse, konfigurasjon, sertifikater og DNS. Rask lokal utpakking er ingen måling av full gjenoppretting. Behold passende historikk og reager på mislykkede kopijobber. Vurder lagring og hjelp til gjenoppretting når du velger VPS-pakke.
Spørsmål og svar
Må jeg slette originalsiden for å bevise at kopien virker?
Nei. En separat tom mappe og kontroll av manifestet tester filene uten driftsstans. Hele tjenesten testes på et separat erstatningsmiljø.
Betyr korrekt SHA-256 at hele nettstedet er kopiert?
Det bekrefter filene i manifestet. Det oppdager ikke en utelatt database, hemmelighet, fil eller DNS-post. Bruk en ressursoversikt og funksjonstest etter gjenoppretting.