Yang mengejutkan kami, tidak ada satu bahan pun tentang alat Open Source yang hebat untuk cadangan data -
Borg (jangan dikelirukan dengan nenek moyang dari nama yang sama Kubernet!) . Karena kami telah menggunakannya dalam produksi selama lebih dari setahun, dalam artikel ini saya akan membagikan "kesan" yang kami dapatkan tentang Borg.
Latar Belakang: Pengalaman dengan Bacula dan Bareos
Pada tahun 2017, kami bosan dengan Bacula dan Bareos, yang kami gunakan sejak awal kegiatan kami (yaitu, sekitar 9 tahun dalam produksi pada waktu itu). Mengapa Selama operasi, kami telah mengumpulkan banyak ketidakpuasan:
- SD (Storage Daemon) membeku. Jika Anda telah mengkonfigurasi paralelisme, maka perawatan SD menjadi lebih rumit, dan pembekuannya akan memblokir cadangan lebih lanjut sesuai jadwal dan kemungkinan pemulihan.
- Diperlukan untuk membuat konfigurasi untuk klien dan direktur. Bahkan jika kita mengotomatiskan ini (dalam kasus kami, Chef, Ansible, dan pengembangan kami digunakan pada waktu yang berbeda), kita perlu memantau bahwa sutradara, setelah memuat ulang, benar-benar mengambil konfigurasi. Ini hanya dilacak pada output perintah reload dan setelah panggilan pesan (untuk mendapatkan teks kesalahan itu sendiri).
- Jadwalkan cadangan. Pengembang Bacula memutuskan untuk bertindak sendiri dan menulis format jadwal mereka sendiri, yang tidak dapat Anda parsing atau ubah ke yang lain. Berikut adalah contoh jadwal cadangan standar di instalasi lama kami:
- Cadangan penuh harian pada hari Rabu dan tambahan pada hari-hari lain:
Run = Level=Full Pool="Foobar-low7" wed at 18:00
Run = Level=Incremental Pool="Foobar-low7" at 18:00 - Cadangan penuh file wal 2 kali sebulan dan setiap jam bertambah:
Run = Level=Full FullPool=CustomerWALPool 1st fri at 01:45
Run = Level=Full FullPool=CustomerWALPool 3rd fri at 01:45
Run = Level=Incremental FullPool=CustomerWALPool IncrementalPool=CustomerWALPool on hourly schedule dihasilkan untuk semua kesempatan (pada hari yang berbeda dalam seminggu setiap 2 jam) kami dapatkan sekitar 1665 ... karena apa yang Bacula / Bareos secara berkala menjadi gila.
- Bacula-fd (dan bareos-fd) memiliki direktori dengan banyak data (katakanlah 40 TB, yang 35 TB berisi file besar [100+ MB], dan 5 TB sisanya berisi file kecil [1 KB hingga 100 MB ]) kebocoran memori lambat dimulai, yang merupakan situasi yang sangat tidak menyenangkan pada produksi.
- Pada cadangan dengan sejumlah besar file, Bacula dan Bareos sangat tergantung pada kinerja DBMS yang digunakan. Drive apa yang dimilikinya? Seberapa terampil Anda tahu bagaimana menyesuaikannya dengan kebutuhan khusus ini? Dan dalam database, omong-omong, satu (!) Tabel non-partisi dibuat dengan daftar semua file di semua cadangan dan yang kedua - dengan daftar semua jalur di semua cadangan. Jika Anda belum siap untuk mengalokasikan setidaknya 8 GB RAM untuk basis + 40 GB SSD untuk server cadangan Anda - segera bersiaplah untuk rem.
- Ketergantungan database layak mendapat satu poin lagi. Bacula / Bareos untuk setiap file bertanya kepada direktur apakah sudah ada file seperti itu. Direktur, tentu saja, merangkak ke dalam database, ke dalam tabel-tabel yang sangat besar ... Ternyata cadangan dapat diblokir hanya dengan fakta bahwa beberapa cadangan berat dimulai pada saat yang sama - bahkan jika perbedaannya adalah beberapa megabyte di sana.
Tidak adil untuk mengatakan bahwa tidak ada masalah yang terpecahkan sama sekali, tetapi kami sampai pada titik di mana kami benar-benar lelah dengan berbagai solusi dan menginginkan solusi yang andal "di sini dan sekarang."
Bacula / Bareos bekerja dengan baik dengan sejumlah kecil (10-30) pekerjaan yang seragam. Apakah ada hal kecil yang pecah seminggu sekali? Tidak apa-apa: mereka memberikan tugas kepada petugas jaga (atau insinyur lain) - mereka memperbaikinya. Namun, kami memiliki proyek di mana jumlah pekerjaan dalam ratusan, dan jumlah file di dalamnya adalah ratusan ribu. Akibatnya, 5 menit seminggu untuk memperbaiki cadangan (tidak termasuk beberapa jam pengaturan sebelum ini) mulai bertambah banyak. Semua ini mengarah pada fakta bahwa 2 jam sehari itu perlu untuk memperbaiki cadangan di semua proyek, karena secara harfiah di mana-mana ada sesuatu yang sepele atau serius rusak.
Kemudian seseorang mungkin berpikir bahwa seorang insinyur yang berdedikasi untuk hal ini harus melakukan pencadangan. Tentu saja, dia akan berjanggut dan seberat mungkin, dan dari penampilannya, cadangan diperbaiki secara instan, sementara dia dengan tenang menyeruput kopi. Dan ide ini mungkin benar dalam beberapa cara ... Tapi selalu ada tapi. Tidak semua orang mampu memperbaiki dan memantau cadangan sepanjang waktu, dan bahkan lebih - seorang insinyur yang dialokasikan untuk tujuan ini. Kami yakin bahwa lebih baik menghabiskan 2 jam sehari ini untuk sesuatu yang lebih produktif dan berguna. Oleh karena itu, kami beralih ke mencari solusi alternatif yang “hanya berfungsi”.
Borg sebagai cara baru
Pencarian untuk opsi Open Source lainnya tersebar dari waktu ke waktu, sehingga sulit untuk memperkirakan total biaya, tetapi pada satu titik (tahun lalu), perhatian kami beralih ke "
pahlawan acara" -
BorgBackup (atau hanya Borg). Sebagian, ini difasilitasi oleh pengalaman nyata penggunaannya oleh salah satu insinyur kami (di tempat kerja sebelumnya).
Borg ditulis dalam Python (versi> = 3.4.0 diperlukan), dan kode yang menuntut kinerja (kompresi, enkripsi, dll.) Diimplementasikan dalam C / Cython. Didistribusikan di bawah lisensi BSD gratis (3-klausa). Ini mendukung banyak platform termasuk Linux, * BSD, macOS, serta pada tingkat eksperimental Cygwin dan Linux Subsystem Windows 10. Untuk menginstal BorgBackup, paket tersedia untuk distribusi Linux populer dan OS lainnya, serta kode sumber, yang juga dapat diinstal melalui pip, - informasi lebih rinci tentang ini dapat ditemukan dalam
dokumentasi proyek .
Mengapa Borg menyuap kami begitu banyak? Berikut ini keunggulan utamanya:
Transisi ke Borg dimulai perlahan pada proyek-proyek kecil. Pada awalnya, ini adalah skrip cron sederhana yang melakukan pekerjaan mereka setiap hari. Ini berlangsung selama sekitar enam bulan. Selama waktu ini, kami harus mendapatkan backup berkali-kali ... dan ternyata Borg tidak harus diperbaiki sama sekali! Mengapa Karena prinsip sederhana bekerja di sini: "Semakin sederhana mekanismenya, semakin sedikit tempat di mana ia akan hancur."
Latihan: bagaimana cara membuat cadangan dengan Borg?
Pertimbangkan contoh sederhana membuat cadangan:
- Unduh binary rilis terbaru ke server cadangan dan mesin yang akan kami cadangkan dari repositori resmi :
sudo wget https://github.com/borgbackup/borg/releases/download/1.1.6/borg-linux64 -O /usr/local/bin/borg sudo chmod +x /usr/local/bin/borg
Catatan : Jika Anda menggunakan mesin lokal untuk pengujian baik sebagai sumber dan sebagai penerima, maka seluruh perbedaan hanya akan ada di URI, yang akan kami sampaikan, tetapi kami ingat bahwa cadangan tersebut perlu disimpan secara terpisah, dan bukan pada mesin yang sama. - Di server cadangan, buat pengguna
borg :
sudo useradd -m borg
Sederhana: tanpa grup dan dengan shell standar, tetapi selalu dengan direktori home. - Kunci SSH dihasilkan pada klien:
ssh-keygen
- Di server, tambahkan kunci yang dihasilkan ke pengguna
borg :
mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh local / bin / borg melayani" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf / XmSVWfF7PfjGlbKW00MJ63zal / E / mxm + vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU / JNU0jITLx + vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk / QmteOOclzx684t9d6BhMvFE9w9r + c76aVBIdbEyrkloiYd + vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44 / Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam + 9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y + IQM7fbDR'> ~ borg / .ssh mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh
- Kami menginisialisasi repo borg di server dari klien:
ssh borg@172.17.0.3 hostname
Switch -e digunakan untuk memilih metode enkripsi untuk repositori (ya, Anda juga dapat mengenkripsi setiap repositori dengan kata sandi Anda!). Dalam hal ini, karena ini adalah contoh, kami tidak menggunakan enkripsi. MyBorgRepo adalah nama direktori di mana borg repo akan berada (Anda tidak perlu membuatnya di muka - Borg akan melakukan semuanya sendiri). - Luncurkan cadangan pertama menggunakan Borg:
borg create --stats --list borg@172.17.0.3:MyBorgRepo::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" /etc /root
Tentang kunci:
--stats dan --list memberi kami statistik tentang cadangan dan file yang masuk ke dalamnya;borg@172.17.0.3:MyBorgRepo - semuanya jelas di sini, ini adalah server dan direktori kami. Dan untuk sihir apa selanjutnya?::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" adalah nama arsip di dalam repositori. Ini arbitrer, tetapi kami mematuhi format _-timestamp (timestamp dalam format Python).
Apa selanjutnya Tentu saja, lihat apa yang masuk ke cadangan kami! Daftar arsip di dalam repositori:
borg@b3e51b9ed2c2:~$ borg list MyBorgRepo/ Warning: Attempting to access a previously unknown unencrypted repository! Do you want to continue? [yN] y MyFirstBackup-2018-08-04_16:55:53 Sat, 2018-08-04 16:55:54 [89f7b5bccfb1ed2d72c8b84b1baf477a8220955c72e7fcf0ecc6cd5a9943d78d]
Kami melihat cadangan dengan cap waktu dan bagaimana Borg bertanya kepada kami apakah kami benar-benar ingin mengakses repositori yang tidak dienkripsi yang belum pernah kami kunjungi sebelumnya.
Kami melihat daftar file:
borg list MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53
Kami mendapatkan file dari cadangan (Anda juga dapat seluruh direktori):
borg@b3e51b9ed2c2:~$ borg extract MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 etc/hostname borg@b3e51b9ed2c2:~$ ll etc/hostname -rw-r--r-- 1 borg borg 13 Aug 4 16:27 etc/hostname
Selamat, cadangan Borg pertama Anda siap!
Latihan: mengotomatiskan ini [dengan GitLab]!
Setelah membungkus semua ini dalam skrip, kami mengkonfigurasi cadangan secara manual dengan cara yang mirip pada sekitar 40 host. Menyadari bahwa Borg benar-benar berfungsi, mereka mulai mentransfer lebih banyak dan lebih banyak proyek ke sana ...
Dan di sini kita dihadapkan dengan apa yang ada di Bareos, tetapi tidak di Borg! Yaitu: WebUI atau semacam tempat terpusat untuk mengonfigurasi cadangan. Dan kami sangat berharap ini adalah fenomena sementara, tetapi sejauh ini kami harus menyelesaikan sesuatu. Menelusuri alat-alat yang sudah jadi dan berkumpul di konferensi video, kami mulai berbisnis. Ada ide bagus untuk mengintegrasikan Borg dengan layanan internal kami, seperti yang kami lakukan sebelumnya dengan Bacula (Bacula sendiri mengambil daftar pekerjaan dari API kami yang terpusat, yang mana kami memiliki antarmuka kami sendiri terintegrasi dengan pengaturan proyek lainnya). Kami memikirkan cara melakukannya, menguraikan rencana bagaimana dan di mana membangunnya, tapi ... Cadangan normal diperlukan sekarang, tetapi tidak ada tempat untuk mengambil rencana waktu muluk. Apa yang harus dilakukan
Pertanyaan dan persyaratan kira-kira sebagai berikut:
- Apa yang harus digunakan sebagai manajemen cadangan terpusat?
- Apa yang bisa dilakukan oleh administrator Linux?
- Apa yang bahkan dapat dipahami dan dikonfigurasikan oleh manajer yang menunjukkan jadwal cadangan kepada pelanggan?
- Apa yang tugas terjadwal lakukan pada sistem Anda setiap hari?
- Apa yang tidak akan sulit untuk dikonfigurasi dan tidak akan rusak? ..
Jawabannya jelas: ini adalah kain tua yang bagus, yang dengan gagah berani melakukan tugasnya setiap hari. Sederhana Itu tidak membeku. Bahkan manajer yang dari Unix ke "Anda" dapat memperbaikinya.
Jadi crontab, tapi di mana Anda menyimpan semua ini? Apakah setiap kali pergi ke mesin proyek dan mengedit file dengan tangan Anda? Tentu saja tidak. Kita dapat menempatkan jadwal kita di repositori Git dan mengkonfigurasi GitLab Runner, yang dengan komit akan memperbaruinya di host.
Catatan : GitLab yang dipilih sebagai alat otomatisasi, karena nyaman untuk tugas dan dalam kasus kami hampir di mana-mana. Tetapi saya harus mengatakan bahwa dia sama sekali bukan keharusan.Anda dapat memperluas crontab untuk cadangan dengan alat otomasi yang sudah dikenal atau umumnya secara manual (pada proyek kecil atau instalasi rumah).
Jadi, inilah yang Anda butuhkan untuk otomatisasi sederhana:
1.
GitLab dan repositori , di mana untuk memulai akan ada dua file:
schedule - jadwal cadanganborg_backup_files.sh - skrip sederhana untuk membuat cadangan file (seperti pada contoh di atas).
Contoh
schedule :
Variabel CI digunakan untuk memverifikasi bahwa pembaruan crontab berhasil, dan
CI_PROJECT_DIR adalah direktori di mana repositori akan setelah mengkloning pelari. Baris terakhir menunjukkan bahwa pencadangan dilakukan setiap hari pada tengah malam.
Contoh
borg_backup_files.sh :
Argumen
pertama di sini adalah nama cadangan, dan yang
kedua adalah daftar direktori untuk cadangan, dipisahkan dengan koma. Sebenarnya, daftar juga dapat berupa kumpulan file terpisah.
2.
GitLab Runner , berjalan pada mesin yang perlu dicadangkan, dan diblokir hanya untuk pekerjaan repositori ini.
3.
Script CI itu sendiri , diimplementasikan oleh file
.gitlab-ci.yml :
stages: - deploy Deploy: stage: deploy script: - export TIMESTAMP=$(date '+%Y.%m.%d %H:%M:%S') - cat schedule | envsubst | crontab - tags: - borg-backup
4.
Kunci SSH untuk pengguna
gitlab-runner dengan akses ke server
gitlab-runner (dalam contoh, adalah 10.100.1.1). Secara default, ini harus di direktori home
.ssh/id_rsa (
gitlab-runner ).
5.
Pengguna borg pada 10.100.1.1 yang sama dengan akses hanya ke perintah
borg serve :
$ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAA...
Sekarang, ketika Anda komit ke repositori Runner, itu akan mengisi konten crontab. Dan ketika waktu respons cron tiba, cadangan dari direktori
/etc dan
/opt akan dilakukan, yang akan berada di server cadangan di direktori
MyHostname-SYSTEM server 10.100.1.1.
Alih-alih kesimpulan: apa lagi yang bisa Anda lakukan?
Penggunaan Borg pada ini, tentu saja, tidak berakhir di sana. Berikut adalah beberapa ide untuk implementasi lebih lanjut, beberapa di antaranya telah kami terapkan di rumah:
- Tambahkan skrip universal untuk cadangan berbeda, yang pada akhir eksekusi dijalankan
borg_backup_files.sh , ditujukan pada direktori dengan hasil pekerjaan mereka. Misalnya, Anda dapat mencadangkan PostgreSQL (pg_basebackup), MySQL (innobackupex), GitLab (pekerjaan menyapu bawaan, membuat arsip). - Tuan rumah pusat dengan jadwal untuk cadangan . Tidak mengkonfigurasi pada setiap host GitLab Runner? Biarkan saja di server cadangan, dan crontab saat startup mentransfer skrip cadangan ke mesin dan menjalankannya di sana. Untuk ini, tentu saja, Anda akan memerlukan pengguna
borg di mesin klien dan ssh-agent , agar tidak meletakkan kunci ke server cadangan di setiap mesin. - Pemantauan Di mana tanpa dia! Lansiran tentang cadangan yang salah diselesaikan harus.
- Membersihkan repositori borg dari arsip lama. Meskipun ada deduplikasi yang baik, backup lama masih harus dibersihkan. Untuk melakukan ini, Anda dapat melakukan panggilan ke
borg prune di akhir skrip cadangan. - Antarmuka web dengan jadwal. Ini akan berguna jika mengedit crontab dengan tangan atau di antarmuka web tidak terlihat solid / tidak nyaman untuk Anda.
- Pie chart . Beberapa grafik untuk representasi visual dari persentase cadangan yang berhasil diselesaikan, waktu pelaksanaannya, lebar saluran "yang dimakan". Tidak heran saya menulis bahwa tidak ada cukup WebUI, seperti di Bareos ...
- Tindakan sederhana yang ingin saya terima dengan tombol: meluncurkan cadangan sesuai permintaan, memulihkan ke mesin, dll.
Dan pada akhirnya, saya ingin menambahkan contoh efektivitas deduplikasi pada cadangan kerja nyata file-file WAL PostgreSQL dalam lingkungan produksi:
borg@backup ~ $ borg info PROJECT-PG-WAL Repository ID: 177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Location: /mnt/borg/PROJECT-PG-WAL Encrypted: No Cache: /mnt/borg/.cache/borg/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Security dir: /mnt/borg/.config/borg/security/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 6.68 TB 6.70 TB 19.74 GB Unique chunks Total chunks Chunk index: 11708 3230099
Ini adalah 65 hari cadangan file WAL yang dilakukan setiap jam. Saat menggunakan Bacula / Bareos, mis. tanpa deduplikasi, kami akan mendapatkan 6,7 TB data. Bayangkan saja: kita mampu menyimpan hampir 7 terabyte data yang dilewatkan melalui PostgreSQL, hanya 20 GB ruang yang benar-benar terisi.
PS
Baca juga di blog kami: