Cara Simpan Backup Server ke Object Storage S3

Cara paling praktis menyimpan backup server ke object storage S3 adalah memakai restic dengan repositori bertipe s3:, atau rclone bila kamu sudah punya file backup dan hanya perlu menyalinnya ke bucket.

Kenapa S3? Karena backup yang baik harus berada di luar server yang dibackup, dan object storage cocok untuk itu: kapasitasnya fleksibel, dibayar sesuai pemakaian, bisa diakses dari server mana pun, dan banyak penyedia menawarkan API yang kompatibel S3. Kalau konsep object storage masih baru bagimu, baca dulu apa itu object storage S3.

Apa yang perlu disiapkan di sisi storage?

Sebelum menyentuh server, rapikan dulu tiga hal di penyedia object storage:

1. Bucket khusus backup. Jangan campur dengan bucket untuk file website atau aplikasi. Beri nama yang jelas, misalnya backup-web01.
2. Kunci akses (access key dan secret key) yang terbatas. Buat kunci baru yang hanya boleh mengakses bucket backup itu, bukan kunci utama akun. Kalau server dibobol, penyerang tidak bisa menyentuh bucket lain.
3. Endpoint dan region. Catat alamat endpoint S3 penyedia (misalnya https://s3.penyedia.example) dan region-nya bila diminta.

Kalau ingin menyimpan di infrastruktur sendiri, kamu bisa menjalankan server S3 sendiri. Caranya ada di memasang MinIO sebagai object storage sendiri.

Pilih restic atau rclone?

Keduanya gratis dan bisa bicara dengan S3, tapi fungsinya berbeda.

Untuk backup server, restic biasanya pilihan yang lebih lengkap. Rclone tepat bila panel atau aplikasi sudah membuat file backup sendiri (misalnya arsip .tar.gz harian) dan kamu hanya perlu mengirimnya keluar.

Cara mengirim backup dengan restic

Simpan pengaturan di /etc/restic/env dengan izin 600:

AWS_ACCESS_KEY_ID=kunci-akses-backup
AWS_SECRET_ACCESS_KEY=kunci-rahasia-backup
AWS_DEFAULT_REGION=us-east-1
RESTIC_REPOSITORY=s3:https://s3.penyedia.example/backup-web01/restic
RESTIC_PASSWORD_FILE=/etc/restic/password

Format s3:https://server/bucket berlaku untuk penyedia yang kompatibel S3. Untuk Amazon S3, dokumentasi restic memakai format s3:s3.<region>.amazonaws.com/<bucket>. Region bersifat opsional untuk penyedia selain AWS, dan bila tidak diisi restic memakai us-east-1. Restic memakai akses gaya path untuk endpoint di luar Amazon dan Google, jadi biasanya tidak ada yang perlu diubah.

Lalu buat repositori dan jalankan backup:

set -a; . /etc/restic/env; set +a
restic init
restic backup / --one-file-system --exclude-file=/etc/restic/excludes
restic snapshots

Daftar pengecualian, backup database, penjadwalan dengan systemd timer, dan cara restore sama persis dengan repositori jenis lain. Langkah lengkapnya ada di backup seluruh server Linux dengan restic.

Cara menyalin file backup dengan rclone

Pasang rclone (apt install rclone atau dari situs resminya), lalu jalankan rclone config dan pilih tipe penyimpanan S3. Setelah remote bernama misalnya s3backup terbentuk, salin folder backup:

rclone copy /var/backups/harian s3backup:backup-web01/harian --progress

Pakai copy, bukan sync, untuk folder backup. Perintah sync membuat tujuan persis sama dengan sumber, termasuk menghapus file di bucket bila file di server terhapus. Itu justru yang ingin dihindari dari sebuah backup. Bila isi backup sensitif dan belum terenkripsi, bungkus remote S3 dengan remote jenis crypt di rclone.

Bagaimana melindungi backup dari penghapusan?

Ransomware modern sering mencari dan menghapus backup lebih dulu. Beberapa lapis perlindungan yang umum tersedia di object storage:

• Versioning bucket. Objek yang ditimpa atau dihapus tetap tersimpan sebagai versi lama, sehingga masih bisa dikembalikan.
• Object lock (WORM). Objek tidak bisa diubah atau dihapus sampai masa kunci habis. Tidak semua penyedia menyediakannya, dan pada sebagian penyedia fitur ini harus diaktifkan saat bucket dibuat.
• Kunci tanpa izin hapus. Bila penyedia mendukung kebijakan akses rinci, server cukup diberi izin menulis dan membaca. Penghapusan data lama dijalankan dari mesin lain yang lebih terlindungi.
• Aturan siklus hidup (lifecycle). Versi lama dihapus otomatis setelah sekian hari, supaya biaya tidak membengkak.

Prinsip berlapis ini adalah bagian dari aturan backup 3-2-1-1-0, terutama salinan yang tidak bisa diubah.

Tips supaya biaya dan waktu tetap terkendali

• Kirim backup penuh pertama di jam sepi. Unggahan awal bisa memakan waktu lama untuk data besar.
• Pahami komponen biaya penyedia. Selain kapasitas, sebagian penyedia mengenakan biaya permintaan API atau lalu lintas keluar saat restore. Baca halaman harga resminya.
• Pilih lokasi yang dekat. Bucket di region yang dekat dengan server mempercepat backup dan restore.
• Pantau keberhasilan tugas. Kirim notifikasi bila skrip backup gagal, jangan menunggu sampai butuh restore.
• Uji restore dari bucket. Ambil satu folder atau database dari S3 ke server uji secara berkala, untuk memastikan kunci, kata sandi repositori, dan datanya benar-benar bisa dipakai.