V aktualizované verzi serveru mám provozní servery realizované jako virtuální stroje, kde má každý dva disky. Jeden je systémový, virtuální qcow2. Druhým diskem každého virtuálního stroje je disk datový, který hypervizor virtuálnímu stroji poskytuje jako blokové zařízení, ať už je to LVM logický disk, nebo odemčený luks kontejner na fyzických discích pro virtualizovaný NAS.

Zálohovat na denní bázi je tedy třeba především datový disk – qcow soubory a konfigurace VM postačí zálohovat občasně.

Původní off-site zálohy mi řešil starý záložní server na vyhrazený HDD – napsala jsem si pro tento účel bash scripty, které se staraly o denní zálohy, jejich rotaci a přípravu pro odkládání na optický, později kvůli přibývajícímu objemu dat na nepřipojený externí disk. Databáze jsem zálohovala pomocí msql-dump utility.

To fungovalo spolehlivě, ovšem struktura dat záloh neumožňovala jednoduchou a rychlou obnovu, hlavně obnovu záloh databází. Zálohy rotovaly na denní bázi, což ale bylo hodně náročné na místo na zálohovacím disku – mohla jsem mít přibližně 10 kompletních záloh, plus jednu měsíc starou na externím disku.

Takže jsem se rozhodla postavit si zálohování zcela znovu, tak, aby v případě nutnosti obnovy postačila krátká sada rsync příkazů.

A rotace záloh? Proč to řešit ručně a datově neefektivně, když existuje BTRFS.

Tenhle souborový systém jsem si poprvé vyzkoušela na prastarém debianu, a moc dobře to nedopadlo. Testovací LVM logický disk jsem naformátovala na btrfs, mountla jsem a začala kopírovat data . Zpočátku vše fungovalo jako vždy, až pak ke konci se mi položil celý stroj. A když říkám položil – tak ve stylu jako že přestal rozumět příkazům jako top, lsblk, dokonce ani shutdown už nepoznával. Odpovídal buď že je nezná, nebo zlověstnými io chybami. Řekla bych, že se cosi rozlezlo skrz swap, který byl u starších linuxů u btrfs problematický, možná něco s pamětí. Jistě, BTRFS na tom starém debianu byl asi hodně experimental, a jeho použití (na vyhrazeném LVM LV) je možná specifické, ale v produkci jsem si experimentování odpustila a šla do zralého ext4.

Dala jsem si další šanci vyzkoušet si BTRFS na novém debianu. Na záložním serveru jsem si vytvořila nový virtuální stroj s Debianem 12, jako datový disk jsem mu svěřila odemčený luks kontejner na fyzickém HDD vyhrazeném pro zálohy. Bylo třeba nainstalovat btrfs nástroje:

apt-get install btrfs-progs

Následně jsem jej naformátovala a vytvořila top subvolume backups. Celé jsem to pak mountla.

mkfs.btrfs /dev/[luksDevice]
btrfs subvolume create backups
fstab: /dev/[luksDevice] /mnt/backupDev/btrfs subvol=backups,defaults,noatime,compress=zstd 0 2

Jednim z argumentů mountu je tedy comprese. Vnitřní struktura tohoto subvolume backups odpovídá jednotlivým produkčním virtuálním strojům, takže obnova dat by byla velmi snadná – prostě nakopírovat to do produkce zpět.

Aby se zálohy odkládaly spolu s originálními právy, je třeba je na zálohovacím stroji spouštět pod rootem, rsync se pak připojuje k zálohovaným strojům pod účtem speciálně vytvořeného usera, který je na cílových členem všech potřebných skupin tak, aby se k datům bez potíží dostal.

Trochu více přemýšlení a mi zabralo hledání výhodnějšího zálohovacího mechanismu databází. Jedním z kandidátů byla úprava mysql-dump scriptu tak, aby se ukládaly všechny databáze na serveru, včetně uživatelů. Jenže výstup logických db záloh je příšerně ukecaný – možná použitelný pro zálohy menších a středních databází, ale pro zálohu mé nejstarší databáze valcMonitoru už naprosto nevhodný, protože některé tabulky v ní mají k dnešku téměř 6 miliónů záznamů. Tohle odkládat a už vůbec ne obnovovat nechcete.

