Cara Backup VPS Menggunakan Restic ke Server Luar

Mengapa sandaran pada pelayan yang sama bukanlah sandaran

Restic ialah alat sandaran sumber terbuka percuma yang menghantar snapshot fail anda yang telah disulitkan dan dinyahduplikasi ke repositori di tempat lain: VPS kedua, mesin di rumah, atau storan objek yang serasi dengan S3. Panduan ini menyediakan Restic pada Ubuntu 24.04, bermula daripada pemasangan hingga ke repositori melalui SFTP, sandaran pertama, pemasa systemd harian, polisi pengekalan, dan latihan pemulihan yang membuktikan keseluruhan sistem berfungsi. Destinasi mestilah mesin lain, kerana salinan yang berada pada pelayan yang sama akan musnah bersama pelayan tersebut.

Direktori backup/ pada mesin yang disandarkan hanya melindungi anda daripada satu perkara sahaja: memadam fail secara tidak sengaja. Ia tidak terselamat daripada kegagalan cakera, kerana ia berada pada cakera yang sama. Ia tidak terselamat daripada penyerang yang mempunyai akses root, kerana mereka akan memadam salinan tersebut terlebih dahulu. Ia tidak terselamat daripada kesilapan akaun yang memadamkan VPS itu sendiri. Pusat data paling tidak cekap di dunia bergurau tentang fail tarball bernama backup_final_v2_REAL yang disimpan pada tatasusunan yang sama dengan data asal, dan gurauan itu tepat kerana ramai antara kita pernah melakukan perkara yang sama. Peraturan utamanya ialah data mesti berada di luar pelayan, dan restic adalah cara paling mudah untuk mematuhinya.

Restic dalam empat idea

Repository. Lokasi tempat restic menulis data. Ia merupakan direktori dalam format restic sendiri yang penuh dengan blob terenkripsi, dan hanya restic yang boleh membacanya. Anda tidak boleh menyuntingnya secara manual; anda berinteraksi dengannya melalui arahan restic dan alamat -r.

Snapshot. Gambaran fail yang anda sandarkan pada satu titik masa tertentu. Setiap proses sandaran mencipta satu snapshot, setiap snapshot boleh dipulihkan secara berasingan, dan setiap satunya berfungsi seperti salinan lengkap data anda pada saat tersebut.

Deduplication. Restic memecahkan fail kepada ketulan (chunks) berdasarkan kandungan dan hanya memuat naik ketulan yang belum wujud dalam repository. Sandaran pertama memuat naik segala-galanya; setiap proses selepas itu hanya memuat naik bahagian yang berubah. Snapshot harian bersaiz 20 GB dengan perubahan 50 MB hanya memerlukan ruang sekitar 50 MB, itulah sebabnya menyimpan berpuluh-puluh snapshot adalah murah.

Encryption by default. Repository restic sentiasa terenkripsi (AES-256), dan setiap arahan memerlukan kata laluan repository. Hos sandaran atau penyedia storan hanya melihat blob yang terenkripsi. Kesan tegasnya: jika kata laluan hilang, data akan hilang selama-lamanya, secara sengaja mengikut reka bentuknya. Simpan salinan kata laluan di tempat lain selain pelayan ini. Perkara ini sangat penting sehingga ia disebut dua kali lagi di bawah.

Memasang restic pada Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

Pada Ubuntu 24.04, arahan ini memasang restic versi 0.16.4, manakala keluaran terkini daripada pembangun ialah 0.19.1. Jurang versi ini wujud kerana keluaran LTS (long term support) membekukan versi pakejnya, namun ia tidak menjadi masalah di sini: versi 0.16.4 mampu melaksanakan semua fungsi dalam panduan ini. Jika anda mahukan keluaran terbaharu untuk peningkatan kelajuan, muat turun binaan binari tunggal rasmi daripada halaman GitHub projek restic, nyahzip ia menggunakan bunzip2, dan pasang ke /usr/local/bin/restic; tiada langkah lain yang diperlukan untuk pemasangan restic.

Cipta repositori pada pelayan lain melalui SFTP

