Zalohovani, best-practices

Jan Hrach jenda na yakumo.hrach.eu
Pátek Listopad 6 21:18:21 CET 2015


> Jednotlivé zálohy jen pomocí snapshotů nebo je nad tím nějaký program?

Jenom několikařádkový skript. Snapshot se jmenuje jako datum a když to vidí starší než půl roku, tak ho smaže.

On 6.11.2015 11:30, Petr Baláš wrote:
> 2015-11-05 19:21 GMT+01:00 Jan Hrach <jenda na yakumo.hrach.eu>:
>>> Kdyz inkrementalne zalohujete na vzdaleny stroj (sprateleny nebo
>>> pronajaty), je pro vas dulezite, aby ten vzdaleny stroj byl "append-only"?
>>
>> Ano. Dělám to tak, že se zálohující stroj připojuje na zálohovaný - opačně přístup není, nemůže tedy soubory měnit.
> 
> Taky tak.
> 
> 
>> Po záloze se se udělá snapshot.
>>
>>> Dale, je pro vas dulezite, aby zalohovaci stroj poskytovat i po zapisu
>>> kontrolni soucty vsech udrzovanych inkrementu
>>
>> Ani ne. btrfs to dělá, mdraid ne. Silent data corruption odhalíme pár za rok (50 TB dat, každý měsíc se to pro kontrolu všechno přečte), navíc když je to v RAIDu s dostatečnou redundancí, tak se to opraví.
>> Kdybych držel nějaké velké binární databáze, mluvil bych jinak.
> 
> Jj, pomalu překlápím stroje na btrfs a btrfs scrub z cronu.
> 
> 
>>> Zajima me vas nazor, jak pristupuji k zalohovani ti z vas, kteri se citite
>>> spokojeni s tim, jak to mate vyreseno.
>>
>> Server, pár disků, nad tím MD nebo BTRFS RAID, případně ještě dm-crypt. Pravidelně rsync všech strojů a pak snapshot.
>> Pro extra paranoiu na serveru nemusí běžet sshd a přístup jen přes lokální konzoli.
> 
> Jednotlivé zálohy jen pomocí snapshotů nebo je nad tím nějaký program?
> 
> Používám dirvish a zatím spokojenost, výsledek se dá krásně zpřístupnit
> skrz sambu (read-only) a nemusím řešit obnovu dat, uživatelé si poradí :-).
> 
> Jinak v jednom případě, kdy mám zálohovací stroj v jiné firmě, tak
> na zálohovaném strojí mám encfs a zálohuji až zašifrované soubory
> (ano, vím že encfs má svoje mouchy ale v tomto případě mi to stačí).
> 
> Petr Baláš
> 
> 
> 
>> On 5.11.2015 10:23, Vladimir Macek wrote:
>>> Zdravim vsechny,
>>>
>>> zkratim to:
>>>
>>> Kdyz inkrementalne zalohujete na vzdaleny stroj (sprateleny nebo
>>> pronajaty), je pro vas dulezite, aby ten vzdaleny stroj byl "append-only"?
>>>
>>>     To znamena, aby cokoli se do backupu zapise, nebylo mozne ze
>>>     zalohovaneho stroje zmenit. Jen v rezimu obnovy ze zaloh (vyjimecna
>>>     situace) aby existovala jina cesta, ktera umozni zalohy cist, popripade
>>>     odmazavat (pokud se odmazavani nedeje automaticky).
>>>
>>> Dale, je pro vas dulezite, aby zalohovaci stroj poskytovat i po zapisu
>>> kontrolni soucty vsech udrzovanych inkrementu, aby mohl zalohovany stroj
>>> (nebo spravce ze tretiho mista) prubezne kontrolovat, ze v zalohovadle se
>>> stale nachazi neporusene inkrementy?
>>>
>>> Podotykam, ze mam na mysli fungovani v rezimu "levne, nekorporatne, skoro
>>> za sve". Ale nemelo by to na odpovedi mit velky vliv, protoze mi jde o
>>> teoreticke principy.
>>>
>>> Zajima me vas nazor, jak pristupuji k zalohovani ti z vas, kteri se citite
>>> spokojeni s tim, jak to mate vyreseno. Jak domaci uzivatele, i majitele
>>> serveru "na kolene", tak zkuseni korporatni spravci se solidnimi rozpocty.
>>>
>>> Nyni mam pro sebe takovy sprateleny append-only zalohovac v geograficky
>>> vzdalenejsi oblasti, kam pres specialne nastaveny put-only FTP server
>>> ukladam sifrovane inkrementy. Dodava mi to klid, ze i kdyby se na
>>> zalohovanem serveru cokoli sebehlo, ta chyba nebo utok neohrozi zalohovana
>>> data. Ale casy se meni a je mozne, ze o append-only remote backup prijdu.
>>>
>>> Pokud se mnou sdilite vyse popsane predstavy, vite o miste, kam se v
>>> takovem pripade uchylit? Co si myslite o vzajemnem poskytovani append-only
>>> zalohovani mezi 2+ servery?
>>>
>>> Diky,
>>>
>>> Vlada
>>>
>>> _______________________________________________
>>> Linux mailing list
>>> Linux na linux.cz
>>> http://www.linux.cz/mailman/listinfo/linux
>>>
>>
>> --
>> Jan Hrach | medlab quality assurance | CEO, NSA Litoměřice - the only company that actually listens to your needs
>> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
>> _______________________________________________
>> Linux mailing list
>> Linux na linux.cz
>> http://www.linux.cz/mailman/listinfo/linux
> 
> 

-- 
Jan Hrach | medlab quality assurance | CEO, NSA Litoměřice - the only company that actually listens to your needs
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E


Další informace o konferenci Linux