Dotaz: Synchronizace souborů do backup adresáře bez přepisování

[majales]

Zdravím, Hledám nástroj pro synchronizaci souborů do backup adresáře, tak aby nepřepisoval existující soubory, ale udělal místo toho soubor nový. Když se nad tím tak zamýšlím, tak by bylo nejlepší aby to bylo i s kompresí, ale tu jsem schopen oželet. Umí něco takového rsync nebo unison? Díky za každý tip.

Odpovědi

[Jendа]

rsync měl nějakou volbu na generování hardlinků, ale osobně jsem na to šel pomocí btrfs nebo ZFS a snapshotů, případně pomocí rdiff-backup.

[majales]

Jenže rdiff-backup je ukrutně pomalý při velkých objemech... Mám ho nasazený na zhruba 300GB adresáři a jedna synchronizace běží cca hodinu.. Pravda je to přes smbmount, ale i tak je to pomalé. ZFS ani btrfs bohužel nepadá v úvahu..

[k3dAR]

sync 300GB za 1h po sambe neni snad tak strasne, mozna by pomohlo misto konzumnich 5k4rpm HDD pouzit nejake SSD a misto 1xGLAN pouzit bond nad 8xGLAN nebo 1x10GLAN ;)

[majales]

Já to teď řeším jako synchronizaci na lokálním filesystému s tím, že ten backup by se neměl v žádném případě přepsat apokud ano tak by měla být zachována předchozí verze souboru.

[majales]

Navíc rdiff-backup se pokud vím už nevyvíjí celých 7 let a už se asi vyvýjet nikdy nebude..

[Filip Jirsák]

A je v tom problém? Jsou tam chyby? Nebo chybí nějaké vlastnosti?

Jinak pokud se aspoň část těch souborů nemění, nejvíc to urychlíte tak, že přes síť použijete protokol rsync, takže se nebudou přenášet celé soubory, ale jenom změny. Tedy pokud je síť úzkým hrdlem, což obvykle bývá.

[k3dAR]

i primo tvurci upozornuji aby prenos na samba byl provaden pres ssh (stejny duvod jako rsync), pripadne zkusit misto cifs pouzit sambafs (ten ma ale limit souboru max 2GB) viz: http://www.nongnu.org/rdiff-backup/FAQ.html#cifs

[Filip Jirsák]

Mám ho nasazený na zhruba 300GB adresáři a jedna synchronizace běží cca hodinu.. Pravda je to přes smbmount, ale i tak je to pomalé.

Přenést 300 GB za hodinu vám připadá málo? Co tam máte za síť? Pokud je to 1 Gbit/s, přenášet po ní reálně 0,66 Gbit/s (s veškerou režií) je podle mne dost slušné.

[Jendа]

Já to pochopil jako že má 300 GB souborů a rozdíl je malý, ale hodinu trvá, než se všechny projdou a vyhodnotí se změny. A tam samozřejmě záleží hlavně na počtu souborů.

Proč nejde použít btrfs? Já to udělal tak, že na Sambě (Wedos disk) mám soubor naformátovaný na btrfs a připojený přes loopback.

[Filip Jirsák]

Pokud má to úložiště připojené přes smbmount, znamená to, že se všechny ty soubory musí přenést SMB protokolem na lokální počítač. Tam by se teoreticky mohly vyhodnotit ty změny, jenže už je to zbytečné, když se soubor přenesl, takže se může rovnou celý zapsat.

Rsync může využít tu svou hlavní výhodu – přenos pouze změn – jedině tehdy, když se přes síť používá protokol rsync (případně zapouzdřený do SSH). Jakmile je pro přenos přes síť použit jiný protokol a rsync porovnává „lokální“ soubory, přenáší se celé soubory. Rsync by se měl pokoušet takové situace detekovat a vypisovat červené blikající varování

[Jendа]

Pokud má to úložiště připojené přes smbmount, znamená to, že se všechny ty soubory musí přenést SMB protokolem na lokální počítač.

Ne, nemusí. Stačí, když se přenesou informace o času poslední změny a velikosti. Pokud se tyto nezměnily, rsync na ně v defaultním nastavení nebude vůbec sahat.

[Filip Jirsák]

Pokud se tyto nezměnily