Anda memerlukan mesin destinasi: VPS kecil kedua adalah pilihan biasa, dan mana-mana mesin dengan pelayan SSH serta ruang cakera yang mencukupi sudah memadai. Restic menggunakan SFTP (pemindahan fail melalui SSH), jadi hos sandaran tidak memerlukan sebarang perisian dipasang. Dalam panduan ini, hos sandaran ialah 10.0.0.12 dengan pengguna bernama restic. Jangan namakan pengguna tersebut backup: Ubuntu dan Debian menyertakan akaun sistem terpelihara bernama backup (uid 34, tiada shell log masuk) pada setiap pemasangan, jadi adduser backup akan gagal dan ssh backup@... akan berakhir di nologin.

Tugas harian akan dijalankan sebagai root pada pelayan yang disandarkan, jadi root memerlukan log masuk kunci ke hos sandaran. Cipta kunci khusus tanpa frasa laluan, kerana tiada manusia yang akan menaipnya pada pukul 3 pagi, kemudian salin kunci tersebut:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Jika anda baharu dengan kunci, asas pengurusan kunci SSH menerangkan model tersebut, keizinan, dan cara untuk membatalkan kunci pada masa hadapan.

Seterusnya, kata laluan repositori. Jana kata laluan yang kuat ke dalam fail yang hanya boleh diakses oleh root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Sekarang salin kata laluan tersebut ke dalam pengurus kata laluan anda sebelum meneruskan. Jika VPS ini rosak, repositori berserta kata laluan ini membolehkan anda memulihkan segala-galanya; repositori tanpa kata laluan tidak akan memulihkan apa-apa.

Mulakan repositori:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Destinasi alternatif ialah storan objek yang serasi dengan S3, yang merupakan pilihan tepat apabila anda tidak mahu mengendalikan mesin kedua. Mana-mana bucket yang serasi dengan S3 berfungsi dengan cara yang sama; hanya alamat dan dua pemboleh ubah kelayakan yang berubah:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Segala-galanya selepas init adalah sama untuk kedua-dua destinasi. Selebihnya panduan ini menunjukkan alamat SFTP; gantikan dengan alamat anda sendiri.

Sandaran pertama, dengan pengecualian

Sandarkan data yang tidak boleh dipasang semula, bukan keseluruhan sistem fail. Sistem pengendalian akan kembali dengan pemasangan semula; konfigurasi dan data anda tidak. Bagi VPS biasa, ini bermakna /etc, /home, dan di mana-mana sahaja aplikasi anda menyimpan status, seperti /srv atau /var/www. Kecualikan cache, kerana ia bersaiz besar, berubah setiap hari, dan boleh dibina semula secara automatik:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

Jalankan kali pertama akan memuat naik segala-galanya, jadi ia mengambil sedikit masa. Jalankan arahan yang sama sekali lagi dan ia selesai dalam beberapa saat, melaporkan beberapa fail yang berubah dan beberapa MiB yang ditambah, kerana penyahduplikasian hanya memuat naik ketulan data baharu. Senaraikan apa yang anda ada:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Setiap snapshot menunjukkan ID, masa, dan laluan yang terkandung di dalamnya. ID tersebut adalah perkara yang anda gunakan untuk memulihkan data.

Jalankan tugasan malam dengan systemd timer

Menaip alamat repositori pada setiap arahan akan menjadi leceh, dan sandaran yang dijalankan secara manual akan berhenti dilakukan dalam masa sebulan. Kedua-dua masalah ini selesai dengan satu skrip dan satu timer. Skrip tersebut menetapkan dua pemboleh ubah persekitaran yang dibaca oleh restic, RESTIC_REPOSITORY dan RESTIC_PASSWORD_FILE, supaya setiap arahan di dalamnya kekal ringkas:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Baris forget dan check diterangkan dalam dua bahagian seterusnya. Sekarang untuk jadual: satu servis oneshot yang menjalankan skrip tersebut, dan satu timer yang mencetuskannya pada pukul 03:00 setiap malam. Timer lebih baik daripada baris cron di sini kerana ia mencatat log ke dalam journal, dan Persistent=true akan menjalankan sandaran yang terlepas sebaik sahaja pelayan kembali aktif selepas tempoh henti.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Aktifkan timer, kemudian jalankan servis sekali secara manual dan perhatikan ia berfungsi:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers menunjukkan bila masa larian seterusnya akan dicetuskan. Anda juga boleh menjana pasangan fail unit tersebut daripada menaipnya sendiri:

