Snapshot, Backup, atau Clone VPS: Apa Bedanya?

Apa sebenarnya snapshot, backup, dan clone

Snapshot VPS adalah image disk server Anda yang disimpan oleh provider, pada infrastruktur provider, di dalam akun Anda. Backup adalah salinan data yang independen dan dapat dipulihkan di tempat lain tanpa bantuan provider yang menyimpan data asli. Clone adalah instance baru yang dibuat dari snapshot. Karena itu, clone dimulai sebagai salinan persis dari instance asli, termasuk identitasnya.

Ketiganya menyelesaikan masalah yang berbeda. Snapshot dapat mengembalikan sistem ke kondisi sebelum upgrade yang gagal dalam hitungan menit, tetapi snapshot tidak berguna jika akun Anda ditutup. Backup tetap tersedia meskipun provider tidak lagi beroperasi. Namun, pemulihannya memerlukan waktu lebih lama karena Anda harus membuat ulang mesin terlebih dahulu. Clone memberi Anda server kedua yang berjalan dalam satu langkah. Clone juga menghasilkan dua mesin yang menganggap dirinya sebagai mesin yang sama.

Mengapa snapshot VPS bukan backup

Masalahnya terletak pada domain kegagalan, bukan pada kualitas image. Snapshot berada di platform penyimpanan milik provider, biasanya di region yang sama dengan server asalnya, dan selalu di dalam account yang sama. Satu kejadian dapat membuat server dan snapshot-nya hilang sekaligus.

• Account ditangguhkan, pembayaran gagal, atau seseorang mencuri kredensial login.
• Seseorang atau script yang memiliki akses API menghapus instance. Pada banyak provider, penghapusan instance juga menghapus snapshot-nya. Baca perilaku yang didokumentasikan provider sebelum berasumsi sebaliknya.
• Region mengalami gangguan, sehingga semua resource di dalamnya tidak dapat diakses secara bersamaan.
• Sesuatu yang berjalan sebagai root di server menemukan token API provider yang Anda tinggalkan di /root, lalu menghapus snapshot sebelum menyentuh disk.

Backup adalah salinan yang tetap bertahan dari keempat kejadian tersebut. Pengujiannya hanya satu pertanyaan: jika account provider Anda berhenti ada sore ini, apa yang masih dapat Anda restore, dan di mana Anda akan me-restore-nya? Apa pun yang gagal menjawab pertanyaan tersebut adalah alat rollback. Tetap buat snapshot karena tidak ada yang dapat dipulihkan lebih cepat. Kemudian simpan salinan kedua pada storage yang tidak dikendalikan provider.

Aturan lama tetap berlaku: tiga salinan data, pada dua jenis storage, dan salah satunya berada di luar platform. Snapshot provider ditambah repository backup restic pada infrastruktur terpisah memenuhi aturan tersebut dengan dua komponen yang perlu dikelola.

Mengapa snapshot database yang sedang berjalan dapat dipulihkan dalam kondisi rusak

Snapshot dari provider menyalin block device sesuai keadaannya pada satu waktu tertentu. Snapshot tidak meminta aplikasi berhenti terlebih dahulu dan tidak dapat melihat data yang masih berada di page cache. Jadi, paling baik, image tersebut hanya konsisten terhadap kerusakan akibat crash. Kondisinya sama persis seperti jika seseorang mencabut kabel daya dari server.

Sebagian besar stack dapat menangani kondisi ini. ext4 dan XFS memutar ulang journal saat mount, sehingga filesystem dapat digunakan. PostgreSQL memutar ulang write-ahead log saat start, dan log menampilkan pesan berikut:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB melakukan hal yang sama dan menampilkan baris crash recovery saat startup. Proses recovery tersebut merupakan perilaku database yang sesuai desain. Karena itu, snapshot satu volume dari PostgreSQL atau MySQL yang tidak sedang sibuk biasanya dapat dipulihkan dengan baik.

Namun, ada kondisi ketika konsistensi terhadap crash tidak cukup. Kondisi ini nyata dan dapat menimbulkan masalah serius. Jika data Anda tersebar pada dua volume, root disk dan data disk terpisah di-snapshot pada waktu yang berbeda. Akibatnya, file data dan direktori log dapat tidak sinkron, sehingga recovery tidak memiliki data yang benar untuk diputar ulang. File apa pun yang ditulis aplikasi tanpa memanggil fsync, seperti upload yang baru diterima sebagian atau file antrean, dapat dipulihkan dalam kondisi terpotong. Data apa pun yang disimpan aplikasi di memori dan ditulis ke disk berdasarkan timer tidak akan masuk ke dalam image.

