Saya menggunakan strategi backup “3-2-1” yang mana cukup populer digunakan di industri. Maksud dari strategi tersebut adalah, memiliki:
- 3 salinan data
- 2 salinan berada di lokal (on-site) namun di media berbeda
- 1 salinan berada diluar (off-site)
Media yang saya gunakan adalah:
- 2 HDD melalui RAID 1 (mirror) untuk salinan on-site
- 1 SSD eksternal untuk salinan off-site
Untuk RAID 1 mungkin dapat dipertanyakan karena RAID bukanlah backup1, dan saya tidak menggunakan fitur “Snapshot Replication” untuk memiliki salinan yang tahan akan error di volume tersebut. That’s fine for now (and in this circumstances) i guess.
Pertanyaan umum terkait “backup” adalah:
- Apa yang harus di backup?
- Kapan harus melakukan backup?
Dan disini kita akan bahas.
Aturan backup
Setiap salinan yang bersifat sensitif, harus disimpan dalam bentuk ter-enkripsi. Untuk on-site backup, menggunakan enkripsi at-rest dan off-site menggunakan enkripsi end-to-end. Enkripsi terkait salinan yang bersifat sensitif ini hanya berlaku di off-site.
Untuk enkripsi at-rest saya menggunakan Linux Unified Key Setup (LUKS) dan untuk enkripsi end-to-end saya menggunakan Restic. Alasan menggunakan pendekatan ini adalah:
- Untuk menghindari penggunaan enkripsi di level volume untuk off-site media
- Jika sekiranya tidak ada yang tau encryption key dari ketiga media tersebut, setidaknya masih ada data yang bisa diakses yang mungkin bermanfaat selain untuk diri saya sendiri
Bagaimanapun menggunakan enkripsi at-rest adalah standar untuk menghindari kasus pencurian data jika media (seperti HDD) “dikeluarkan” dari tempat yang seharusnya. Bedanya dengan end-to-end adalah enkripsi terjadi sebelum data tersebut dipindahkan, yang gampangnya, seperti enkripsi terjadi saat pengguna mengirim pesan ke tujuan, namun hanya si tujuan yang dapat “membaca” pesan nya.
Retention policy
Untuk setiap salinan yang disimpan dalam bentuk ter-enkripsi umumnya salinan tersebut berumur 1 bulan. Dengan fitur deduplication nya Restic, jumlah snapshot tidak menjadi “multiplier” terhadap jumlah kapasitas yang digunakan, yang membuat penyimpanan menjadi lebih efektif.
Cara backup
- On-site backup terjadi dibelakang layar oleh DSM nya Synology.
- Off-site backup terjadi melalui scheduler yang menjalankan program
restic(1)dari program USB copy. - SSD eksternal selalu terhubung ke NAS kecuali saat saya sedang berpergian lama.
Barang pribadi
Untuk saat ini saya belum berencana melakukan backup untuk level perangkat (Macbooks, iPads, iPhones, dkk) karena belum memiliki alasan khusus. Gampangnya, tidak ada barang “berharga” yang disimpan di perangkat tersebut selain konfigurasi/preferensi perangkat, dan jumlah aplikasi yang saya gunakan pun tidak sebanyak itu sehingga bisa saya lacak disini.
Yang di backup
Ini adalah barang-barang pribadi seperti media, dokumen, dan lain-lain. Mungkin aset-aset digital yang digunakan untuk keperluan/kepentingan pribadi. Untuk hal ini saya memiliki kategori khusus:
- Aset yang hanya boleh diakses oleh saya pribadi
- Aset yang boleh diakses oleh siapapun yang memiliki akses
Untuk poin pertama, salinan disimpan dalam bentuk ter-enkripsi (E2E) di off-site. Poin pertama ini mungkin barang-barang yang penting untuk saya namun “nice to know” untuk yang lain :)
Waktu backup
Untuk on-site backup, ini terjadi secara instan. Seperti multimedia, dokumen, dan sumber kode. Untuk backup ke media lain (off-site), ini terjadi daily dan automated.
Database
Saya hanya menggunakan PostgreSQL di Homelab saya, dan backup menggunakan pgbackrest.
Yang di backup
Semua konten databases, users, extensions.
Waktu backup
Saya melakukan “full backup” dan “differential backup” untuk efisiensi tanpa harus mengorbankan efektivitas. Full backup terjadi setiap 1 minggu dan differential backup terjadi setiap hari. Waktunya adalah di pagi hari di zona waktu Asia/Jakarta (UTC+7).
Target backup nya adalah ke MinIO yang berada di mesin mac-mini, dan di replikasi ke MinIO yang berada di mesin nas01. Technically untuk ini salinannya berjumlah 4 karena berada di 2 HDD (1 mesin yang sama) dan 2 SSD (2 mesin berbeda).
Retention policy khusus untuk ini adalah “keep 3 full backup” beserta differential backup nya. Yang berarti, rentang waktu untuk snapshots nya adalah 3 minggu. Yang berarti, ada 1*7*3 total backup yang disimpan.
MinIO
Ada 2 instance MinIO yang berjalan di Homelab saya: untuk cold storage (nas01) dan warm storage (mac-mini).
Yang di backup
Ini bergantung dengan bucket yang ada. Sejauh ini kegunaannya adalah:
- Menyimpan cache
- Menyimpan media yang sering diakses
- Menyimpan media yang jarang diakses
Untuk media yang sering diakses seperti berkas-berkas multimedia, saya melakukan “tiering” yang gampangnya, metadata objek (objek adalah konsep “file” di MinIO) disimpan di MinIO utama (mac-mini) namun kontennya disimpan di replika (nas01). Didepan MinIO selalu ada “caching proxy” jadi pendekatan ini efektif sekaligus efisien digunakan khususnya bila cache di proxy tersebut expired.
Untuk media yang jarang diakses seperti berkas backup, saya melakukan “replication” di level bucket.
Untuk cache yang disimpan di bucket MinIO, saya tidak melakukan backup, karena, it’s a cache anyway.
Waktu backup
Besar kemungkinan “just-in-time” untuk on-site backup dan daily untuk off-site dari NAS ke SSD eksternal.
Git repository
Saya menggunakan Gitea dan menyimpan konten repository di NAS yang diakses melalui NFS, jadi strategi backup 3-2-1 berlaku disini. Cache berada di Redis, dan belum memiliki alasan mengapa harus mem-backup Redis.
Yang dibackup
Git repository, media, LFS.
Waktu backup
Besar kemungkinan “just-in-time” untuk on-site dan daily untuk off-site. Sumber kode tidak termasuk ke bagian “sensitif” saya dalam konteks privasi btw, jadi backup tidak disimpan dalam bentuk end-to-end encrypted.
Dan saya hanya menulis program Open Source anyway :)
Game
Saya belum memiliki pengetahuan untuk “best practices” dalam backup game khususnya bila bergantung ke Steam.
Berkas konfigurasi
Saya berencana untuk menggunakan tools yang menggunakan MinIO sebagai “backend” penyimpanan nya.
Yang dibackup
Untuk saat ini: .yml, .ini, .conf, dkk. Mungkin akan mempertimbangkan menggunakan etcd nanti.
Waktu backup
Jika ingat (LOL). Ini adalah berkas/data yang tidak setiap hari berubah, so, yeah.
Beberapa bergantung dengan “dotfiles” dan pada akhirnya disimpan di Git repository.
Catatan Tambahan
Pertimbangkan untuk menggunakan NFS, misal seperti ini:
- /dom/nama-vmx/app
- /dom/nama-vmy/app
- /dom/nama-vmz/app
Sehingga berkas konfigurasi dapat di backup menggunakan pendekatan 3-2-1 dan tidak perlu ribet mengatur MinIO.
Footnotes
-
Jika terjadi aksi yang tidak diharapkan (seperti delete) maka salinan di kedua media tersebut sama-sama terhapus ↩