Guia pràctica / còpia de seguretat i restauració d’un VPS

Còpia de seguretat i restauració d’un VPS

Una còpia és útil quan la pots recuperar fora del VPS i restaurar els fitxers esperats. Aquest exercici arxiva una pàgina estàtica i una configuració Nginx, les copia a un altre ordinador i comprova els bytes sense tocar el lloc en funcionament.

· Actualització: · Lectura: uns 5 min

Contingut de la guia

Defineix una recuperació petita

Utilitza Bash, GNU tar, sha256sum i OpenSSH amb Ubuntu o un client Linux/WSL. Executa les ordres del servidor en un terminal i les locals en un terminal d’un altre ordinador. Mantén-los oberts perquè conservin les variables. Atura’t davant de qualsevol error.

L’exercici crea dos fitxers prescindibles al directori personal. No canvia Nginx, tallafoc ni contingut viu, i mai no extreu com root. Comença amb les mostres; la substitució opcional només usa els dos fitxers de la guia HTTPS estàtica.

Un lloc més gran necessita inventari de recursos, redirects, includes, DNS i dependències. Dos fitxers no són una còpia completa de màquina o aplicació.

Prepara dos fitxers sense modificar el lloc

Al servidor, crea un directori privat de pràctica. La configuració és un fitxer per arxivar, no un servei per activar.

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"

Opcionalment, reemplaça només aquestes còpies prescindibles per la pàgina i configuració reals del tutorial. Les fonts han de ser llegibles pel compte. Revisa secrets i pausa desplegaments mentre les reculls perquè siguin de la mateixa versió. Omet aquest bloc si fas servir les mostres.

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"

Les ordres llegeixen els originals sense modificar-los. No copien claus TLS ni directoris sencers del sistema. Afegeix explícitament qualsevol altre fitxer necessari tant a l’inventari com al manifest de checksums.

Crea l’arxiu i dues comprovacions

Al servidor, calcula checksums dels fitxers, crea un arxiu amb rutes relatives i calcula’n el checksum. No modifiquis la càrrega durant el pas.

(
    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"

La llista ha de contenir site/, nginx/, els dos fitxers i SHA256SUMS. El checksum extern detecta canvis en l’arxiu transferit; el manifest intern comprova els fitxers extrets. Cap dels dos autentica una còpia si algú pot canviar dades i checksum esperat alhora.

Copia a un ordinador separat

Al client, posa a remote_backup el directori d’exportació exacte imprès pel servidor. Canvia IP, compte i clau pels d’SSH. 203.0.113.10 és una adreça de documentació; REPLACE és un marcador, no el sufix generat per mktemp.

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/"

Verifica una empremta nova per un canal fiable. Si falla SSH, segueix el diagnòstic de connexió; no ometis la verificació del host per facilitar la transferència.

SCP protegeix el transport amb SSH. El tar.gz està comprimit, no xifrat. Protegeix compte i emmagatzematge de destinació i xifra en repòs si les dades ho exigeixen. Un altre directori del mateix VPS no és una còpia externa.

Verifica i restaura en un directori buit nou

Al client, comprova l’arxiu abans d’extreure’l. Continua només si sha256sum mostra OK. Una fallada requereix investigar o repetir la transferència; no sobreescriguis el checksum esperat.

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Extreu aquest arxiu fiable en un directori nou. keep-old-files impedeix reemplaçar fitxers existents; no-same-owner evita recuperar el propietari arxivat. No canviïs la destinació per / ni utilitzis 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"

Espera OK per a site/index.html i nginx/first-site.conf i l’encapçalament recuperat. Això verifica contingut, no propietaris de producció, ACL, disponibilitat ni totes les dependències.

Separa restauració de fitxers i recuperació del servei

La configuració restaurada encara és text inactiu. En un servidor substitut separat, revisa rutes, includes, mòduls, permisos i certificats. Valida allí la configuració Nginx completa abans de recarregar i comprova HTTP/HTTPS des de fora. Validar un servidor viu sense canvis no comprova la còpia restaurada.

L’arxiu exclou deliberadament claus privades TLS. Planifica reemetre certificats o una còpia protegida separada. No copiïs fitxers d’una base activa amb aquesta recepta tar: utilitza el mètode consistent de backup i restauració de la base.

Els snapshots poden ajudar a recuperar màquines; revisa retenció, domini de fallada i procediment. Existir un snapshot no demostra que els fitxers exportats es puguin recuperar en un host substitut.

Registra objectius i resultat

RPO expressa pèrdua acceptable de dades en temps; RTO, el temps objectiu per recuperar el servei. Per a un lloc estàtic informatiu podries fixar 24 hores de RPO i 60 minuts de RTO. Són objectius il·lustratius, no resultats mesurats. Còpies diàries només compleixen el pla si tenen èxit i es poden restaurar.

En pantalles petites, desplaça la taula lateralment per veure totes les columnes.

RegistreQuè demostra
Hora de còpia i versióQuina versió pots recuperar
Destinació independent i retencióOn sobreviu i durant quant temps
Checksums externs i internsSi s’han recuperat els bytes seleccionats
Inici i final de restauracióTemps dels passos definits
Fitxers, permisos o dependències absentsFeina pendent abans de recuperar el servei
HTTPS extern al substitutSi el lloc torna a funcionar

Cronometra tot el procés abans de donar per assolible l’RTO: accés, creació de VM, configuració, certificats i DNS. Una extracció local ràpida no és un benchmark d’incidència. Conserva punts adequats de restauració i vigila treballs fallits. Compara retenció i assistència amb els criteris d’allotjament.

Preguntes freqüents

He d’eliminar el lloc original per provar la còpia?

No. Restaurar en un directori buit separat i comprovar el manifest valida els fitxers sense provocar una interrupció. Prova el servei complet en un entorn substitut.

Un checksum correcte vol dir que tinc tot el lloc?

Confirma els fitxers del manifest. No descobreix una imatge, base, secret o ajust DNS omès. Mantén un inventari i prova les funcions reals després de recuperar el servei.

L’exercici valida una còpia independent dels fitxers seleccionats. Una aplicació completa necessita inventari i proves propis.

Fonts oficials

  1. Document 1: ubuntu.com
  2. Document 2: www.gnu.org
  3. Document 3: www.gnu.org
  4. Document 4: man.openbsd.org

Guies relacionades