Bagaimana GitLab membantu Anda mencadangkan penyimpanan NextCloud yang besar

Hei Habr!

Hari ini saya ingin berbicara tentang pengalaman kami dalam mengotomatiskan pencadangan data besar dari penyimpanan Nextcloud dalam konfigurasi berbeda. Saya bekerja sebagai stasiun layanan di Molniya AK, tempat kami melakukan manajemen konfigurasi sistem TI; Nextcloud digunakan untuk penyimpanan data. Termasuk, dengan struktur terdistribusi, dengan redundansi.

Permasalahan yang timbul pada fitur instalasinya adalah data yang banyak. Pembuatan versi yang disediakan oleh Nextcloud, redundansi, alasan subjektif, dan banyak lagi menciptakan banyak duplikat.

prasejarah

Saat mengelola Nextcloud, muncul masalah dalam mengatur cadangan yang efektif, yang harus dienkripsi, karena datanya berharga.

Kami menawarkan opsi untuk menyimpan cadangan di tempat kami atau di komputer pelanggan pada mesin terpisah dari Nextcloud, yang memerlukan pendekatan otomatis yang fleksibel dalam administrasi.

Ada banyak klien, semuanya dengan konfigurasi berbeda, dan semuanya ada di situsnya sendiri dan dengan karakteristiknya sendiri. Ini adalah teknik standar ketika seluruh situs adalah milik Anda, dan cadangan dibuat dari mahkota; ini tidak cocok.

Pertama, mari kita lihat data masukannya. Kita butuh:

• Skalabilitas dalam hal satu atau beberapa node. Untuk instalasi besar kami menggunakan minio sebagai penyimpanan.
• Cari tahu tentang masalah dalam melakukan pencadangan.
• Anda perlu menyimpan cadangan dengan klien Anda dan/atau bersama kami.
• Mengatasi masalah dengan cepat dan mudah.
• Klien dan instalasi sangat berbeda satu sama lain - keseragaman tidak dapat dicapai.
• Kecepatan pemulihan harus minimal dalam dua skenario: pemulihan penuh (bencana), satu folder terhapus secara tidak sengaja.
• Fungsi deduplikasi diperlukan.

Untuk mengatasi masalah pengelolaan cadangan, kami menginstal GitLab. Lebih detail dengan tekel.

Tentu saja, kami bukan orang pertama yang memecahkan masalah seperti itu, namun tampaknya pengalaman praktis yang kami peroleh dengan susah payah bisa menarik dan kami siap membagikannya.

Karena perusahaan kami memiliki kebijakan sumber terbuka, kami mencari solusi sumber terbuka. Pada gilirannya, kami membagikan perkembangan kami dan mempostingnya. Misalnya di GitHub ada plugin kami untuk Nextcloud, yang kami berikan kepada klien, meningkatkan keamanan data jika terjadi penghapusan yang tidak disengaja atau disengaja.

Alat cadangan

Kami memulai pencarian metode solusi dengan memilih alat pembuatan cadangan.

Tar + gzip biasa tidak berfungsi dengan baik - datanya terduplikasi. Peningkatan sering kali hanya berisi sedikit perubahan aktual, dan sebagian besar data dalam satu file diulang.
Ada masalah lain - redundansi penyimpanan data terdistribusi. Kami menggunakan minio dan datanya pada dasarnya mubazir. Atau Anda harus membuat cadangan melalui minio itu sendiri - memuatnya dan menggunakan semua spacer antara sistem file, dan, yang tidak kalah pentingnya, ada risiko melupakan beberapa keranjang dan informasi meta. Atau gunakan deduplikasi.

Alat pencadangan dengan duplikasi tersedia dalam sumber terbuka (di Habré ada Artikel tentang hal ini) dan finalis kami adalah Borg и Istirahat. Perbandingan kami terhadap kedua aplikasi ada di bawah, tetapi untuk saat ini kami akan memberi tahu Anda bagaimana kami mengatur keseluruhan skema.

Mengelola cadangan

Borg dan Restic bagus, tetapi tidak ada produk yang memiliki mekanisme kontrol terpusat. Untuk tujuan manajemen dan pengendalian, kami memilih alat yang telah kami terapkan, yang tanpanya kami tidak dapat membayangkan pekerjaan kami, termasuk otomatisasi - ini adalah CI/CD yang terkenal - GitLab.

