Zalohovani, best-practices

Petr Baláš petr na balas.cz
Pátek Listopad 6 11:30:00 CET 2015


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



-- 
Petr Baláš - petr at balas dot cz


Další informace o konferenci Linux