Corak penuh di sebalik kedua-dua fail ini, termasuk sintaks kalendar dan arahan pengukuhan (hardening directives) yang boleh dibawa oleh sesuatu servis, terdapat dalam menjalankan program sebagai servis systemd pada VPS.

Sandaran hanyalah khabar angin sehingga anda memulihkannya

Anggap ayat tersebut sebagai satu perintah. Tugas sandaran yang berjaya dijalankan setiap malam hanya membuktikan tugas tersebut telah berjalan; ia tidak membuktikan data anda boleh dikembalikan. Dua pemeriksaan akan merapatkan jurang ini.

Pertama, restic check, yang sudah dijalankan oleh skrip setiap malam. Ia mengesahkan struktur repositori dan indeks, supaya kerosakan senyap pada hos sandaran dapat dikesan pada malam berikutnya dan bukannya pada hari pemulihan. Sekali sebulan, jalankan versi yang lebih mendalam, yang memuat turun dan mengesahkan secara kriptografi satu persepuluh daripada data sebenar secara rawak:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Oleh kerana subset tersebut adalah rawak setiap kali, larian bulanan akan meliputi keseluruhan repositori tanpa perlu menanggung kos muat turun penuh.

Kedua, latihan pemulihan. Masih dalam root shell seperti di atas, pulihkan satu direktori sebenar daripada snapshot terkini ke lokasi sementara dan bandingkan ia dengan fail yang sedang digunakan:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff yang tidak mencetak apa-apa bermakna setiap bait kembali dengan identik, yang merupakan satu-satunya bukti yang sah. Padamkan /srv/restore-drill selepas itu. Lakukan latihan ini setiap bulan, dan sekali atau dua kali setahun lakukan versi penuh: pulihkan keseluruhan snapshot terkini ke VPS sementara dan periksa sama ada aplikasi anda benar-benar bermula daripadanya. Pada hari anda memerlukan ini berfungsi di bawah tekanan, anda pasti mahu ia menjadi rutin yang sudah biasa anda lakukan.

Pengekalan: forget dan prune

Tanpa polisi, snapshot akan terkumpul selama-lamanya dan repositori akan terus membesar. Baris forget dalam skrip menggunakan polisi setiap malam: --keep-daily 7 mengekalkan satu snapshot sehari untuk tujuh hari terakhir, --keep-weekly 4 satu snapshot seminggu untuk empat minggu, dan --keep-monthly 6 satu snapshot sebulan untuk enam bulan. Semua data yang tidak dilindungi oleh peraturan akan dibuang (forgotten).

forget sahaja hanya memadamkan rekod snapshot; ketulan data (data chunks) kekal dalam repositori sehingga ada proses yang memadamkannya. Itulah fungsi --prune: ia mencari ketulan data yang tidak lagi dirujuk oleh mana-mana snapshot dan memadamkannya, iaitu masa di mana ruang cakera benar-benar dikembalikan. Prune melakukan kerja repositori yang sebenar, jadi bagi repositori yang besar, sesetengah pengguna menjalankan forget setiap malam dan --prune setiap minggu; untuk saiz VPS biasa, menjalankan setiap malam adalah memadai.

Pangkalan data: lakukan dump dahulu, kemudian sandarkan fail dump tersebut

Restic menyalin fail semasa ia membacanya, manakala pangkalan data menulis ke dalam failnya secara berterusan. Fail pangkalan data yang sedang aktif dan disalin semasa proses penulisan akan menyebabkan data rosak apabila dipulihkan, kerana salinan tersebut mencampurkan halaman data sebelum dan selepas penulisan. Penyelesaiannya adalah standard: minta enjin pangkalan data menghasilkan eksport yang konsisten ke dalam satu fail, kemudian biarkan restic menyandarkan fail tersebut.