Idenya adalah sebagai berikut: gitlab-runner diinstal pada setiap node yang menyimpan data Nextcloud. Pelari menjalankan skrip sesuai jadwal yang memantau proses pencadangan, dan meluncurkan Borg atau Restic.

Apa yang kami dapatkan? Umpan balik dari eksekusi, kontrol mudah atas perubahan, detail jika terjadi kesalahan.

di sini adalah di sini di GitHub kami memposting contoh skrip untuk berbagai tugas, dan kami akhirnya melampirkannya ke cadangan tidak hanya Nextcloud, tetapi juga banyak layanan lainnya. Ada juga penjadwal di sana jika Anda tidak ingin mengkonfigurasinya secara manual (dan kami tidak mau) dan .gitlab-ci.yml

Belum ada cara untuk mengubah batas waktu CI/CD di API Gitlab, tetapi ini kecil. Perlu ditingkatkan, katakanlah 1d.

Untungnya, GitLab dapat diluncurkan tidak hanya berdasarkan komitmen, tetapi hanya sesuai jadwal, inilah yang kami butuhkan.

Sekarang tentang skrip pembungkus.

Kami menetapkan ketentuan berikut untuk skrip ini:

• Ini harus diluncurkan oleh pelari dan dengan tangan dari konsol dengan fungsi yang sama.
• Harus ada penangan kesalahan:
• kode kembali.
• mencari string di log. Misalnya, bagi kami, kesalahan mungkin merupakan pesan yang tidak dianggap fatal oleh program.
• Batas waktu pemrosesan habis. Waktu tunggu harus masuk akal.
• Kami membutuhkan log yang sangat detail. Tapi hanya jika terjadi kesalahan.
• Sejumlah tes juga dilakukan sebelum memulai.
• Bonus kecil untuk kenyamanan yang menurut kami berguna selama proses dukungan:
• Awal dan akhir dicatat dalam syslog mesin lokal. Ini membantu untuk menghubungkan kesalahan sistem dan operasi cadangan.
• Bagian dari log kesalahan, jika ada, dikeluarkan ke stdout, seluruh log ditulis ke file terpisah. Akan lebih mudah untuk segera melihat CI dan mengevaluasi kesalahannya jika kesalahannya sepele.
• Mode debug.

Log lengkap disimpan sebagai artefak di GitLab; jika tidak ada kesalahan, log akan dihapus. Kami menulis skrip di bash.

Kami akan dengan senang hati mempertimbangkan saran dan komentar apa pun mengenai open source - selamat datang.

Bagaimana itu bekerja

Pelari dengan pelaksana Bash diluncurkan pada node cadangan. Menurut penjadwal, pekerjaan CI/CD diluncurkan dalam lobak khusus. Pelari meluncurkan skrip pembungkus universal untuk tugas-tugas tersebut, ia memeriksa validitas repositori cadangan, titik pemasangan, dan semua yang kita inginkan, lalu mencadangkan dan membersihkan yang lama. Cadangan yang sudah selesai dikirim ke S3.

Kami bekerja sesuai dengan skema ini - ini adalah penyedia AWS eksternal atau setara dengan Rusia (lebih cepat dan data tidak meninggalkan Federasi Rusia). Atau kami memasang cluster minio terpisah untuk klien di situsnya untuk tujuan ini. Kami biasanya melakukan ini untuk alasan keamanan, ketika klien tidak ingin data meninggalkan sirkuitnya sama sekali.

Kami tidak menggunakan fitur pengiriman backup melalui ssh. Ini tidak menambah keamanan, dan kemampuan jaringan penyedia S3 jauh lebih tinggi daripada mesin ssh kami.

Untuk melindungi mesin lokal Anda dari peretas, karena ia dapat menghapus data di S3, Anda harus mengaktifkan pembuatan versi.
Cadangan selalu mengenkripsi cadangan.

Borg memiliki mode tidak terenkripsi none, namun kami sangat tidak menyarankan untuk mengaktifkannya. Dalam mode ini, tidak hanya tidak ada enkripsi, tetapi checksum dari apa yang ditulis tidak dihitung, yang berarti integritas hanya dapat diperiksa secara tidak langsung, menggunakan indeks.

