Pencadangan & pemulihan

Aplikasinya bernama “Ticket System Backup & Restore”. Ia berada di samping sistem tiketnya dan punya pintasannya sendiri di desktop.

Ada versi untuk Windows dan satu untuk Linux. Aplikasinya sama, hanya dibangun untuk masing-masing sistem operasi.

Aplikasi itu punya enam tab. “Restore” mencantumkan cadangan yang Anda punya, “Create Backup” membuat yang baru, “Schedule” mengurus waktunya, “Encryption” menampilkan kunci pemulihan, “Settings” menampilkan jalurnya, dan “Log” protokolnya.

Pengaturannya sudah terisi. Pada permulaan pertamanya, aplikasi itu menentukan sendiri di mana sistem tiketnya tinggal.

Folder untuk cadangannya berada di bawah “Backup directory”. Anda dapat mengubahnya, misalnya ke diska yang berbeda.

Di Windows, aplikasi itu meminta hak administrator saat dimulai. Pengaturannya berlaku untuk setiap administrator komputer itu dan tersimpan di “%ProgramData%\SMITEY\backup-app”.

Pemasangannya menyiapkan cadangan harian dengan sendirinya. Cadangan itu berjalan pukul 23:00 di zona waktu sistem tiket.

Jadwalnya tinggal di sistem operasinya. Di Windows itu adalah Task Scheduler, di Linux layanan cron. Jadi tidak ada layanan tambahan yang berjalan hanya untuk cadangan.

Cadangannya tidak memerlukan siapa pun dalam keadaan masuk. Di server tempat tidak ada yang pernah masuk pun, ia tetap berjalan.

Baris di bawah tombolnya memberi tahu Anda apakah tugasnya benar-benar ada di sistem operasinya. Kotak yang tercentang hanya menyebut apa yang tersimpan.

Cadangan disimpan dalam lima tingkat: 14 hari, 4 minggu, 12 bulan, 4 triwulan, dan 5 tahun. Sebuah cadangan bertahan selama ia adalah yang terbaru dari periodenya di salah satu tingkat itu.

Yang dihitung adalah hari kalender, bukan berkas. Dua cadangan dalam satu hari adalah satu hari.

Cadangan yang Anda buat dengan tangan tidak pernah dihapus secara otomatis. Itulah arti angka 0 pada “Keep manual”.

Bila Anda mengubah jadwalnya, perubahan Anda bertahan melewati sebuah pembaruan. Pemasangannya hanya menyetelnya bila Anda belum pernah menyetel jadwal. Bila Anda mematikan pencadangannya, pencadangan itu tetap mati. “Remove all scheduled tasks” juga bertahan: sebuah pembaruan tidak menyiapkan jadwalnya lagi sesudahnya.

Sebuah cadangan memuat segala yang membentuk keadaan sistem Anda. Yaitu basis data, lampiran file, arsip, dan kunci. Hanya basis data di luar SMITEY yang tidak ikut.

Kuncinya adalah bagian yang mudah terlewat. Kunci itu mendekripsi kredensial yang tersimpan, misalnya kredensial akun surat Anda. Tanpanya, sebuah pemulihan akan kembali dengan kredensial yang mati.

Setiap cadangan baru adalah satu file terenkripsi berakhiran “.smbk”. File itu memuat satu file per volume, daftar isinya, dan basis data sebagai file teks bila ikut dicadangkan.

Sistemnya terus berjalan selama hal ini terjadi. Agen Anda sama sekali tidak menyadari adanya pencadangan.

“Estimate size” memberi tahu Anda lebih dulu seberapa besar basis datanya. Volume berisi lampiran ditambahkan di atasnya. Cadangan tidak dikompresi.

Tidak pernah ada yang ditimpa. Setiap cadangan adalah berkasnya sendiri, dan hanya pembersihannya yang menghilangkan yang lama.

Hanya administrator yang dapat membaca cadangan. Hal yang sama berlaku untuk berkas konfigurasi dan berkas berisi data masuk pertama di folder instalasi. Program instalasi dan setiap pembaruan menyetel izin ini sendiri.

Bila basis data Anda berjalan di server sendiri dan bukan di kontainer SMITEY, aplikasi tidak dapat mencadangkannya. Cadangkan dengan alat Anda sendiri. Dalam hal itu cadangan hanya memuat lampiran, arsip, dan kunci, terenkripsi seperti biasa. Pembaruan mengenali basis data seperti itu sendiri dan mengalihkan aplikasi. Sampai saat itu cadangan harian pada instalasi seperti itu gagal, kecuali Anda mengalihkannya dengan tangan lebih dulu. Di baris perintah Anda juga dapat melakukannya dengan tangan memakai “config --database external”. Dengan “config --database bundled” Anda beralih kembali.