Karena itu, tulis dump ke disk sebelum mengambil snapshot. Dengan demikian, image berisi satu file yang Anda ketahui konsisten secara internal, terlepas dari kondisi file data aktif.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction menghasilkan dump tabel InnoDB yang konsisten tanpa memblokir proses penulisan, karena dump berjalan dalam satu transaksi repeatable-read. Fitur ini tidak mencakup tabel MyISAM, yang memerlukan lock atau server yang dihentikan. Periksa bahwa dump tidak kosong dan tidak terpotong sebelum mempercayainya: tail -n 1 /var/backups/mysql-$(date +%F).sql pada mysqldump yang lengkap diakhiri dengan komentar Dump completed.

Jika Anda memiliki data volume terpisah, Anda dapat membekukannya selama beberapa detik yang diperlukan snapshot:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

Bekukan data volume saja. Jangan pernah membekukan /. Root filesystem yang dibekukan akan memblokir setiap penulisan pada server, termasuk shell yang akan Anda gunakan untuk mengetikkan perintah unfreeze. Akibatnya, Anda akan kehilangan akses ke server dan harus menunggu hard reset.

Bagian offsite: restic atau Borg

Snapshot adalah bagian yang cepat. Salinan offsite adalah bagian yang tetap tersedia meskipun provider Anda bermasalah. restic merupakan pilihan default yang baik karena melakukan deduplikasi, mengenkripsi data di sisi klien, dan menulis ke object storage yang kompatibel dengan S3, SFTP, atau direktori biasa. Storage VPS sebagai target offsite cocok untuk kebutuhan ini karena repository backup memerlukan kapasitas, bukan IOPS.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

Salin passphrase tersebut ke password manager sekarang, pada perangkat yang bukan server ini. Repository restic tidak dapat dibuka tanpa passphrase tersebut dan tidak ada jalur pemulihan. Jika satu-satunya salinan password berada di server yang baru saja hilang, backup tersebut hanya berupa data terenkripsi yang tidak dapat digunakan.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E mempertahankan variabel tersebut. Tanpanya, root mendapatkan environment yang bersih dan restic melaporkan bahwa lokasi repository belum ditentukan. restic snapshots harus menampilkan proses yang baru saja Anda jalankan, beserta host dan path-nya. Verifikasi repository itu sendiri secara berkala, lalu baca sebagian data untuk memastikannya dapat dipulihkan, bukan hanya memeriksa strukturnya:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Backup yang belum pernah diuji hanyalah perkiraan. Pulihkan backup ke VPS yang berbeda setidaknya satu kali, ukur waktunya, lalu catat hasilnya karena angka tersebut adalah target pemulihan Anda yang sebenarnya. Borg adalah pilihan andal lainnya dan menyimpan repository melalui SSH, bukan object storage. Perbandingan trade-off keduanya dibahas dalam perbandingan restic dan BorgBackup.

Hal yang harus diperbaiki sebelum VPS hasil kloning digunakan di lingkungan produksi

Klon adalah replika yang identik. Di situlah manfaat sekaligus masalahnya. Semua hal yang membuat sistem asli unik ikut diduplikasi, dan duplikasi tersebut dapat saling berbenturan.

Buat ulang kunci host SSH. Klon membawa file /etc/ssh/ssh_host_* milik sistem asli, sehingga dua server menampilkan identitas host yang sama. Siapa pun yang mengendalikan salah satunya dapat menyamar sebagai server lainnya di hadapan setiap klien yang telah menerima kunci tersebut. SSH tidak menampilkan peringatan karena kunci itu sesuai dengan kunci yang diharapkan klien.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A menulis kunci baru untuk setiap jenis kunci yang diperlukan daemon. Fingerprint dari perintah terakhir harus berbeda dari fingerprint pada sistem asli. Sesi Anda saat ini tetap berjalan karena me-restart sshd tidak menutup koneksi yang sudah terbentuk. Lakukan ini sebelum ada pihak yang terhubung ke klon. Jika ditunda, setiap klien yang sudah memercayai kunci bawaan tersebut akan menerima WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! dan harus menjalankan ssh-keygen -R <host> terlebih dahulu.

Reset machine ID. /etc/machine-id adalah pengenal unik yang dibuat systemd sekali, saat boot pertama, dan diwarisi oleh klon.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