Penjadwal terpisah memeriksa cadangan untuk integritas indeks dan konten. Pengecekannya lambat dan lama, jadi kami menjalankannya secara terpisah sebulan sekali. Mungkin memerlukan waktu beberapa hari.

Baca saya dalam bahasa Rusia

Fungsi utama

• prepare latihan
• testcheck pemeriksaan kesiapan
• maincommand Tim inti
• forcepostscript fungsi yang dijalankan pada akhirnya atau karena kesalahan. Kami menggunakannya untuk meng-unmount partisi.

Fungsi layanan

• cleanup Kami mencatat kesalahan atau menghapus file log.
• checklog parsing log untuk terjadinya baris dengan kesalahan.
• ret pengendali keluar.
• checktimeout periksa batas waktu.

Lingkungan Hidup

• VERBOSE=1 Kami segera menampilkan kesalahan di layar (stdout).
• SAVELOGSONSUCCES=1 simpan log setelah berhasil.
• INIT_REPO_IF_NOT_EXIST=1 Buat repositori jika tidak ada. Dinonaktifkan secara default.
• TIMEOUT waktu maksimum untuk operasi utama. Anda dapat mengaturnya sebagai 'm', 'h' atau 'd' di akhir.

Mode penyimpanan untuk salinan lama. Bawaan:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Variabel di dalam skrip

• ERROR_STRING — string untuk log check-in untuk kesalahan.
• EXTRACT_ERROR_STRING — ekspresi untuk menampilkan string jika terjadi kesalahan.
• KILL_TIMEOUT_SIGNAL — sinyal untuk mematikan jika waktu habis.
• TAIL — berapa banyak string dengan kesalahan di layar.
• COLORMSG — warna pesan (kuning default).

Script yang namanya wordpress itu punya nama conditional, triknya juga membackup database mysql. Artinya, ini dapat digunakan untuk instalasi Nexcloud node tunggal, di mana Anda juga dapat membuat cadangan database. Kenyamanannya tidak hanya semuanya ada di satu tempat, tetapi isi database juga dekat dengan isi file, karena perbedaan waktu yang minimal.

Istirahat vs Borg

Ada juga perbandingan antara Borg dan Restic di sini di Habré, dan tugas kami bukan hanya membuat yang lain, melainkan tugas kami sendiri. Penting bagi kami bagaimana tampilannya pada data kami, dengan spesifikasi kami. Kami membawa mereka.

Kriteria pemilihan kami, selain yang telah disebutkan (deduplikasi, pemulihan cepat, dll.):

• Resistensi terhadap pekerjaan yang belum selesai. Periksa pembunuhan -9.
• Ukuran pada disk.
• Persyaratan sumber daya (CPU, memori).
• Ukuran gumpalan yang disimpan.
• Bekerja dengan S3.
• Pemeriksaan integritas.

Untuk pengujian, kami mengambil satu klien dengan data nyata dan ukuran total 1,6 TB.
Kondisi.

Borg tidak tahu cara bekerja secara langsung dengan S3, dan kami memasang disk sebagai sekering, via konyol. Restic mengirimkannya ke S3 sendiri.

Goofys bekerja dengan sangat cepat dan baik, dan memang ada modul cache disk, yang semakin mempercepat pekerjaan. Ini masih dalam tahap beta, dan sejujurnya, kami mengalami crash karena kehilangan data selama pengujian (yang lain). Namun kemudahannya adalah prosedur pencadangan itu sendiri tidak memerlukan banyak membaca, tetapi kebanyakan menulis, jadi kami menggunakan cache hanya selama pemeriksaan integritas.

Untuk mengurangi pengaruh jaringan, kami menggunakan penyedia lokal - Yandex Cloud.

Hasil pengujian perbandingan.

• Bunuh -9 dengan restart lebih lanjut keduanya berhasil.
• Ukuran pada disk. Borg bisa dikompres, sehingga hasilnya sesuai dengan yang diharapkan.

Pencadangan
Ukuran

Borg
562Gb

Istirahat
628Gb

• Oleh CPU
  Borg sendiri mengkonsumsi sedikit, dengan kompresi default, tetapi harus dievaluasi bersamaan dengan proses goofys. Secara total, keduanya sebanding dan menggunakan sekitar 1,2 core pada mesin virtual pengujian yang sama.