Setiap cadangan baru dienkripsi. Ini berlaku untuk cadangan dari jadwal, cadangan yang dibuat dengan tangan, dan cadangan sebelum pembaruan. Anda tidak perlu mengaktifkan apa pun.

Cadangan dienkripsi dengan AES-256. Instalasi membuat kuncinya sendiri. Pada instalasi yang sudah ada, kunci dibuat saat pembaruan pertama ke versi dengan enkripsi. Kunci disimpan di server dalam keadaan terlindungi. Hanya administrator yang dapat membacanya.

Ini melindungi salinan di luar server. Siapa pun yang menemukan cadangan di drive jaringan, di stik USB, atau di penyimpanan online tidak dapat membacanya tanpa kunci. Siapa pun yang menguasai server itu sendiri juga memegang kuncinya.

Kunci pemulihan adalah kunci yang sama dalam bentuk yang dapat Anda tulis. Kunci itu diawali “SMBK-”. Anda menemukannya di tab “Encryption” dan di file “SMITEY-credentials.txt” di folder instalasi. Bila Anda menghapus file itu, kunci tetap ada di tab “Encryption”.

“Copy” menaruh kunci di clipboard. “Save to file...” menyimpannya bersama ID kunci dan tanggal dalam file teks. Simpan misalnya di pengelola kata sandi atau di atas kertas dalam brankas.

Sampai Anda mengonfirmasi bahwa kunci sudah disimpan, aplikasi menampilkan bilah kuning di bagian atas. Untuk mengonfirmasi, klik “I stored the key outside this server” dan jawab pertanyaannya dengan “Yes”. Bilah itu lalu hilang. Tab itu kemudian menampilkan kapan Anda mengonfirmasi.

ID kunci memberi tahu server mana yang memiliki sebuah cadangan. Bila cadangan bukan milik server ini, aplikasi menyebut ID kuncinya. Lalu aplikasi meminta kunci pemulihan yang cocok.

Bila aplikasi tidak dapat membaca kunci, ia tidak membuat cadangan. Ia juga tidak membuat yang tanpa enkripsi. Dalam hal itu tab “Encryption” menyatakan bahwa kunci tidak dapat dibaca. Bila file kunci tidak ada sama sekali, cadangan berikutnya membuat kunci baru. Bilah kuning lalu muncul lagi, karena kunci baru pun harus disimpan. Cadangan lama tetap hanya dapat dibuka dengan kunci pemulihan yang lama.

Cadangan lama berformat ZIP tidak terenkripsi. Anda tetap dapat memulihkannya. Tab itu menampilkan jumlahnya. Pembersihan menghapusnya dengan aturan yang sama seperti cadangan lain.

Di server tanpa desktop, “key --show” menampilkan hal yang sama di baris perintah.

Di tab “Restore” Anda memilih cadangan yang Anda inginkan kembali. Lalu Anda mengklik “Restore”.

Aplikasinya bertanya lebih dulu. Ia menyebut apa yang akan terjadi: keadaan hari ini ditimpa, dan aplikasinya menjalankan ulang kontainernya. Jika ada orang yang dianonimkan dalam keadaan hari ini, menyusul pertanyaan kedua. Pertanyaan itu menyebut jumlahnya dan bertanya apakah mereka perlu dianonimkan lagi setelah pemulihan. “Yes” sudah terpilih sejak awal. Dengan “No”, cadangan dipulihkan tanpa langkah ini. Jika Anda menutup jendelanya sebagai gantinya, tidak ada yang dipulihkan.

Centang “Wipe target volumes before restore” mengosongkan volumenya lebih dulu. Dengan begitu tidak ada berkas yang tertinggal yang belum ada ketika cadangannya dibuat.

Langkah-langkahnya muncul di tab “Log”. Di sana Anda melihat satu per satu apa yang dilakukan aplikasinya. Jika Anda menjawab “Yes” pada pertanyaan kedua, satu baris di akhir menyebut berapa anonimisasi yang diterapkan lagi oleh sistem tiket pada malam berikutnya. Jika anonimisasi itu tidak dapat dipindahkan, log menampilkan peringatan sebagai gantinya. Jika ada peringatan, baris status di bagian bawah jendela menyebut jumlahnya.