/etc/machine-id yang kosong memberi tahu systemd untuk membuat nilai baru pada boot berikutnya. Karena itu, kosongkan file tersebut alih-alih menghapusnya. Duplikasi machine ID menyebabkan dua masalah. Pada image yang memperoleh alamat melalui DHCP, systemd-networkd secara default membuat DHCP client identifier dari machine ID. Akibatnya, kedua klon meminta lease sebagai klien yang sama dan server memberikan alamat yang sama kepada keduanya. Selain itu, journald menandai setiap entri dengan machine ID. Collector log terpusat kemudian mencatat kedua server sebagai satu mesin. Jalankan cat /etc/machine-id setelah reboot dan pastikan nilainya berubah.

Ubah hostname.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl menulis /etc/hostname dan langsung menerapkan nama tersebut. Perintah ini tidak mengubah /etc/hosts, jadi edit baris 127.0.1.1 agar sesuai. Jika langkah ini dilewati, nama baru tidak dapat di-resolve. Akibatnya, setiap panggilan sudo menunggu lookup yang gagal dan menampilkan sudo: unable to resolve host web-02: Name or service not known.

Ganti setiap kredensial yang tertanam di dalam image. Klon menyimpan secret milik sistem asli, dan kini dua mesin dapat bertindak sebagai sistem asli. Periksa file authorized_keys SSH, token API provider dan DNS, file .env aplikasi, password database, private key TLS, token pendaftaran monitoring, serta password repository restic. Perintah ini menemukan sebagian besar kredensial tersebut:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

Jika klon hanya digunakan untuk pengujian dan tidak akan melayani trafik, cabut kredensial alih-alih menggantinya. Server staging yang menyimpan token API produksi aktif pada dasarnya adalah server produksi dengan proses patching yang lebih buruk.

Matikan job yang kini berjalan dua kali. Dua server dengan crontab yang sama akan mengakses sistem eksternal yang sama pada menit yang sama.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

Kasus restic perlu dijelaskan karena masalahnya dapat merusak retensi, bukan sekadar gagal dengan jelas. restic memberi tag nama host pada setiap snapshot, dan restic forget --keep-daily 7 menerapkan kebijakannya per host. Dua mesin yang melaporkan nama host yang sama diperlakukan sebagai satu host. Akibatnya, tujuh snapshot "harian" dapat semuanya berasal dari klon, sementara snapshot sistem asli dihapus. Perbaiki hostname sebelum backup pertama dijalankan, atau hentikan timer pada klon. Kasus certbot lebih sederhana: dua server yang memperbarui nama yang sama akan mencapai batas laju sertifikat duplikat dari certificate authority. Proses yang kalah gagal dengan error yang menyatakan bahwa terlalu banyak sertifikat telah diterbitkan untuk kumpulan nama yang persis sama. Klon yang domainnya masih mengarah ke sistem asli juga tidak dapat melewati HTTP challenge. Karena itu, nonaktifkan pembaruan pada klon.

Tangani agent monitoring. Sebagian besar agent menggunakan hostname atau file ID yang ditulis saat instalasi sebagai identitas. Akibatnya, dua agent yang melaporkan satu host akan mencampurkan metriknya ke dalam satu rangkaian data. Grafik CPU kemudian menampilkan nilai yang tidak pernah dihasilkan oleh satu mesin pun, dan alert menjadi tidak stabil. Hentikan dan hapus agent pada klon, atau daftarkan ulang agent dengan hostname baru menggunakan prosedur yang didokumentasikan oleh vendor Anda.

Periksa konfigurasi jaringan untuk alamat sistem asli. Jika image menyimpan alamat statis dalam netplan, klon akan menggunakan IP yang dimiliki mesin lain.

ip -br addr
sudo grep -r addresses /etc/netplan/

Hapus state cloud-init jika klon ini akan dijadikan template.

sudo cloud-init clean --logs

Perintah tersebut menghapus state cloud-init di bawah /var/lib/cloud. Dengan demikian, boot berikutnya menjalankan kembali modul first-boot, termasuk membuat kunci host SSH jika kunci tersebut belum ada. Beberapa versi juga menyediakan flag untuk mereset machine ID. Jalankan cloud-init clean --help pada image Anda sendiri untuk melihat opsi yang didukung, alih-alih mengandalkan daftar flag dari sumber lain.

Kapan menggunakan yang mana

Membatalkan upgrade yang berisiko: buat snapshot. Buat snapshot beberapa menit sebelum perubahan, jalankan upgrade, lalu pulihkan image jika terjadi masalah. Pemulihan akan membuang semua penulisan sejak snapshot dibuat. Jadi, pada server yang menangani trafik aktif, lakukan dump database terlebih dahulu dan tentukan dengan jelas rentang waktu data yang akan hilang. Untuk do-release-upgrade pada server yang dapat dibuat offline selama sepuluh menit, snapshot sudah mencakup seluruh rencana.

