Řešení 1:
Možnosti pro rychlý přístup k milionům souborů a jejich zálohování
Půjčte si od lidí s podobnými problémy
To zní velmi podobně jako jednodušší druh problému, kterému čelí zpravodajské servery USENET a cachování webových proxy:stovky milionů malých souborů, ke kterým se přistupuje náhodně. Možná si od nich budete chtít vzít nápovědu (kromě toho, že obvykle nemusí zálohovat).
http://devel.squid-cache.org/coss/coss-notes.txt
http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf
Je zřejmé, že cyklická povaha souborového systému cyklických zpráv je pro vás irelevantní, ale koncept na nižší úrovni s více diskovými soubory/zařízeními se zabalenými obrazy a rychlým indexem z informací, které uživatel poskytuje k vyhledání informací o umístění, je velmi vhodný.
Vyhrazené souborové systémy
Samozřejmě, toto jsou jen podobné koncepty, o kterých lidé mluvili o vytvoření souborového systému v souboru a jeho připojení přes smyčku, kromě toho, že si můžete napsat svůj vlastní kód souborového systému. Samozřejmě, protože jste řekli, že váš systém je převážně pro čtení, můžete ve skutečnosti vyhradit diskový oddíl (nebo oddíl lvm pro flexibilitu ve velikosti) tomuto jedinému účelu. Když chcete zálohovat, připojte souborový systém jen pro čtení a poté vytvořte kopii bitů oddílu.
LVM
Výše jsem zmínil LVM jako užitečný pro umožnění dynamického určování velikosti oddílu, takže nemusíte zálohovat spoustu prázdného místa. Ale samozřejmě, LVM má další funkce, které mohou být velmi použitelné. Konkrétně funkce "snímek", která vám umožní zmrazit souborový systém v okamžiku. Jakékoli náhodné rm -rf nebo cokoli, co by nenarušilo snímek. V závislosti na tom, co přesně se snažíte udělat, to může být dostatečné pro vaše potřeby zálohování.
RAID-1
Jsem si jistý, že již znáte RAID a pravděpodobně jej již používáte pro spolehlivost, ale RAID-1 lze použít i pro zálohování, alespoň pokud používáte softwarový RAID (můžete jej použít s hardwarovým RAID, ale ve skutečnosti poskytuje nižší spolehlivost, protože ke čtení může vyžadovat stejný model/řadič revize). Koncept spočívá v tom, že vytvoříte skupinu RAID-1 s jedním více diskem, než ve skutečnosti potřebujete připojeným pro vaše běžné potřeby spolehlivosti (např. třetí disk, pokud používáte softwarový RAID-1 se dvěma disky, nebo třeba velký disk a hardwarový- RAID5 s menšími disky se softwarovým RAID-1 nad hardwarovým RAID-5). Když přijde čas na vytvoření zálohy, nainstalujte disk, požádejte mdadm, aby tento disk přidal do skupiny raid, počkejte, dokud nebude indikovat úplnost, případně požádejte o ověřovací scrub a poté disk odeberte. Samozřejmě, v závislosti na výkonnostních charakteristikách můžete mít disk většinu času nainstalován a pouze jej vyjmout za účelem výměny za alternativní disk, nebo jej můžete nechat nainstalovat pouze během zálohování).
Řešení 2:
Můžete připojit virtuální souborový systém pomocí správce zpětné smyčky, ale i když by to urychlilo proces zálohování, mohlo by to ovlivnit normální operace.
Další alternativou je záloha celého zařízení pomocí dd. Například dd if=/dev/my_device of=/path/to/backup.dd .
Řešení 3:
Jak asi víte, vaším problémem je lokalita. Typické vyhledávání disku trvá přibližně 10 ms. Takže pouhé volání "stat" (nebo open()) na 10 milionech náhodně umístěných souborů vyžaduje 10 milionů hledání, tedy přibližně 100 000 sekund, neboli 30 hodin.
Své soubory tedy musíte vkládat do větších kontejnerů, takže příslušné číslo je šířka pásma vašeho disku (obvykle 50–100 MB/s pro jeden disk), nikoli váš čas vyhledávání. Také proto, abyste na něj mohli hodit RAID, což vám umožní zvýšit šířku pásma (ale nezkrátit dobu vyhledávání).
Pravděpodobně vám neřeknu nic, co byste ještě nevěděli, ale jde mi o to, že váš nápad s „kontejnerem“ určitě problém vyřeší a postačí téměř jakýkoli kontejner. Loopback mounts bude pravděpodobně fungovat stejně dobře jako cokoli jiného.
Řešení 4:
Existuje několik možností. Nejjednodušší a měl by fungovat se všemi linuxovými souborovými systémy je dd zkopírujte celý oddíl (/dev/sdb3 nebo /dev/mapper/Data-ImageVol ) na jeden obrázek a archivujte jej. V případě obnovy jednotlivých souborů připojte obraz zpětné smyčky (mount -o loop /usr/path/to/file /mountpoint ) a zkopírujte soubory, které potřebujete. Pro úplnou obnovu diskového oddílu můžete obrátit směr počátečního dd ale opravdu potřebujete oddíl stejné velikosti.
Soudě podle vašeho případu použití předpokládám, že jednotlivé obnovy souborů jsou velmi zřídka, pokud k nim vůbec někdy dojde. To je důvod, proč zde má opravdu smysl zálohování založené na obrazech. Pokud potřebujete provádět jednotlivé obnovy častěji, bude mnohem pohodlnější použití připravených snímků LVM; ale stále musíte provést zálohu založenou na obrazech pro tyto kritické katastrofy typu „ztratili jsme všechno“. Obnovy založené na obrázcích bývají časté rychlejší než obnovy založené na taru jednoduše proto, že se pouze obnovují bloky, nevyžadují s každým fopen/fclose docela dost operací s metadaty a může to být také vysoce sekvenční disková operace pro další zvýšení rychlosti.
Alternativně, jak zmiňuje video Google @casey zhruba v polovině, XFS je skvělý souborový systém (pokud je složitý). Jeden z hezčích nástrojů s XFS je xfsdump nástroj, který vypíše celý souborový systém do jednoho souboru a obecně to udělá rychleji než tar umět. Je to utilita specifická pro souborový systém, takže může využívat interních funkcí fs způsoby, které tar nedokáže.
Řešení 5:
Doporučuji, abyste nejprve zkusili upgradovat na EXT4, pokud jej již nepoužíváte.
Google provedl mnoho výzkumů, proč je EXT4 dobrý nápad.
Poté byste se měli podívat na nasazení architektury distribuovaného souborového systému. Například:
- http://www.xtreemfs.org/
- http://code.google.com/p/kosmosfs/
- http://hadoop.apache.org/hdfs/