Ne pokud se nezměnily, ale pokud budou stejné. Což zrovna v případě smbmount může dopadnout všelijak. Dá se použít parametr, aby rsync zadané rozdíly v čase ignoroval, ale ten v defaultním nastavení zapnutý není.

[lertimir]

Vždy je volba mezi rychlostí, efektivitou, flexibilitou a pohodlností. Já na zálohy už asi 3 roky používám backuppc a je vynikající v efektivitě (v záloze jsou soubory principiálně organizovany kompresované podle hashů a následně na hardlinkovány na jednotlivé zálohy jednotlivých strojů. Takže stejný soubor existující na několika strojích a zpracovaný v několika zálohách je fakticky v záloze pouze jedenkrát) flexibilitě ( efektivní nastavení úplných a inkrementálních záloh více úrovní, nastavení adresářových stromů které zálohovat a co vylučovat a podobně na úrovni souborů.) pohodlnosti (komfortní webové rozhraní pro definici a práci včetně pohodlné restaurace souborů a stromů na jiný stroj. (Konkrétně, manželce končil notebook tak po instalaci systému stačilo ho zavést do zálohovacího systému a ze staré zálohy určit kam se její home má restaurovat a bylo.) Nevýhoda: značná pomalost, inkrementální zálohy cca 100 minut a úplné cca 250 minut. (ale úplná záloha má 800 000 souborů a to asi rychleji stejně nejde. IOPS na rotačním disku jsou kolem 100 IOPS.)

Pokud je to záloha, která má šáhnout na všechny soubory a posoudit jestli se změnily tak na rotačním disku stejně více než cca 100 za vteřinu neudělá nijak. Žádný systém.

[Jendа]

Pokud je to záloha, která má šáhnout na všechny soubory a posoudit jestli se změnily tak na rotačním disku stejně více než cca 100 za vteřinu neudělá nijak. Žádný systém.

Může být víc záznamů o souborech v jednom bloku.

[lertimir]

Příloha:

• diskstats_utilization-day.png (52065 bytů)

Myslel jsem to tak že když máš skutečně šáhnout na soubor a spočítat hash a pak porovnat jestli hash máš tak je jedno jak máš malé soubory. Na urovni aplikace užívající FS už vetšinou nemáš informaci, jestli soubory nejsou fyzicky na disku v jednom bloku. (ale uznávam, když posuzuji, že se nezměnily časy souborů tak čtu jen inode.). Chtel jsem tim hlavně drůraznit, že když je záloha na souborové úrovni a jsou to stovky tisíc souborů tak je to pomalé z principu i když je to velikostně malé.

Jen pro info přihazuji graf ze zálohovacího serveru. Když jede něčí záloha tak vyjede primárně šedý pík, což je zálohovací oddíl postavený jako RAID 10 nad oddílem z disků sdb-e. Jasně je vidět že rychlost zálohy je limitovaná seekováním přes zálohovací oddíl. A takhle to seekuje nejen při inkrementech ale i při úplné záloze, protože zjištuje jestli soubor není stejný a tím pádem se nebude nic do zálohy přidávat.

[dustin]

Tan backup dir je namontovaný přes sambu? Pak by nešly využít ani hardlinky rsyncu, které jinak docela pěkně fungují. Např. je využívá dirvish (perlový skript nad rsyncem), který by pro tohle šel snadno nakonfigurovat.

[marek_hb]

co takhle rsnapshot?

[majales]

Díval jsem se na něj, ale z toho co jsem pochopil tak neumí zachovat původní zálohu, což je to co právě potřebuju.

Trochu se to tady pomotalo s tím, že jsem napsal, že používám rdiff-backup pro zálohování vzdáleného disku připojeného přes smbmount. To co jsem chtěl, je zálohovat lokálně adresář do adresáře tak aby se původní záloha nikdy nepřepsala a pokud vznikne stejné nazvaný soubor s jiným obsahem tak aby se ten původní zachoval a ten nový se tam taky dostal a aby se toto detekovalo třeba nagiosem. Reálně to bude adresář s podadresáři a v každém z nich soubory a podadresáře a soubory tam budou neustále přibývat.

[Filip Jirsák]

Podle mne rdiff-backup i rsnapshot dělají přesně to, co popisujete, tedy inkrementální zálohování s možností obnovit soubory z předchozích záloh. V případě rdiff-backup vidíte přímo na disku poslední zálohu a předchozí zálohy musíte obnovovat příkazem, v případě rsnapshot vidíte ty předchozí zálohy přímo na disku. Rozdíl je samozřejmě v potřebném místu na disku, když se změní část souboru – u rdiff-backup bude ta společná část uložena jen jednou, v případě rsnapshot musí být na disku vícekrát, v každé variantě souboru jednou.

[k3dAR]

neni treba obnovovat prikazem, pouzivam s rdiff-backup-fs, doplneno o patche aby slo exportovat po samba, takze vysledek je ze vsechny vidis prirustkove backup jako adresare podle datumu zalohy a v nem virtualne vidis vsechny soubory a vykopirujs co potrebujes pomoci sveho oblibeneho nastroje na kopirovani souboru :)