Bermigrasi ke plan yang lebih besar: deploy clone. Buat clone dari snapshot ke plan yang lebih besar, periksa seluruh daftar identitas di atas, lalu uji clone tersebut pada IP-nya sendiri sebelum memindahkan trafik apa pun. Turunkan TTL DNS sehari sebelumnya agar cutover berlangsung cepat, dan biarkan server asli tetap berjalan sampai server baru menangani trafik nyata. Pastikan terlebih dahulu bahwa plan yang lebih besar memang lebih cepat untuk beban kerja Anda dengan menggunakan metode benchmark yang sama pada kedua server, karena lebih banyak vCPU pada hardware yang lebih sibuk tidak selalu berarti upgrade.

Membuat template: buat snapshot dari mesin yang sudah dibersihkan. Install dan perkuat keamanan satu server, lalu hapus semua hal yang bersifat unik sebelum membuat image. Jangan sertakan host keys, kosongkan machine ID, hapus authorized_keys pribadi, hapus kredensial, dan bersihkan cloud-init. Setelah itu, buat snapshot. Setiap instance yang di-deploy dari snapshot tersebut akan membuat identitasnya sendiri pada boot pertama. Dengan demikian, checklist di atas tidak perlu lagi dijalankan sebagai checklist. Padukan dengan sepuluh menit pertama standar pada VPS baru agar template sudah berisi pekerjaan yang biasanya harus Anda ulangi.

FAQ

Apakah snapshot VPS merupakan backup?

Tidak, karena snapshot berbagi domain kegagalan dengan server asalnya. Snapshot tersimpan pada storage milik provider, di akun Anda, dan biasanya di region yang sama. Penangguhan akun, pencurian API key, atau penghapusan instance secara tidak sengaja dapat menghapus server dan snapshot-nya dalam satu tindakan. Pada banyak provider, penghapusan instance memang secara desain turut menghapus snapshot-nya. Snapshot adalah rollback tercepat yang Anda miliki. Karena itu, tetap buat snapshot secara berkala dan simpan salinan terenkripsi kedua pada infrastruktur yang tidak dikendalikan oleh provider Anda.

Apakah saya perlu menghentikan database sebelum membuat snapshot?

Tidak selalu, tetapi Anda perlu memahami hasilnya. Snapshot dari provider bersifat crash-consistent. Artinya, image tersebut sesuai dengan kondisi disk setelah listrik terputus. PostgreSQL dan InnoDB dapat memulihkan kondisi tersebut saat start, dan PostgreSQL mencatat log database system was not properly shut down; automatic recovery in progress selama prosesnya. Pemulihan tidak dijamin jika data Anda tersebar pada dua volume yang dibuat snapshot pada waktu berbeda, atau jika aplikasi menulis tanpa fsync. Tulis pg_dumpall atau mysqldump --single-transaction ke disk terlebih dahulu agar image memuat satu file yang Anda ketahui konsisten.

Mengapa dua server hasil clone menggunakan alamat IP yang sama?

Karena keduanya berbagi /etc/machine-id. Pada image yang menggunakan DHCP, systemd-networkd secara default membuat identifier klien DHCP dari machine ID. Akibatnya, kedua clone meminta lease sebagai klien yang sama dan server DHCP menawarkan alamat yang sama kepada keduanya. Potong /etc/machine-id hingga berukuran 0 byte, hapus /var/lib/dbus/machine-id, buat symbolic link kembali ke /etc/machine-id, lalu reboot agar systemd membuat nilai baru. Penyebab umum lainnya adalah alamat statis yang ditulis dalam /etc/netplan/ dan disalin oleh clone tanpa perubahan. Periksa dengan ip -br addr.

Apa cara tercepat untuk memastikan clone aman ditempatkan di production?

Bandingkan empat hal dengan server asli. Jalankan ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub pada keduanya dan pastikan fingerprint berbeda. Jalankan cat /etc/machine-id pada keduanya dan pastikan nilainya berbeda. Jalankan hostnamectl status dan pastikan namanya baru serta dapat di-resolve, sehingga sudo tidak memberikan peringatan. Kemudian jalankan systemctl list-timers --all dan hentikan setiap timer yang berkomunikasi dengan sistem bersama, seperti backup, pembaruan sertifikat, atau agent monitoring, hingga Anda menentukan mesin mana yang bertanggung jawab atas tugas tersebut.