Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data
Používám Bareos.
Ad 1) nemám zkušenost, ale nevidím v tom sílu bareosu.
Ad 2.1) bez problému, fs zálohuju s vyloučením datového adresáře PG, v nezávislém jobu mám script na dump po jednotlivých databázích (pro obnovu je to lepší, než pgdumpall); lze nastavit zálohování base+wal, bylo by to asi i lepší, ale u toho bych považoval za nutné naplánovat pravidelné testy obnovitelnosti, a to se mi nechtělo.
Ad 2.2) obdobně, script, který ve smyčce dumpuje databázi po databázi.
Ad 2.3) bez problémů, jen pokud chcete zálohovat i extended attributes, hlásí čas od času warningy.
Dobrou zkušenost mám s tím, že bareos provede zálohu rychle, efektivně, a při použití jeho interní lzo komprese, tak i s malým objemem dat.
Pak mám speciální případy, např. stroj, kde je několik TB fotek, a kde zákazník nemá požadavek na archivaci stavu X dní, stačí mu poslední záloha (archiv má u sebe), tam mám v jobu nastavený na dané adresáře rsync. Rsync pak dělám na ZFS s nastavenou deduplikací, protože některé fotky se opakují (dosahuji efektivity uložení 1:1,2) Takže job nejprve spustí rsync, a po něm udělá klasicky zálohu zbytku OS.
Jako slabiny vidím menší stabilitu bareosu, chybějící deduplikaci (dedup by base jobs mi moc nepomáhá), složité nastavování retence dat, a aktuálně má bug při restore, pokud máte datasety nastavené do různých adresářů (pokud je máte v jednom, je to bez problémů).
Retence dat se dá nastavit přes datasety, ale je potřeba přemýšlet o tom, jak velký bude jednotlivý soubor vs. retence dat v něm. Dá se očekávat, že na full zálohách budete potřebovat delší retenci, na inkrementech kratší. Pokud oba druhy zálohy skončí ve stejném datasetu, tak nemá možnost se uvolnit a de facto bude data držet tak dlouhou dobu, dokud nevyexspiruje i full.
Dost nepohodlné je konfigurování plánovače. Pokud máte víc strojů k zálohování, budete patrně chtít, aby full zálohy neběžely ve stejný den, ale rozložily se. Pak musíte na každý job nadefinovat i vlastní schedule, ale konfigurace není moc čitelná, takže si musíte vést evidenci bokem, třeba v excelu.
Nižsí stabilita bareosu se někdy projevuje v nekonzistentním stavu jeho databáze - není to žádná tragedie, ale když zrovna potřebujete obnovit soubor, a musíte začít řešit i toto, je to ke vzteku.
Za slabinu považuji to, že po rekonfiguraci neexistuje vždy možnost reloadu, aniž by spadly běžící joby. Opět, dá se s tím žít, ale pokud to uděláte uprostřed full zálohy, ta bude muset proběhnout znovu, ale data v datasetu už jsou, a budou čekat na exspiraci (také nedořešený stav).
Stačí popis takto?
54 Odpovědí
13194 Zhlédnutí