Kopia zapasowa VPS Ubuntu: sprawdź, czy odzyskasz pliki
Kopia zapasowa VPS Ubuntu jest użyteczna dopiero wtedy, gdy pozwala odzyskać potrzebne dane. Ten test pokazuje archiwizację dwóch plików statycznej strony, przeniesienie kopii poza VPS i sprawdzenie odtworzonej treści. Nie jest kopią całego serwera ani aktywnej bazy danych.
Spis treści
Przygotuj oddzielne miejsce ćwiczenia
Potrzebujesz Bash, GNU tar, sha256sum i OpenSSH: na przykład Ubuntu, Linux albo WSL. Zachowaj dwa terminale przez całe ćwiczenie: jeden na serwerze, drugi na swoim komputerze. Zmienne ustawione w jednej sesji nie przechodzą do innej. Po błędzie zatrzymaj się i wyjaśnij przyczynę.
Pracujemy w katalogach tymczasowych użytkownika. Przykład nie zmienia działającego Nginx, zapory ani danych witryny i nie rozpakowuje archiwum do katalogu głównego. Dla rzeczywistej strony spisz dodatkowe pliki, zależności, DNS i potrzebne usługi.
Utwórz dwa pliki testowe
W terminalu serwera wykonaj poniższy blok. Tworzy stronę oraz przykładowy plik konfiguracji Nginx w prywatnym katalogu ćwiczenia.
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="pl"><title>Próba odtwarzania</title><h1>Odtworzona strona statyczna</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 'Katalog ćwiczenia: %s\n' "$backup_lab"Konfiguracja jest materiałem do archiwizacji: nie włączamy jej w Nginx. Jeśli używasz danych testowych, pomiń następny blok.
Opcjonalnie możesz skopiować dwa rzeczywiste pliki z instrukcji pierwszego wdrożenia. Najpierw sprawdź ich ścieżki i czytelność oraz obecność poufnych danych. Wstrzymaj publikację na czas kopiowania spójnego wydania. Ten blok podmienia kopie w ćwiczeniu, nie pliki źródłowe.
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"Nie obejmuje to kluczy prywatnych TLS ani całych katalogów systemowych. Rozbudowaną stronę trzeba uzupełnić o jej zasoby i odpowiedni wykaz plików.
Zbuduj archiwum i sumy kontrolne
Pozostając w tej samej sesji serwera, utwórz archiwum ze względnymi ścieżkami, listą plików i sumami kontrolnymi.
(
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 'Katalog eksportu na serwerze: %s\n' "$backup_lab/export"Sprawdź listę: powinny być na niej dwa pliki ćwiczenia oraz manifest sum. Zapisz wypisany katalog eksportu. Suma archiwum wykrywa zmianę bajtów, a manifest pozwala sprawdzić pliki po rozpakowaniu.
Sumy kontrolne same nie potwierdzają pochodzenia. Jeśli ktoś podmieni archiwum i odpowiadającą mu sumę, samo porównanie tego nie wykryje. Chroń dostęp i źródło kopii.
Przenieś kopię poza VPS
Teraz użyj terminalu własnego komputera. Zastąp adres, użytkownika, klucz oraz remote_backup dokładną ścieżką wypisaną na serwerze. Wartość REPLACE to miejsce na tę ścieżkę, nie gotowa nazwa katalogu.
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/"Przy pierwszym połączeniu zweryfikuj klucz hosta zaufanym kanałem. Jeśli przesyłanie nie działa, użyj diagnostyki SSH.
SCP szyfruje transport. Archiwum tar.gz jest skompresowane, lecz nie jest przez to zaszyfrowane na dysku. Ogranicz dostęp do kopii i zastosuj ochronę odpowiednią do danych. Drugi katalog na tym samym VPS nie stanowi niezależnego miejsca odtworzenia.
Zweryfikuj i odtwórz do pustego katalogu
W tej samej lokalnej sesji sprawdź pobrane archiwum. Oczekuj wyniku OK, zanim przejdziesz dalej.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Nie zastępuj oczekiwanej sumy nową tylko dlatego, że kontrola nie przeszła. Wyjaśnij błąd przesyłania lub zmianę źródła. Poprawne archiwum z zaufanego źródła odtwórz w nowym pustym katalogu, bez 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"Opcje ograniczają nadpisywanie plików i odtwarzanie właściciela. Oczekuj dwóch wyników OK dla plików i nagłówka odtworzonej strony. Sprawdza to treść ćwiczenia, nie uprawnienia ACL, działające usługi ani komplet zależności.
Oddziel odzyskane pliki od odzyskanej usługi
Odtworzony plik Nginx nadal nie jest aktywną konfiguracją. Na oddzielnym serwerze docelowym sprawdź ścieżki, moduły, include, uprawnienia i certyfikaty. Dopiero tam wykonaj test konfiguracji przed przeładowaniem oraz sprawdź HTTPS z zewnątrz.
Test nginx -t na starym serwerze nie dowodzi, że nowy potrafi obsłużyć odtworzoną stronę. Klucze prywatne TLS nie są częścią tego ćwiczenia: potrzebują osobnej chronionej kopii albo ponownego wystawienia certyfikatu.
Aktywna baza wymaga własnej spójnej metody kopii i odtwarzania. Snapshot może pomóc, ale trzeba sprawdzić zależność od konta i platformy, retencję, spójność i odtworzenie. Samo istnienie snapshotu nie potwierdza niezależnej kopii.
Ustal dopuszczalną utratę danych i czas odzyskania
RPO opisuje dopuszczalny okres utraty danych, a RTO docelowy czas przywrócenia usługi. Przykład 24 godziny i 60 minut to cele do ustalenia, nie zmierzone wyniki tego poradnika. Codzienny harmonogram ma sens tylko wtedy, gdy zadania kończą się poprawnie i kopie dają się odtworzyć.
Zapisz czas kopii, wersję aplikacji, miejsce poza VPS, retencję, wyniki kontroli oraz przebieg próby. Zanotuj brakujące pliki, zależności i czas poszczególnych kroków.
Pełny test obejmuje utworzenie maszyny, dostęp, pakiety, dane, certyfikat, DNS i zewnętrzny test HTTPS. Szybkie rozpakowanie archiwum nie mierzy czasu usunięcia całej awarii. Powiąż plan z procedurą wdrożenia i uwzględnij niezależny magazyn w koszcie utrzymania.
Pytania i odpowiedzi
Czy skopiowanie plików oznacza odtworzenie całego VPS?
Nie. Ten test obejmuje dwa pliki statycznej strony. System, usługi, baza, uprawnienia, DNS i certyfikaty wymagają osobnego planu.
Czy tar.gz chroni poufność kopii?
Nie. Kompresja nie jest szyfrowaniem. SCP zabezpiecza przesyłanie, ale pliki przechowywane po obu stronach potrzebują odpowiedniej kontroli dostępu i ochrony.
Jak często sprawdzać odtwarzanie?
Ustal harmonogram zgodny z ryzykiem, retencją i celami odzyskania. Powtórz próbę po ważnej zmianie aplikacji, danych lub sposobu wykonywania kopii.