Fórum Root.cz
Hlavní témata => Server => Téma založeno: maxlink 27. 03. 2017, 11:23:01
-
Ahoj, mam Linux server (Debian), pres 8TB HDD v diskovem poli, v noci se na nej pres NFS/Sambu lejou zalohy virtualnich masich, jsou to "bloby" od 50-300GB, existuje nastroj jak jak bych mohl ty data deduplikovat, protoze valna cas je porad stejna, je tam ext4, premyslel jsem o zfs, ale zase deduplikace chce hodne RAM, mam pouze 8GB aktualne, myslel jsem spise nejaky archivator/backup nastroj, ktery by to pres den prechroupal, zalohy bezi v noci cca 5hodin a pres den se stroj flaka. Diky za tip. Max.
-
Nestačil by pustit lokální rsync?
-
Nemůžete dělat deduplikaci (pomocí hardlinků) obecně na libovolném systému a s libovolnými nástroji. Snadno se vám pak stane, že zjistíte duplicitu mezi dvěma soubory, nahradíte je hardlinkem – pak někdo jeden z těch souborů změní, a tím vám zároveň změní i ten druhý. Pokud tedy ten disk používáte jenom pro zálohy, pořád byste je musel dělat tak, že každý den vytvoříte komplet novou zálohu, a teprve po té uděláte deduplikaci – tj. nesměl byste zálohy přepisovat. Ale pokud používáte NFS/Sambu a ne rsync, zřejmě už to tak děláte dnes.
Proč nepoužijete btrfs?
-
To by me taky zajimalo, jak se resi deduplikace na urovni obrazu VM.
-
Nemůžete dělat deduplikaci (pomocí hardlinků) obecně na libovolném systému a s libovolnými nástroji. Snadno se vám pak stane, že zjistíte duplicitu mezi dvěma soubory, nahradíte je hardlinkem – pak někdo jeden z těch souborů změní, a tím vám zároveň změní i ten druhý. Pokud tedy ten disk používáte jenom pro zálohy, pořád byste je musel dělat tak, že každý den vytvoříte komplet novou zálohu, a teprve po té uděláte deduplikaci – tj. nesměl byste zálohy přepisovat. Ale pokud používáte NFS/Sambu a ne rsync, zřejmě už to tak děláte dnes.
Proč nepoužijete btrfs?
Mám klasický vmware, z něho v noci vypadne několik souboru, jako záloha VM, co soubor to v podstatě stroj, je to klasické ghettoVCB, vmware má přimountované NFS z backup serveru a sype se to přímo backup, protože ty image se dělají každou noc a jsou +- stejně veliké, tak je jasné, že se tam moc věcí nemění, proto se ptám, jestli je nějaká možnost jak ty stejné bloky v těch souborech (každé virtuální mašiny) uchovat jen jednou, klidně to protáhnu nějakým nástrojem, chtěl bych schovávat více záloh (více dní zpětně) i za cenu, že při obnově ze staršího budu muset "slejt" nějak zpět, rozumějte nemám možnost nic moc nikde snapshotovat (jen na úrovni vmware a to dělat ghetto), zfs/brtfs deduplikace online by byla fajn, ale co jsem pochopil, tak to docela žere zdroje (RAM a to jakože dost).
Narazil jsem na zbackup.org, asi to zkusím nemáte s tím někdo zkušenosti ? Max
-
zfs/brtfs deduplikace online by byla fajn, ale co jsem pochopil, tak to docela žere zdroje (RAM a to jakože dost).
Takhle se bude chovat každá deduplikace – potřebujete mít nějaké kontrolní součty všech zapsaných bloků a umět v nich rychle vyhledávat. Aby to dávalo smysl, je potřeba je držet v RAM.
V případě btrfs nemusíte používat on-line deduplikaci, můžete porovnávat jen vybrané soubory (třeba novou a předchozí zálohu), čímž zdroje výrazně ušetříte. A dostanete tím prakticky to, co dělají zbackup.org nebo rdiff-backup, akorát to máte rovnou jako čitelné soubory na disku.
-
Pokud deduplikaci potřebuješ, stačí přidat paměť. Je dnes docela levná.
-
...
Jasne ze na to sou nastroje ... treba ty fs ktery to umej ... a aby to bezelo v nejakym pouzitelnym casovym horizontu ... potrebujes na to ... tu RAM. Hodne ram. Uvedom si, ze je treba vzit kazdej jeden blok a porovnat ho se vsema ostatnima ... a aby se tohle nemuselo delat, tak si deduplikator bloky/soubory ... ohashuje, a drzi si v ram ty hashe.
Na btrfs to pak samo muzes pustit i bez ty ramky ... jen to v zavislosti na objemu pobezi treba i par dnu.
Nebo to udelas tak, ze budes "zalohu" prepisovat ... a z ni udelas snap. Ten bude drzet prave jen zmeny ... ovsem to neresi deduplikaci v ramci kompletnich zaloh ale jen v ramci jednotlivych souboru.
-
V ZFS lze dedup table ukládat i na L2ARC cache na SSD. To by mohlo být nejlevnější řešení.
Osobně bych za 1200 Euro pořídil repas server se > 64GB RAM DDR3, ale ne každému to vyhovuje. Např. http://www.ebay.de/itm/Dell-PowerEdge-R720-2x-Xeon-Six-Core-E5-2640-2-5GHz-80GB-RAID-PERC-H310-Server-/292061947252 mínus 20% DE DPH a určitě by se s nimi dala domluvit rozumná doprava.
-
Mám dobré zkušenosti z BorgBackup https://borgbackup.readthedocs.io (https://borgbackup.readthedocs.io)
Deduplikace je rychlá.
Spotřeba paměti se dá optimalizovat nastavením chunk paramatrů http://borgbackup.readthedocs.io/en/stable/internals.html (http://borgbackup.readthedocs.io/en/stable/internals.html)
-
(..) A dostanete tím prakticky to, co dělají zbackup.org nebo rdiff-backup, akorát to máte rovnou jako čitelné soubory na disku.
Moment -- myslel jsem, ze u rdiff-backup mam zalohu taky rovnou jako citelne soubory na disku. Pletu se? Hodlam na to prejit.
-
(..) A dostanete tím prakticky to, co dělají zbackup.org nebo rdiff-backup, akorát to máte rovnou jako čitelné soubory na disku.
Moment -- myslel jsem, ze u rdiff-backup mam zalohu taky rovnou jako citelne soubory na disku. Pletu se? Hodlam na to prejit.
Jde to namountovat pres FUSE (rdiff-backup-fs). Max
-
Moment -- myslel jsem, ze u rdiff-backup mam zalohu taky rovnou jako citelne soubory na disku. Pletu se? Hodlam na to prejit.
Pletete se, v čitelné podobě je na disku jenom poslední záloha, starší se musí „zrekonstruovat“ z rozdílových souborů. Pomocí FUSE se ta rekonstrukce dá schovat za běžné rozhraní souborového systému, ale na pozadí pořád bude muset ovladač tu rekonstrukci provést.
Doporučuju k přečtení Záloha dat pomocí rdiff-backup (https://www.root.cz/clanky/zaloha-dat-pomoci-rdiff-backup/).
-
Je to tam "hoši". :-).
Přemigroval jsem na btrfs a nasadil "offline" deduplikaci přes duperemove, to mi stačí spustit nad ránem až doběhnout zálohy, duperemove najde duplicitní bloky submitne je do jádra k deduplikaci, to vypadá dobře. Max.
-
pak řekni, jak to funguje
nad obrovskýma datama mi to zatuhuje jeden stroj, ale o data jsem nepřišel ;)
a nevýhoda btrfs je, že po deduplikaci je potřeba místo ještě skutečně uvolnit, t.j.
btrfs fi df /mnt
btrfs balance start -musage=99 /mnt
btrfs balance start -dusage=99 /mnt
btrfs fi df /mnt
asi pouštět z cronu, asi ne každý den? jednou týdně?
-
Neexistuje nějaký souborový systém podobný taru, který je možné bzipovat?
-
tar neni FS
a bzip2 proc? gzip je v btrfs nebo zfs a jestli chces vetsi kompresi, tak lzma je lepsi nez bzip2
ale primo transparentne ve FS se zatim asi nepouziva
-
Neexistuje nějaký souborový systém podobný taru
Co myslíte tím „podobný taru“? Aby v něm soubory nebyly ukládané v sektorech, ale za sebou? To je třeba ISO 9660 (https://cs.wikipedia.org/wiki/ISO_9660), který se používá na CD, případně ještě novější UDF (i když ten je o něco komplikovanější).
který je možné bzipovat?
Opět nevím, co tím myslíte? Máte souborový systém v souboru připojený přes loopback? Bzipovat můžete jakýkoli soubor. Nebo by podporu bzipování měl mít v sobě přímo ten souborový systém?
Možná by bylo jednodušší, kdybyste napsal, co vlastně chcete řešit.
-
A nemyslel tazatel nahodu prepinac "j" ktery tar rovnou bzipuje?
tar cvjf archive-name.tar.bz2 some/path/here/
-
Neexistuje nějaký souborový systém podobný taru, který je možné bzipovat?
Nezávisle na FS...
sudo dd if=/dev/sda1 | bzip2 > ~/sda1.bz2