Zamyšlení se nad zálohováním každoměsíčního přívalu dat. (diskuse)

[Max]

Řeším něco podobného. Jednak failover/ha a jednak zálohování s minimálním rollbackem dat.
Zatím jsem narazil na tyto možnosti :
1) ESXi replication + SRM (v intervalech se odkopírovává živá VM na vzdálený ESXi hypervisor + se snapshotuje a celé je to zautomatizováno pomocí vmware SRM)
2) ESXi + premium kit licence + 3rdparty řešení (např. veam backup, tivoli, double take apod.)
3) XenServer pool migration/replication (mělo by to být něco jako to ESXi replication)
4) KVM + drbd + lvm/btrfs snapshoty (replikace dat téměř v reálném čase v rámci drbd + následně snapshot v nějakých intervalech)

ESXi by mělo zaručovat 100% konzistenci dat. 3rd produkty s ESXi taktéž zaručují 100% konzistenci dat. XenServer replication, tak tam nevím, zda to zajišťuje.
Pokud jde o drbd, tak tam nelze zajistit 100% konzistenci dat, stejně tak jí nelze zajistit u LVM/btrfs snapshotů (měl by to být stejný případ, jako kdyby došlo k vytažení PC z napájení). Ale na druhou stranu, vše by mělo přežít vytržení PC z napájení (jak file systém, tak transakční db).

Pokud jde o db, tak provozujeme Oracle, tam se dlouhodobý backup řeší jednak exportem db, alé také standby db + zálohou transakčních logů.
Vše se ukládá na backup storage v hodně krátkých intervalech po dobu dvou let. Vše starší se pálí v podobě exportu db na blue ray, ale s větším odstupem času (je zbytečné pálit/udržovat export db proběhlý 2x denně, drží se tak třeba 4x měsíční backup).
Zdar Max

[gtz]

Uvažoval bych o nějaké pásce LTO4/LTO5 v provedení SAS/FC. Kapacita pro zálohy se mi zdá v pohodě, ale pak se musíte zamyslet nad tím jak se ty data mění. Tyto mechaniky jsou ideální pro přírůstkové zálohy kdy se dá celkem sofistikovaně udělat rotace záloh. Pokud by se nemuselo médium schovávat a šlo by přepsat plnou zálohou dalšího týdne pak by to bylo snad v pořádku.

[Jendа]

U virtuálů neexportovat obrazy FS, ale zálohovat soubory třeba pomocí rdiff-backup.

Kompresi umí ZFS a btrfs.

[Josef Kufner]

rdiff-backup je velmi velmi pomalý při přístupu k starším datům. Osvědčil se mi více rsnapshot, který stojí na rsyncu a jeho deduplikaci pomocí vytváření hardlinků. Ale nejsem si jist, co to udělá s objemem dat větším než je záloha pár notebooků na domácí server.

[volvox]

Používal jsem rsnapshot, potom rdiff-backup a nakonec skončil u obnam. U předchozích jsem se stále narážel na výkonostní limity a komplikovanou konfiguraci. Zálohuju s tím milióny souborů v řádu několika TB. Je to rychlejší (min. o řád v mém use case), jednotlivé zalohy lze namountovat, deduplikuje...

[Josef Kufner]

Velkou výhodou rsnapshotu je, že všechny zálohy jsou kdykoliv k dispozici bez použití jakéhokoliv dalšího nástroje. Obnova omylem smazaného/poškozeného souboru je jen o připojení se na server a vlezení do odpovídajícího adresáře.

Co jsem tak kouknul na obnam, prý má/měl problémy s výkonem. Je to už nějak vyřešené?

[VSi]

Používám disrvish, což je stejný princip jako rsnapshot. Největší zálohovaný FS má 420 GB a 2.7 milionu souborů. Zpětně držíme kolem 100 záloh, žádný problém. Jen mazání takového množství souborů na ext4 je dost pomalé. Záloha trvá asi 2 hodiny při změně cca 5 GB, cíl je mdadm RAID6 z 8 2TB SATA disků, zdroj podstatně rychlejší SAS pole s XFS. Zásadní problém jsou xattr (kvůli samba DOSATTRIB), jejich záloha přes rsync prodlužuje čas na víc než 5 násobek.

[Dreit]

K páskám - http://jetset.blog.root.cz/2011/06/27/datchanger/ - třeba by poradil, nějakou zkušenost očividně má

[Xerces]

Pane jo 150GB vstupních dat. To je výkonnost jak u nějaký nadnárodní korporace.

[Jendа]

Tak když sniffuješ mailový provoz středně velkého ISP…

[JiK]

o Amazon Glacier jsi slysel? za par drobnejch bys vyresil sve zalohy.

[majales]

Ahoj. Online záloha nepadá v úvahu. Máme uplink 4Mbit a v nejbližší době se nechystá žádný upgrade a linka slouží na servírování služeb zákazníkům. U vstupních dat se jedná o data katastru, vypočítaný komprimovaný rozdíl (rdiff-backup) mezi měsíčními výdeji je v řádu jednotek až několika desítek GB. ZFS se bojím, respektive bojím se deduplikace s její paměťovou náročností, ale pokud to bude schůdná cesta tak bych se vydal asi tudy.

[odin]

+1

Nechapu, proc se v dobe cloudu za par korun resi nejaka handmade reseni, ktera stejne nikdy nebudou poradne fungovat.

[Josef Kufner]

Třeba proto, že svá data nechci dávat nějaké nedůvěryhodné firmě z druhého konce světa.

[Odin]

Sifrovani?

Ale mate pravdu, od toho bugu v openssl uz tomu moc neverim

[Jendа]

Sifrovani?

To je snad samozřejmost. Spíš jde o to, že se prostě rozhodnou, že už je to nebaví, a co se s tím pak dá dělat.

[Aleš Kapica]

Tohle je bohužel argument, který u řady lidí přesahuje jejich schopnosti pro vnímání času. Většina má problém si vůbec představit co bude za pět let.