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

19.11.2014 14:20 | Přečteno: 1162× | Obecné | poslední úprava: 19.11.2014 14:16

Zamyšlení se nad zálohováním obrovského měsíčního přísunu dat. Jedná se za prvé o textová data vstupní s objemem 150-160GB nekomprimovanych (23-25GB komprimovaných slabou zip kompresí ) plus textová data zpracovaná, cca 159GB nekomprimovaná (8GB komprimovaná 7zip) plus databázové soubory z nich vytvořené grafická 65GB spi 85GB nekomprimovaná (spi 10GB grafická 13GB komprimovaná 7zip). U těchto dat nepředpokládá žádná retence. V případě problému je potřeba umožnit návrat x let nazpět. V současnosti se zálohují na DVD či BlueRay disky.

Dále se jedná o zálohy fyzických (Bare Metal) a virtuálních serverů (export Hyper-V nebo KVM LVM partition) celkem nekomprimováno asi cca 250 +140GB nekomprimováno. V současné době se komprimuje každý stroj zvlášť. Přičemž u zálohy strojů se předpokládá minimálně tří-čtyž měsíční retence.

Napadají mě pouze tyto cesty:

• zfs NAS4Free nebo FreeNAS deduplikace + záloha pomocí snapshotů na externí disk či na jiný stroj
• Duplicati 2.0 deduplikace - zatím neprozkoumaná novinka
• Pásková jednotka - nikdy jsem na pásky nic nezálohoval

Co byste radili vy? Máte tip jak se efektivně vypořádat s takovým přivalem dat? Nebo zůstat u původního zálohování na DVD + BlueRAY a síťová úložiště?        

Komentáře

[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.