Objevila jsem ale jiný nástroj, který se mi zalíbil: mariabackup, který umí vytvářet rozdílové zálohy celého repository mariadb serveru, krása. Vyzkoušela jsem si to – rozdílová záloha trvá pár vteřin, po tutu dobu server běží dál se zamknutými tabulkami.

Nejdřív tedy instalace nástroje:

apt-get install mariadb-backup

a pak bylo třeba ručně vytvořit první celou zálohu (lokálně na provozním serveru):

mariabackup –backup –rsync –target-dir=/[dbBackup]/ –user=root

Tahle první kompletní záloha trvala několik minut, pořád kratší dobu než mysql-dump. Denně v noci se pak na databázovém serveru spouští script, který vytvoří do adresáře inc rozdílovou zálohu, kterou pak začlení do té kompletní a připraví data v ní přímé použití jako nové repository databázového stroje. Složku inc se změnami je pak třeba smazat. Výstupem tohoto scriptu je tedy offline repository databáze, kterou lze bez dalších cavyků přesunout na zálohovací stroj. Optimalizace spočívá v tom, že kompletní záloha se vytvořila jen jednou, na začátku, denním cronem se pak přesouvají jen změny, což je hotové za zlomek času.

mariabackup –backup –rsync –target-dir=/[dbBackup]/inc/ –incremental-basedir=/[dbBackup]/ –user=root
mariabackup –prepare –target-dir=/[dbBackup]/ –incremental-dir=/[dbBackup]/inc/
rm -r /[dbBackup]/inc/
chown -R mysql:mysql /[dbBackup]/

Mariabackup se mi bohužel nepodařilo rozchodit pod jiným uživatelem než přímo rootem – nevadí, chodí to jen lokálně v rámci daného virtuálního stroje.

Zálohovací script sloužící pro odkládání záloh off-site je spouštěný denně a velmi jednoduchý:

rsync -avz –delete backuper@VM1:/mnt/[prodData] /mnt/backupDev/VM1/
rsync -avz –delete backuper@VM2:/mnt/[prodData]/git/ /mnt/backupDev/VM2/git/
rsync -avz –delete backuper@VM2:/mnt/[prodData]/gogs/ /mnt/backupDev/VM2/gogs/
rsync -avz –delete backuper@VM2:/mnt/[prodData]/www/ /mnt/backupDev/VM2/www/
rsync -avz –delete backuper@VM2:/[dbBackup]/ /mnt/backupDev/VM2/mysql/
rsync -avz –delete backuper@VM3:/var/mail/ /mnt/backupDev/VM3/mail/

Spouštím jej mimochodem skrz výborný nástroj cronic, který omezuje výsledné maily z cronjobů jen na chybové hlášky.

No a poslední by už třeba vyřešit jen denní snapshoty záloh, abych měla k dispozici kompletní zálohy den po dni co nejdéle do minulosti. Za tímto účelem jsem si z git-hubu stáhla jednoduchý sript btrfs-snapshot, který se volán v cronu postará o vytváření snapshotů na denní bázi, očísluje je a bude je rotovat. Do scriptu výše jsem tak přidala další řádek:

cronic ~/btrfs-snapshot.sh /mnt/backupDev daily 30

A je hotovo… BTRFS snapshoty lze prohlížet a dále s nimi pracovat jako s obyčejnými adresáři, velmi elegantní. Data takto pojaté kompletní zálohy mají objem téměř 500GB, ovšem protože btrfs běží s kompresí, dělá to nakonec jen nějakých 140GB. Časem uvidím, jak velkými změnami v datech produkční data denně prochází, a tedy kolik místa mi staré snapshoty zaberou, a podle toho upravím poslední parametr  scriptu btrfs-snapshot.sh tak, abych těch denních záloh měla co nejvíce.

Běžný průchod celého zálohovacího scriptu trvá pár minut, podle objemu změněných dat, které rsync kopíruje či v zálohách maže.

Nová realizace záloh je tedy jednodušší, datově mnohem efektivnější i rychlejší, a případná obnova z těchto záloh by měla být velmi jednoduchá. Zdá se tedy, že mise splněna.

Nechám to běžet, zpočátku to budu průběžně i kontrolovat, a pokud nenarazím na nějaký problém, dovolím si na to zapomenout 🙂

 

 

 

 

 

Další díly seriálu

<< Server 20: konečně SAS řadič a další výzvaServer 22: Výměna základní desky >>