[marek_hb]

což ale při rsnapshotu odpadá - všechny zálohy jsou normálně čitelné bez další věci co se může rozbít (podle mě)

[k3dAR]

nefunguje rsnapshot tak ze vsechny nezmenene soubory udela hardlink na prvotni backup (nutno tedy cilovej filesystem s podporou hardlink) a zmenene soubory nakopiruje cele i pri zmene 1 bajtu?(+ nafoukne o to cele backup dir)? oproti tomu rdiff-backup lze cilit i na filesystem bez hardfiles (aspon myslim :) ale hlavne zmenene soubory uklada jen jako rozdil...
myslim ze oboji ma sve vyhody i nevyhody... me (zatim?) pro me potreby vyhovuje vice rdiff-backup + rdiff-backup-fs :)

[Filip Jirsák]

Ano, funguje tak, psal jsem to o něco výše.

[marek_hb]

jj funguje - rdiff jsem kdysi používal,ale asi jsem měl pomalý počítač nebo já nevím co, ale připojení záloh přes rdiff-backup-fs bylo pomalé (i jen pohyb v adresářích) + jsem se pak někde dočetl o možných problémech při různých verzích rdiff a tak jsem přešel na rsnapshot a vyhovuje mi víc

[marek_hb]

Mam pocit ze prave tohle umi - udela proste zalohu 1 - pak ji prekopiruje na 2 a do jednicky zapise zmeny (tak nejak) - tzn mas pak adresar treba hourly 0 a v nem normalne pristupnou adresarovou strukturu a soubory v case zalohy a pak adresar hourly 1 - 2 - 3 (podle nastaveni) a v nich predchozi zalohy. Plus muzes mit dalsi jako tydeni, mesicni

Aspon takhle nejak funguje u me - sypu pres nej zalohy na nas dik pripojeny pres nfs

[Josef Kufner]

rsnapshot stojí na rsync --link-dest. Tedy vytváří hardlinky na nezměněné soubory v předchozí záloze. Obnova je nesrovnatelně rychlejší než v případě rdiff-backup, neboť není potřeba rekonstruovat staré verze souborů z diffů.

Používal jsem rdiff-backup, nyní používám rsnapshot a je to mnohem lepší. Hlavně ta obnova starších souborů. Zdaleka nejčastější use-case záloh je právě vytažení nějaké staré verze jednoho souboru či adresáře s několika málo soubory.

Co se místa na disku týče, hardlinky docela komplikují výpočet zabraného místa i odhad, za jak dlouho místo dojde, ale celkem v pohodě se s tím dá žít. Je docela obtížné zkopírovat zálohovací disk na nový zálohovací disk, neboť je potřeba zachovat hardlinky a na to je potřeba hodně paměti.

Rozhodně s rsnapshotem doporučuju mít dedikovaný fyzický (i logický) disk jen na zálohy. Jinak to je ale dobrý a jednoduchý (není moc, co by se mohlo podělat) nástroj.

[VjEtNaM]

Drive jsem pouzival rdiff-backup. Ale rychlost nic moc. Nyni pouzivam BorgBackup. Zatim jsem spokojeny. Rychlost super, deduplikace, komprese, sifrovani, mountovani zaloh pres fuse.

[m]

Nešel by back-in-time ? Pokud se soubory nemají přepisovat, tak toto splňuje verzováním.