
Catatan ini melengkapi siklus cadangan. Ini akan berbicara tentang organisasi logis dari server khusus (atau VPS), nyaman untuk cadangan, dan juga akan menawarkan opsi untuk dengan cepat memulihkan server dari cadangan tanpa downtime jika terjadi kecelakaan.
Sumber data
Sebuah dedicated server paling sering memiliki setidaknya dua hard drive yang digunakan untuk mengatur array RAID tingkat pertama (mirror). Ini diperlukan untuk dapat melanjutkan server jika satu drive gagal. Jika ini adalah server khusus yang didedikasikan, mungkin ada pengontrol RAID perangkat keras terpisah dengan teknologi caching aktif pada SSD, sehingga selain hard drive biasa satu atau lebih SSD dapat dihubungkan. Kadang-kadang server khusus ditawarkan, di mana hanya SATADOM yang hadir dari disk lokal (disk kecil, secara struktural - drive flash USB yang terhubung ke port SATA), atau bahkan drive flash USB kecil (8-16GB) biasa yang terhubung ke port internal khusus, dan data diambil dari sistem penyimpanan terhubung melalui jaringan penyimpanan khusus (Ethernet 10G, FC, dll.), dan ada server khusus yang dimuat langsung dari sistem penyimpanan. Saya tidak akan mempertimbangkan opsi seperti itu, karena dalam kasus seperti itu, tugas mencadangkan server dengan lancar diteruskan ke spesialis yang melayani sistem penyimpanan, biasanya ada berbagai teknologi eksklusif untuk membuat snapshot keadaan, deduplikasi bawaan, dan kegembiraan lain dari administrator sistem yang dibahas dalam bagian sebelumnya dari seri ini. Volume array disk dari server khusus dapat mencapai beberapa puluh terabyte, tergantung pada jumlah dan volume disk yang terhubung ke server. Dalam kasus VPS, volumenya lebih sederhana: biasanya tidak lebih dari 100GB (tetapi ada lebih banyak), dan tarif untuk VPS seperti itu dapat dengan mudah lebih mahal daripada server khusus yang termurah dari hoster yang sama. VPS paling sering memiliki satu drive, karena di bawahnya akan ada penyimpanan (atau sesuatu hyperconverged). Terkadang VPS memiliki beberapa disk dengan karakteristik berbeda, untuk tujuan berbeda:
- sistem kecil - untuk menginstal sistem operasi;
- besar - penyimpanan data pengguna.
Saat menginstal ulang sistem menggunakan panel kontrol, disk dengan data pengguna tidak ditimpa, tetapi sistem sepenuhnya dimuat ulang. Juga, dalam kasus VPS, tuan rumah dapat menawarkan tombol yang mengambil snapshot dari status VPS (atau disk), namun, jika Anda menginstal sistem operasi Anda atau lupa untuk mengaktifkan layanan yang diinginkan di dalam VPS, beberapa data mungkin masih hilang. Selain tombol, layanan penyimpanan data biasanya ditawarkan, paling sering sangat terbatas. Biasanya ini adalah akun dengan akses FTP atau SFTP, kadang-kadang bersama-sama dengan SSH, dengan shell terpotong (misalnya rbash), atau pembatasan menjalankan perintah melalui otorisasi_keys (melalui ForcedCommand).
Server khusus terhubung ke jaringan oleh dua port dengan kecepatan 1 Gbit / s, kadang-kadang dapat berupa kartu dengan kecepatan 10 Gbit / s. VPS sering memiliki satu antarmuka jaringan. Paling sering, pusat data tidak membatasi kecepatan jaringan di dalam pusat data, tetapi membatasi kecepatan akses Internet.
Beban khas dari server khusus atau VPS adalah server web, database, server aplikasi. Kadang-kadang berbagai layanan dukungan tambahan dapat diinstal, termasuk untuk server web atau database: mesin pencari, sistem surat, dll.
Server yang disiapkan secara khusus bertindak sebagai ruang untuk menyimpan salinan cadangan, itu akan dijelaskan secara lebih rinci di bawah ini.
Organisasi Disk Logis
Jika ada pengontrol RAID, atau VPS dengan satu disk, dan juga tidak ada preferensi khusus untuk subsistem disk (misalnya, disk cepat terpisah untuk basis data) - semua ruang kosong dibagi sebagai berikut: satu partisi dibuat, sekelompok volume LVM dibuat di atasnya , ia menciptakan beberapa volume: 2 yang kecil dengan ukuran yang sama yang digunakan sebagai sistem file root (mereka diubah secara bergantian dengan pembaruan untuk mengaktifkan rollback cepat, ide itu dimata-matai dari distribusi Calculate Linux), yang lain adalah untuk partisi swap, sisanya gratis ruang ini dibagi menjadi volume kecil yang digunakan sebagai sistem file root untuk kontainer penuh, disk untuk mesin virtual, sistem file untuk akun di / rumah (setiap akun memiliki sistem file sendiri), sistem file untuk kontainer aplikasi.
Catatan penting: volume harus sepenuhnya swasembada, mis. seharusnya tidak bergantung satu sama lain dan pada sistem file root. Dalam kasus mesin atau wadah virtual, titik ini diamati secara otomatis. Jika ini adalah wadah aplikasi atau direktori rumah, Anda harus mempertimbangkan untuk memisahkan file konfigurasi server web dan layanan lain sedemikian rupa untuk secara maksimal menghapus dependensi volume di antara mereka. Misalnya, setiap situs berjalan pada penggunanya sendiri, file konfigurasi situs berada di direktori home pengguna, dalam pengaturan server web, file konfigurasi situs tidak disertakan melalui /etc/nginx/conf.d/ .conf , tetapi, misalnya, / home / /configs/nginx/*.conf
Jika ada beberapa disk, Anda dapat membuat RAID perangkat lunak (dan mengkonfigurasi caching pada SSD, jika ada kebutuhan dan peluang), di atas yang mana untuk memasang LVM sesuai dengan aturan yang disarankan di atas. Juga dalam hal ini, Anda dapat menggunakan ZFS atau BtrFS, tetapi di sini perlu dipertimbangkan beberapa kali: keduanya memerlukan pendekatan sumber daya yang jauh lebih serius, di samping itu, ZFS tidak datang dengan kernel Linux.
Terlepas dari skema yang digunakan, selalu bermanfaat untuk memperkirakan perkiraan kecepatan penulisan perubahan pada disk sebelumnya, dan kemudian menghitung ukuran ruang kosong yang akan disediakan untuk membuat snapshot. Misalnya, jika server kami menulis data pada kecepatan 10 megabyte per detik, dan ukuran seluruh array data adalah 10 terabyte - waktu sinkronisasi dapat mencapai satu hari (22 jam - jumlah ini akan ditransfer melalui jaringan 1 gbit / s) - layak untuk dicadangkan tentang 800 GB Pada kenyataannya, jumlahnya akan lebih sedikit, Anda dapat dengan aman membaginya dengan jumlah volume logis.
Perangkat Server Penyimpanan Cadangan
Perbedaan utama antara server untuk menyimpan cadangan adalah disk besar, murah, dan relatif lambat. Karena HDD modern telah melewati batas 10 TB dalam satu drive, perlu untuk menggunakan sistem file atau RAID dengan checksum, karena selama pembangunan kembali array atau pemulihan sistem file (beberapa hari!), Disk kedua mungkin gagal karena peningkatan beban. Pada disk dengan kapasitas hingga 1TB, ini tidak terlalu sensitif. Untuk kesederhanaan deskripsi, saya berasumsi bahwa ruang disk dibagi menjadi dua bagian dengan ukuran yang kira-kira sama (sekali lagi, misalnya, menggunakan LVM):
- volume yang terkait dengan server yang digunakan untuk menyimpan data pengguna (cadangan terakhir yang dibuat untuk verifikasi akan digunakan untuk mereka);
- volume yang digunakan sebagai repositori BorgBackup (data untuk cadangan akan langsung sampai di sini).
Prinsip operasi adalah bahwa volume terpisah dibuat untuk setiap server di bawah repositori BorgBackup, di mana data dari server pertempuran akan pergi. Repositori beroperasi dalam mode add-only, yang menghilangkan kemungkinan penghapusan data yang disengaja, dan karena deduplikasi dan pembersihan repositori berkala dari cadangan lama (ada salinan tahunan, bulanan untuk tahun lalu, mingguan untuk bulan lalu, setiap hari untuk minggu terakhir, mungkin dalam spesial kasing - jam untuk hari terakhir: total 24 + 7 + 4 + 12 + tahunan - sekitar 50 salinan untuk setiap server).
Dalam repositori BorgBackup, hanya mode penambahan yang tidak diaktifkan, sebagai gantinya, ForcedCommand digunakan dalam .ssh / authorizedkey tentang kira-kira paket berikut:
from=" ",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......
Pembungkus skrip ditempatkan di atas jalur yang ditentukan di atas borg, yang, selain meluncurkan biner dengan parameter, juga memulai proses memulihkan cadangan setelah data dihapus. Untuk melakukan ini, skrip wrapper membuat file tag di sebelah repositori yang sesuai. Cadangan terakhir yang dibuat setelah proses pengunggahan data secara otomatis dikembalikan ke volume logis yang sesuai.
Desain ini memungkinkan Anda untuk membersihkan cadangan yang tidak perlu secara berkala, dan juga tidak memungkinkan server pertempuran untuk menghapus apa pun di server penyimpanan cadangan.
Proses pencadangan
Pemrakarsa cadangan adalah server khusus itu sendiri atau VPS, karena skema semacam itu memberi lebih banyak kendali atas proses pencadangan dari server ini. Pertama-tama, potret keadaan sistem file root aktif diambil, yang dipasang dan diunggah menggunakan BorgBackup ke server penyimpanan cadangan. Setelah menyelesaikan pengambilan data, gambar dilepas dan dihapus.
Jika ada database kecil (hingga 1 GB untuk setiap situs), dump database dibuat, yang disimpan dalam volume logis yang sesuai, di mana sisa data dari situs yang sama berada, tetapi agar dump tidak dapat diakses melalui server web. Jika databasenya besar, Anda harus mengonfigurasi data mining "panas", misalnya menggunakan xtrabackup untuk MySQL, atau WAL dengan archive_command di PostgreSQL. Dalam hal ini, basis data akan dipulihkan secara terpisah dari situs-situs ini.
Jika wadah atau mesin virtual digunakan, Anda harus mengonfigurasi qemu-guest-agent, CRIU atau teknologi lain yang diperlukan. Dalam kasus lain, pengaturan tambahan paling sering tidak diperlukan - buat saja snapshot dari volume logis, yang kemudian diproses sama dengan snapshot dari keadaan sistem file root. Setelah mengambil data, gambar dihapus.
Pekerjaan lebih lanjut dilakukan pada server penyimpanan cadangan:
- Cadangan terakhir yang dibuat di setiap repositori diperiksa.
- memeriksa file tag yang menunjukkan bahwa proses pengambilan data selesai,
- data sedang diperluas ke volume lokal yang sesuai,
- file tag dihapus
Proses pemulihan server
Jika server utama mati, server khusus serupa diluncurkan, yang diambil dari beberapa gambar standar. Kemungkinan besar, pengunduhan akan dilakukan melalui jaringan, namun teknisi pusat data yang melakukan konfigurasi server dapat segera menyalin gambar standar ini ke salah satu disk. Pengunduhan dilakukan dalam RAM, setelah itu proses pemulihan dimulai:
- permintaan dibuat untuk melampirkan perangkat blok melalui iscsi \ nbd atau protokol serupa lainnya dari volume logis yang berisi sistem file root dari server yang mati; karena sistem file root harus kecil - langkah ini harus diselesaikan dalam beberapa menit. Pemulihan bootloader juga dilakukan;
- struktur volume logis lokal diciptakan kembali, volume logis dilampirkan dari server cadangan menggunakan modul kernel dm_clone: ββpemulihan data dimulai, dan perubahan ditulis segera ke disk lokal
- sebuah wadah diluncurkan dengan semua disk fisik yang tersedia - server sepenuhnya dipulihkan, tetapi dengan kinerja yang berkurang;
- setelah sinkronisasi data selesai, volume logis dari server cadangan terputus, wadah dimatikan, server reboot;
Setelah reboot, server akan memiliki semua data yang ada pada saat cadangan, dan juga termasuk semua perubahan yang dibuat selama proses pemulihan.
Artikel siklus lainnyaCadangan, bagian 1: Mengapa Anda memerlukan cadangan, tinjauan umum metode, teknologi
Cadangan, Bagian 2: Tinjauan Umum dan Pengujian alat pencadangan berbasis rsync
Cadangan, Bagian 3: Gambaran Umum dan Pengujian duplikasi, dupati
Cadangan, Bagian 4: Tinjauan Umum dan Pengujian zbackup, restic, borgbackup
Cadangan, Bagian 5: Menguji Bacula dan Cadangan Veeam untuk Linux
Cadangan: bagian yang diminta oleh pembaca: ulasan AMANDA, UrBackup, BackupPC
Cadangan, Bagian 6: Membandingkan Alat Cadangan
Cadangan Bagian 7: Kesimpulan
Saya mengundang Anda untuk membahas opsi yang diusulkan di komentar, terima kasih atas perhatian Anda!