Bila cadangan memuat basis data, keadaan lengkapnya kembali. Tiket, komentar, riwayat, lampiran file, waktu yang dicatat, dan basis pengetahuan semuanya ada lagi seperti pada saat cadangan dibuat.

Setelah itu sistemnya dapat dipakai lagi. Pada pemasangan kecil hal ini memakan kurang dari satu menit.

Bila cadangan memuat basis data, basis data itu kembali sepenuhnya atau tidak sama sekali. Volumenya menyusul sesudahnya. Bila sebuah volume gagal, basis datanya sudah kembali tetapi file bisa hilang; tab “Log” menunjukkan langkah mana yang gagal. Dalam setiap kasus, aplikasi menjalankan ulang kontainernya sesudahnya, bahkan bila pemulihan gagal.

Cadangan dari versi yang lebih lama dapat dipulihkan ke versi yang lebih baru. Saat dimulai berikutnya, sistemnya menaikkan basis datanya ke versinya sendiri.

Persetujuan dan tindakan berhenti berlangganan untuk survei kepuasan dipindahkan tanpa pertanyaan. Ini berlaku juga bila Anda menjawab pertanyaan kedua dengan “No”. Aplikasi membacanya dari pemasangan yang sedang berjalan sebelum pemulihan. Setelah itu, satu baris di tab “Log” menyebutkan jumlahnya, misalnya “12 consent and unsubscribe record(s) were carried over.” Sistem tiket mengambil alihnya pada start pertamanya. Persetujuan atau tindakan berhenti berlangganan yang dibuat setelah pencadangan karena itu tetap berlaku. Bila pemindahan gagal, log menampilkan peringatan. Pemulihan tetap dianggap berhasil.

Aplikasi lebih dulu memeriksa cadangan terenkripsi secara lengkap. Selama itu baris status menyatakan “Checking the encrypted backup before anything is changed...”. Baru setelah itu aplikasi menghentikan kontainer. Bila file rusak atau diubah, aplikasi berhenti dan melaporkan “The backup file is damaged. Nothing was changed.”

Bila cadangan berasal dari server lain, aplikasi meminta kunci pemulihan server itu. Ini terjadi setelah pertanyaan-pertanyaan. Jendela “Recovery key needed” menyebut ID kunci cadangan itu. Jendela yang sama muncul bila kunci server ini tidak ada.

Kesalahan ketik terdeteksi sebelum ada yang diubah. Baris status lalu melaporkan “The recovery key has a typing error. Check each character.” Setelah itu jendela bertanya lagi. Bila kunci milik cadangan lain, baris status melaporkan “This recovery key does not belong to this backup.” Dengan “Cancel” aplikasi berhenti dan melaporkan “Restore cancelled. Nothing was changed.”

Aplikasi tidak mengambil alih kunci yang Anda masukkan. Ia tetap memakai kuncinya sendiri. Cadangan baru tetap dibuat dengan kunci server ini. Bila Anda memulihkan di server baru, simpan juga kunci pemulihan server itu.

Cadangan tanpa basis data hanya memulihkan lampiran, arsip, dan kunci. Kunci yang ada dipertahankan. Basis data tetap seperti adanya. Aplikasi menyatakan hal ini sebelum pemulihan dan bertanya. Dengan “No” tidak ada yang diubah.

Jika instalasi diatur memakai basis datanya sendiri, aplikasi melewati bagian basis data meskipun cadangan berisi basis data. Ini berlaku misalnya untuk cadangan yang lebih lama. Aplikasi bertanya lebih dulu. Dengan “No” tidak ada yang diubah.

Sebuah server sering tidak punya desktop. Karena itu aplikasi yang sama juga berjalan sebagai sebuah perintah.

Lima perintah yang Anda perlukan sehari-hari: “backup” menyimpan, “list” menampilkan cadangan yang Anda punya, “restore” membawa satu kembali, “schedule” menyetel waktunya, dan “config” menampilkan pengaturannya. Untuk kunci, ditambah “key” dan “decrypt”.

Di baliknya adalah aplikasi yang sama dengan yang ada di jendelanya. Tidak ada jalur kedua yang melakukan hal yang berbeda.

Aplikasinya berada di “/opt/smitey/Backup”. Anda memanggilnya dengan “sudo” lalu menambahkan perintahnya. Kontainernya berjalan sebagai “root”, jadi cadangannya juga memerlukan hak itu.

