VPS-rugsteun en herstel van statiese lêers
’n Rugsteun is bruikbaar wanneer jy dit buite die VPS kan kry en die verwagte lêers kan herstel. Hierdie oefening argiveer ’n statiese bladsy en een Nginx-konfigurasie, kopieer dit na ’n ander rekenaar en verifieer die herstelde grepe sonder om die werkende webwerf te raak.
VPSuntu · Bygewerk: · Leestyd: sowat 5 min
In hierdie gids
Baken die klein oefening af
Gebruik Bash, GNU tar, sha256sum en OpenSSH op Ubuntu of ’n Linux/WSL-kliënt. Bedieneropdragte loop in een bedienerterminaal; kliëntopdragte in een terminaal op ’n aparte rekenaar. Hou albei oop sodat veranderlikes beskikbaar bly. Stop ná enige opdragfout.
Die oefening gebruik twee tydelike lêers onder jou tuisgids. Dit verander nie Nginx, brandmure of lewende inhoud nie en onttrek nooit as root nie. Begin met die toetslêers. Die opsionele vervanging gebruik net die twee lêers van die statiese HTTPS-gids.
Maak vir ’n groter webwerf ’n aparte inventaris van bates, herleidings, ingeslote konfigurasie, DNS en afhanklikhede. Twee lêers is nie ’n volledige masjien- of toepassingsrugsteun nie.
Berei twee lêers voor sonder om die webwerf te verander
Skep op die bediener ’n private oefengids. Die konfigurasie hieronder is ’n lêer om te argiveer, nie ’n diens om te aktiveer nie.
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"Opsioneel: vervang net die tydelike kopieë met die gids se werklike bladsy en server block. Jou rekening moet albei bronne kan lees. Inspekteer eers vir geheime en onderbreek ontplooiings tydens versameling sodat die lêers dieselfde weergawe verteenwoordig. Slaan hierdie blok vir die toetslêeroefening oor.
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"Hierdie opdragte lees die lewende bronne sonder om hulle te verander. Hulle kopieer nie private TLS-sleutels of hele stelselgidse nie. Voeg bykomende nodige lêers doelbewus by die inventaris én checksum-manifes.
Skep die argief en twee vlakke van kontrole
Bereken op die bediener die lêers se checksums, skep ’n argief met relatiewe paaie en bereken sy checksum. Hou die inhoud tydens dié stap onveranderd.
(
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"Die lys moet site/, nginx/, die twee gekose lêers en SHA256SUMS bevat. Die argief-checksum bespeur oordragveranderinge; die interne manifes toets onttrekte lêers. Geen checksum verifieer egtheid as iemand data én die verwagte checksum kan vervang nie.
Kopieer na ’n aparte rekenaar
Stel op die kliënt remote_backup op die presiese uitvoergids wat die bediener gedruk het. Vervang adres, rekening en sleutellêer met werkende SSH-besonderhede. 203.0.113.10 is ’n dokumentasieadres; REPLACE is ’n plekhouer, nie mktemp se gegenereerde agtervoegsel nie.
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/"Verifieer ’n nuwe host key via ’n vertroude kanaal. By SSH-foute gebruik die verbindingsgids; moenie sleutelkontrole afskakel om die kopie te laat slaag nie.
SCP beskerm oordrag met SSH. Die tar.gz-lêer is saamgepers, nie geënkripteer nie. Beskerm die bestemmingsrekening en berging en gebruik enkripsie in rus wanneer nodig. ’n Tweede gids op dieselfde VPS is nie ’n onafhanklike kopie nie.
Verifieer en herstel in ’n nuwe leë gids
Kontroleer die argief op die kliënt vóór onttrekking. Gaan net voort as sha256sum OK gee. ’n Fout vereis ondersoek of nuwe oordrag; moenie die verwagte checksum oorskryf om dit te verberg nie.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Onttrek hierdie vertroude argief in ’n nuutgeskepte gids. keep-old-files weier om bestaande lêers te vervang; no-same-owner herstel nie die argief se eienaarskap nie. Moet nooit die bestemming na / verander of sudo gebruik nie.
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"Verwag OK vir site/index.html en nginx/first-site.conf en die herstelde bladsyopskrif. Dit toets lêerinhoud, nie produksie-eienaarskap, ACL’s, beskikbaarheid of alle afhanklikhede nie.
Skei lêerherstel van diensherstel
Die herstelde konfigurasie is nog onaktiewe teks. Hersien paaie, includes, modules, toestemmings en sertifikate op ’n aparte vervangingsbediener. Valideer daar die volledige Nginx-konfigurasie vóór herlaai en toets HTTP/HTTPS van buite. ’n Toets op ’n onveranderde lewende bediener valideer nie dié kopie nie.
Die argief sluit private TLS-sleutels doelbewus uit. Beplan nuwe sertifikate of ’n aparte beskermde kopie. Moenie ’n aktiewe databasis met hierdie tar-resep kopieer nie; gebruik die databasis se ondersteunde konsekwente rugsteun en herstel.
Snapshots kan met masjienherstel help. Kontroleer bewaring, gedeelde risiko’s by ’n faling en die herstelprosedure. ’n Bestaande snapshot bewys nie dat jou uitgevoerde webwerflêers op ’n vervangingsgasheer herstelbaar is nie.
Teken hersteldoelwitte en resultate aan
RPO is aanvaarbare dataverlies gemeet in tyd; RTO is die beoogde tyd om die diens te herstel. Vir ’n klein statiese inligtingswebwerf kan 24 uur RPO en 60 minute RTO voorbeeldteikens wees. Dit is nie gemete resultate nie. Daaglikse rugsteun voldoen net aan die skedule wanneer kopieë slaag en herstelbaar bly.
Skuif die tabel sywaarts op klein skerms om al die kolomme te sien.
| Rekord | Wat dit aantoon |
|---|---|
| Rugsteuntyd en weergawe-ID | Watter weergawe herstelbaar is |
| Onafhanklike bestemming en bewaring | Waar en hoe lank die kopie behoue bly |
| Argief- en lêerchecksums | Of die gekose grepe herstel is |
| Begin- en eindtyd | Tyd vir die omskrewe herstelstappe |
| Ontbrekende lêers, regte of afhanklikhede | Wat nog nodig is vóór diensherstel |
| Eksterne HTTPS op die vervanging | Of die webwerf werklik terug is |
Meet die hele vervanging vóór jy ’n RTO as haalbaar beskou: toegang, masjienskepping, konfigurasie, sertifikate en DNS waar nodig. Vinnige plaaslike onttrekking is nie ’n benchmark vir herstel ná ’n onderbreking nie. Hou geskikte herstelpunte en ondersoek gefaalde take. Vergelyk bewaring en herstelhulp in die hostingkriteria.
Gereelde vrae
Moet ek die oorspronklike webwerf skrap om die kopie te toets?
Nee. Herstel in ’n aparte leë gids en kontroleer die manifes. Dit toets die lêerkopie sonder ’n onderbreking. Toets die volle diens op ’n aparte vervangingsomgewing.
Bewys ’n korrekte checksum dat die hele webwerf gerugsteun is?
Dit bevestig net die lêers in die manifes. Dit ontdek nie ’n weggelate beeld, databasis, geheim of DNS-instelling nie. Hou ’n inventaris en toets werklike funksies ná diensherstel.