Bagi PostgreSQL, tambahkan baris dump di bahagian atas restic-backup.sh, sebelum arahan restic backup, dan sertakan direktori dump tersebut dalam laluan sandaran:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump memainkan peranan yang sama untuk MariaDB dan MySQL. Untuk contoh lengkap bagi keseluruhan corak ini, bahagian sandaran Nextcloud mengaktifkan mod penyelenggaraan, melakukan dump Postgres, dan menyalin fail-fail tersebut sebagai satu set yang konsisten, iaitu set yang tepat untuk dibawa keluar dari pelayan oleh restic setiap malam. SQLite menggunakan konsep yang sama dengan kaedah yang lebih ringkas: panduan Vaultwarden menghentikan kontena selama beberapa saat untuk mengambil salinan sejuk (cold copy) bagi db.sqlite3, dan arkib itulah yang dihantar keluar dari pelayan oleh restic.

FAQ

Adakah sandaran restic disulitkan?

Ya, sentiasa. Setiap repositori restic disulitkan dengan AES-256, tiada mod tanpa penyulitan, dan setiap arahan memerlukan kata laluan repositori. Mesin atau penyedia yang menyimpan repositori hanya memegang blob yang disulitkan, jadi hos sandaran yang terjejas tidak akan mendedahkan fail anda. Pertukarannya mutlak: tanpa kata laluan, data tidak boleh dipulihkan oleh sesiapa pun, jadi simpan satu salinan kata laluan di luar pelayan.

Adakah restic melakukan sandaran inkremental?

Setiap snapshot restic berfungsi seperti sandaran penuh, namun menggunakan storan inkremental. Restic memecahkan fail kepada ketulan (chunks) dan hanya memuat naik ketulan yang belum disimpan dalam repositori, jadi proses harian hanya memindahkan data yang berubah pada hari tersebut. Berbeza dengan skim inkremental tradisional, tiada rantaian untuk dimainkan semula: mana-mana snapshot boleh dipulihkan secara terus dan memadam snapshot lama tidak akan merosakkan snapshot yang lebih baharu.

Bagaimanakah cara untuk memulihkan fail daripada sandaran restic?

Jalankan restic snapshots untuk mencari ID snapshot, kemudian restic restore <id> --target /some/empty/dir untuk memulihkannya, dengan menambah --include /path untuk memulihkan sebahagian daripadanya sahaja. latest berfungsi sebagai ganti kepada ID. Restic mencipta semula struktur direktori asal di bawah sasaran, jadi memulihkan /etc/ssh akan meletakkannya di /some/empty/dir/etc/ssh. Latih prosedur ini sebelum anda memerlukannya, kerana sandaran yang tidak diuji hanyalah khabar angin.

Berapa kerap saya perlu menjalankan sandaran restic?

Jadual harian adalah tahap minimum yang wajar bagi sesebuah pelayan, dan penyahduplikasian (deduplication) menjadikannya murah: setiap proses hanya memuat naik ketulan yang berubah sejak kali terakhir. Data yang berubah dengan pantas, atau data yang kritikal jika hilang walaupun sehari, boleh dijalankan setiap beberapa jam dengan corak pemasa yang sama. Kekerapan hanyalah separuh daripada tugas; jalankan juga restic check secara berkala dan latihan pemulihan setiap bulan, kerana jadual tanpa pengesahan hanyalah keselesaan palsu.

Apakah yang berlaku jika saya kehilangan kata laluan repositori restic saya?

Sandaran tersebut tidak boleh dipulihkan. Penyulitan restic tidak mempunyai pintu belakang dan tiada tetapan semula, jadi kata laluan adalah sama penting dengan sandaran itu sendiri. Simpan satu salinan dalam pengurus kata laluan anda dan di mana-mana tempat tahan lama yang bukan merupakan pelayan yang disandarkan. Selagi anda masih mempunyai akses, restic key add boleh mendaftarkan kata laluan kedua untuk repositori yang sama, yang memberikan anda kata laluan simpanan.