• Penyimpanan. Restic kira-kira 0,5GB, Borg kira-kira 200MB. Tapi ini semua tidak signifikan dibandingkan dengan cache file sistem. Jadi disarankan untuk mengalokasikan lebih banyak memori.
• Perbedaan ukuran gumpalan sangat mencolok.

Pencadangan
Ukuran

Borg
sekitar 500MB

Istirahat
sekitar 5MB

• Pengalaman S3 Restic luar biasa. Bekerja dengan Borg melalui goofys tidak menimbulkan pertanyaan apa pun, tetapi telah dicatat bahwa disarankan untuk melakukan umount setelah pencadangan selesai untuk mengatur ulang cache sepenuhnya. Keunikan S3 adalah bongkahan yang kurang terpompa tidak akan pernah dikirim ke bucket, yang berarti data yang tidak diisi secara lengkap akan menyebabkan kerusakan besar.
• Pemeriksaan integritas berfungsi dengan baik dalam kedua kasus, namun kecepatannya berbeda secara signifikan.
  Istirahat 3,5 jam.
  Borg, dengan cache file SSD 100GB – Jam 5.Hasil kecepatannya kurang lebih sama jika datanya ada di disk lokal.
  Borg membaca langsung dari S3 tanpa cache 33 jam. Sangat panjang.

Intinya adalah Borg dapat mengompresi dan memiliki blob yang lebih besar - yang membuat penyimpanan dan operasi GET/PUT di S3 lebih murah. Namun hal ini harus dibayar dengan verifikasi yang lebih rumit dan lambat. Mengenai kecepatan pemulihan, kami tidak melihat adanya perbedaan. Restic membutuhkan pencadangan berikutnya (setelah yang pertama) sedikit lebih lama, tetapi tidak secara signifikan.

Pilihan terakhir yang tidak kalah pentingnya adalah ukuran komunitas.

Dan kami memilih borg.

Beberapa kata tentang kompresi

Borg memiliki algoritma kompresi baru yang luar biasa - zstd. Kualitas kompresinya tidak lebih buruk dari gzip, tetapi jauh lebih cepat. Dan kecepatannya sebanding dengan lz4 default.

Misalnya, dump database MySQL dikompresi dua kali lebih baik dari lz4 dengan kecepatan yang sama. Namun, pengalaman dengan data nyata menunjukkan bahwa terdapat sedikit perbedaan dalam rasio kompresi node Nextcloud.

Borg memiliki mode kompresi yang lebih bonus - jika file memiliki entropi tinggi, maka kompresi tidak diterapkan sama sekali, sehingga meningkatkan kecepatan. Diaktifkan berdasarkan opsi saat membuat
-C auto,zstd
untuk algoritma zstd
Jadi dengan opsi ini, dibandingkan dengan kompresi default, kami mendapatkannya
masing-masing 560Gb dan 562Gb. Data dari contoh di atas, izinkan saya mengingatkan Anda, tanpa kompresi hasilnya adalah 628Gb. Hasil perbedaan 2GB agak mengejutkan kami, namun kami berpikir bahwa kami akan tetap memilihnya. auto,zstd.

Metode verifikasi cadangan

Menurut penjadwal, mesin virtual diluncurkan langsung dari penyedia atau dari klien, yang sangat mengurangi beban jaringan. Setidaknya ini lebih murah daripada membesarkannya sendiri dan mengarahkan lalu lintas.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Dengan menggunakan skema yang sama, kami memeriksa file dengan antivirus (setelah faktanya). Lagi pula, pengguna mengunggah berbagai hal ke Nextcloud dan tidak semua orang memiliki antivirus. Melakukan pemeriksaan pada saat penuangan memakan waktu terlalu lama dan mengganggu usaha.

Skalabilitas dicapai dengan menjalankan runner pada node berbeda dengan tag berbeda.
Pemantauan kami mengumpulkan status cadangan melalui API GitLab dalam satu jendela; jika perlu, masalah mudah diketahui dan dilokalisasi dengan mudah.

Kesimpulan

Hasilnya, kami tahu pasti bahwa kami membuat cadangan, bahwa cadangan kami valid, masalah yang timbul dengannya hanya membutuhkan sedikit waktu dan diselesaikan di tingkat administrator yang bertugas. Cadangan hanya memakan sedikit ruang dibandingkan dengan tar.gz atau Bacula.

Sumber: www.habr.com