Anda dapat menyalin keenam kotak di bawah. Keenamnya mencakup apa yang benar-benar diperlukan dalam pemakaian sehari-hari.

Sebuah pemulihan juga bertanya di sini. Ia baru berjalan ketika Anda menambahkan “--yes”. Pemulihan itu lalu juga memindahkan anonimisasi dari keadaan hari ini, sama seperti “Yes” di jendela. Dengan “--no-reapply”, pemulihan berjalan tanpa langkah ini.

Ada sebuah berkas di servernya untuk membaca semua ini. Berkas itu bernama “BACKUP-RESTORE.txt” dan berada di “/opt/smitey”. Berkas itu menelusuri jadwalnya, setiap perintahnya, dan jalan kembalinya sekali lagi, sesuai kecepatan Anda sendiri. Berkas itu tersedia dalam bahasa Jerman dan bahasa Inggris: bila Anda memilih bahasa Jerman saat pemasangan, Anda mendapat yang berbahasa Jerman, bila tidak, yang berbahasa Inggris. Kedua versinya juga berada di bawah “/opt/smitey/docs”.

“key --show” menampilkan kunci pemulihan, ID kunci, dan jumlah cadangan tanpa enkripsi. Setelah kunci disimpan di luar server, Anda mengonfirmasinya dengan “key --confirm-stored”.

Cadangan dari server lain Anda pulihkan dengan “--key-file”. File yang Anda sebut berisi kunci pemulihan. File dari “Save to file...” juga dapat dipakai. Sebagai ganti file, Anda juga dapat memakai variabel lingkungan “SMITEY_BACKUP_KEY”. Dengan “sudo” Anda menaruhnya langsung sebelum program, yaitu “sudo SMITEY_BACKUP_KEY=<key> /opt/smitey/Backup/TicketSystemBackup restore …”. Kunci itu lalu masuk ke riwayat shell. Bila kunci tidak cocok, tidak ada yang diubah.

“decrypt” menulis isi sebuah cadangan sebagai file tanpa enkripsi ke folder kosong. File ini tidak terenkripsi. File ini berisi kata sandi dan data pribadi. Hapus segera setelah selesai.

Cadangannya adalah berkas di folder yang Anda setel. Folder itu berada di mesin yang sama dengan sistem tiketnya.

Untuk kasus yang lazim, hal itu berjalan baik. Data yang terhapus karena keliru, pembaruan yang gagal, atau galat di datanya semuanya tercakup.

Hal itu tidak menolong terhadap diska yang rusak. Bila diskanya hilang, cadangannya hilang bersamanya.

Jadi salinlah berkasnya ke tempat lain. Sebuah diska jaringan, server kedua, atau penyimpanan di jaringan sudah cukup.

File yang disalin dapat dimuat kembali di server mana pun. Di server lain Anda memerlukan kunci pemulihan untuk itu. Dengan “Import backup file…” Anda membawa file itu kembali ke daftar.

Salinan itu terenkripsi. Tidak seorang pun dapat membacanya tanpa kunci pemulihan. Jadi jangan simpan kunci di samping salinan. Cadangan lama berakhiran “.zip” tidak terenkripsi.

Sebuah pembaruan membuat cadangannya sendiri lebih dulu. Hal itu terjadi terlepas dari jadwal Anda dan tanpa Anda mencentang apa pun.

Ia menyimpan hal yang sama seperti biasa: basis data, lampiran, arsip, dan kunci. Bila basis data berjalan di luar SMITEY, pembaruan hanya mencadangkan lampiran, arsip, dan kunci.

Cadangan ini dibuat oleh aplikasi “Ticket System Backup & Restore”. Cadangan ini terenkripsi seperti yang lain dan berada di folder yang sama. Di daftar, jenisnya adalah “Update”. Tiga cadangan terbaru dari jenis ini disimpan. Aplikasi menghapus yang lebih lama sendiri.

Pemberitahuan sebelum pembaruannya memberi tahu Anda demikian. Anda tidak harus ingat untuk menyimpan lebih dulu sendiri.

Bila cadangan ini gagal, pembaruan berhenti sebelum ada yang diganti. Basis data di luar SMITEY tidak menahan pembaruan. Pembaruan lalu mengalihkan aplikasi sehingga cadangan harian juga melewatkan basis data. Cadangkan basis data ini dengan alat Anda sendiri.