Daftar isi
Tentukan batas latihanSiapkan dua file tanpa mengubah situsBuat arsip dan checksum pada dua tingkatSalin ke komputer lain melalui SSHVerifikasi sebelum ekstraksi ke direktori kosongPisahkan pemulihan file dan layananCatat tujuan dan hasil pemulihanTentukan batas latihan
Gunakan Bash, GNU tar, sha256sum, dan OpenSSH pada Ubuntu atau client Linux/WSL. Jalankan perintah server dalam satu terminal server dan perintah client dalam satu terminal komputer terpisah. Pertahankan kedua terminal agar variabel tersedia. Berhenti setelah error perintah.
Dua file latihan berada di direktori home. Latihan tidak mengubah Nginx, firewall, atau konten aktif; ekstraksi tidak dijalankan sebagai root. Mulai dengan file contoh, lalu gunakan pilihan pengganti hanya untuk dua file dari publikasi statis HTTPS. Ini bukan backup penuh mesin atau aplikasi.
Siapkan dua file tanpa mengubah situs
Pada server, buat direktori latihan privat. Konfigurasi berikut hanya untuk diarsipkan, tidak diaktifkan sebagai layanan.
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="id"><title>Latihan pemulihan</title><h1>Halaman statis yang dipulihkan</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 'Direktori latihan: %s\n' "$backup_lab"Opsional: untuk menyalin halaman serta server block asli dari tutorial, gantikan hanya salinan latihan memakai perintah berikut. Keduanya harus dapat dibaca akun Anda. Periksa rahasia dalam konfigurasi dan hentikan deployment sementara agar file berasal dari rilis yang sama. Lewati blok ini untuk latihan file contoh.
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"Sumber aktif hanya dibaca, tidak diubah. Private key sertifikat dan seluruh direktori sistem tidak disalin. Situs sebenarnya dapat memerlukan file tambahan; masukkan secara sengaja ke inventaris dan manifest checksum.
Buat arsip dan checksum pada dua tingkat
Pada server, catat checksum file terpilih, buat arsip dengan path relatif, lalu hitung checksum arsip. Jangan mengubah payload selama proses.
(
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 'Direktori ekspor server: %s\n' "$backup_lab/export"Daftar harus berisi site/, nginx/, dua file terpilih, dan SHA256SUMS. Checksum arsip mendeteksi perubahan saat penyalinan; manifest internal memeriksa file hasil ekstraksi. Keduanya tidak mengautentikasi backup bila seseorang dapat mengganti data sekaligus checksum yang diharapkan.
Salin ke komputer lain melalui SSH
Pada client, isi remote_backup dengan direktori export persis seperti yang dicetak server. Sesuaikan IP, akun, dan nama private key. 203.0.113.10 adalah IP dokumentasi; REPLACE harus diganti suffix sebenarnya dari 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/"Verifikasi fingerprint host melalui jalur terpercaya sebelum menerima host baru. Jika SSH gagal, ikuti pemeriksaan koneksi; jangan mematikan pengecekan host key.
SCP melindungi transfer melalui SSH. Arsip tar.gz dikompresi, bukan dienkripsi. Lindungi akun dan media tujuan serta gunakan enkripsi penyimpanan bila data memerlukannya. Folder kedua pada VPS yang sama bukan salinan di luar server.
Verifikasi sebelum ekstraksi ke direktori kosong
Pada client, periksa arsip terlebih dahulu. Lanjutkan hanya bila sha256sum menampilkan OK. Selidiki kegagalan atau salin ulang; jangan mengganti checksum yang diharapkan hanya agar pemeriksaan lolos.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Ekstrak arsip terpercaya ini ke direktori baru. --keep-old-files menolak mengganti file lama dan --no-same-owner tidak memulihkan ownership arsip. Jangan mengganti tujuan menjadi / atau memakai 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"Harapkan OK untuk site/index.html dan nginx/first-site.conf serta judul halaman hasil pemulihan. Ini memverifikasi isi file, bukan ownership produksi, ACL, ketersediaan layanan, atau semua dependensi situs.
Pisahkan pemulihan file dan layanan
Konfigurasi yang diekstrak masih file teks tidak aktif. Pada server pengganti terpisah, periksa path, include, modul, izin, serta sertifikat. Validasi konfigurasi Nginx gabungan di sana sebelum reload, lalu uji HTTP/HTTPS dari luar. Tes konfigurasi server aktif lama tidak memvalidasi salinan yang dipulihkan.
Arsip sengaja tidak mencakup private key TLS. Rencanakan penerbitan ulang sertifikat atau backup sertifikat yang terlindungi secara terpisah. Jangan menyalin file database aktif dengan resep tar ini; gunakan metode backup konsisten dan restore yang didukung database.
Periksa retensi snapshot penyedia, lokasi kegagalan yang dapat ditahan, dan prosedur restore. Snapshot tersedia belum membuktikan file ekspor bisa dipulihkan pada host pengganti.
Catat tujuan dan hasil pemulihan
RPO adalah toleransi kehilangan data dalam satuan waktu; RTO adalah target waktu pemulihan layanan. Contoh untuk situs informasi statis: RPO 24 jam dan RTO 60 menit. Itu target bisnis ilustratif, bukan hasil latihan yang diukur. Backup harian memenuhi rencana hanya bila salinan berhasil dan tetap dapat dipulihkan.
Geser tabel ke samping untuk melihat semua kolom.
| Catatan | Yang dibuktikan |
|---|---|
| Waktu backup dan ID rilis | Versi yang dapat dipulihkan |
| Tujuan terpisah dan retensi | Lokasi serta umur salinan |
| Hasil checksum arsip/file | Isi yang berhasil dikembalikan |
| Waktu mulai dan selesai restore | Durasi pekerjaan yang didefinisikan |
| File, izin, atau dependensi yang kurang | Pekerjaan sebelum layanan kembali |
| HTTPS eksternal pada pengganti | Situs benar-benar tersedia kembali |
Ukur proses lengkap: akses, provisioning, konfigurasi, sertifikat, dan DNS bila dibutuhkan. Ekstraksi lokal cepat bukan benchmark pemulihan gangguan. Simpan beberapa titik pemulihan dan periksa job backup gagal. Sertakan retensi serta bantuan restore dalam pemilihan VPS.
Alur arsip file contoh dan checksum diuji lokal dengan GNU tools di Git Bash pada Windows. Uji itu tidak mencakup server Ubuntu, transfer SSH jarak jauh, pemulihan sertifikat, atau aktivasi Nginx.
Pertanyaan umum
Perlukah situs asli dihapus untuk menguji backup?
Tidak. Pulihkan ke direktori kosong terpisah dan periksa manifest. Uji layanan lengkap pada lingkungan pengganti tanpa menyebabkan gangguan situs asli.
Apakah checksum berhasil berarti seluruh situs sudah dibackup?
Checksum hanya memeriksa file dalam manifest. Aset, database, rahasia, atau DNS yang tidak dicatat tidak terdeteksi. Pertahankan inventaris dan uji fungsi aplikasi.
Apakah snapshot saja cukup?
Periksa retensi, lokasi penyimpanan, dan hasil pemulihan. Salinan independen menguji jalur pemulihan lain.