Dotaz: Zálohování serveru

[camel1cz]

Zdravím všechny a prosím o radu.

Mám server, běžící na proxmoxu a v něm několik virutálů. Celkem jde asi o 1,4TB dat z čehož se asi 30GB denně změní.

Aktuálně zálohuji baculou z hostingu do kanceláře, ale máme slabou linku a pokud by nastal problém, tak restore bude trvat 14 dnů.

Otázka tedy zní, jak toto řešíte vy zkušení?

Zvažuju následující možnosti

• pronájem prostoru v cloudu (ale nenašel jsem dostatečně rychlý),
• navýšení rychlosti připojení v kanceláři,
• pronájem diskového prostoru v ČR - nejspíš wedos disk (1TB za 300Kč),
• nějaká kombinace? Např. full záloha někde dobře dostupná + inkrementy a databáze "po ruce"?

Potřebuji být schopný v rozumném čase obnovit data. V nejhorším případě vše, ale běžně jen pár MB... Bacula ale vytváří velké soubory a při obnově je zřejmě celé čte, takže obnovení pár mega dat trvá přes síťový disk na pomalé lince fakt dlouho :(

Díky moc za postřehy!

Odpovědi

[Punny]

1,4 TB je celkem malo...Doma zalohuji pomoci backuppc vsechno (pouzil jsem to i v malych firmach). Dokaze obnovit velmi rychle kazdy soubor a dokaze celkem setrit mistem na storage.
Ja osobne bych zvysil rychlost linky...oceni to vsichni nejspis ;) cloud a ukaladat do nich zalohy a vlastne cokoliv mi jde proti srsti
Nicmene zalezi stejne jen na tobe cemu davas prednost.
Punny

[Heron]

Máme několik datacenter (asi tak 3) a zálohujeme to do kříže (no spíš trojúhelníku). V případě výpadku datacentra jsme schopni daná vmka spustit na jiném přímo ze záloh.

[Punny]

a to jako machrujes? :D my mame ve firme take spoustu DC a to i napric kontinenty :P a tece nam tam TB a TB dat den co den. Doufam, ze to vsem pomuze :D

[Heron]

Nemachruju (na rozdíl o tebe dokonce ani nehodnotím objem dat). Tazatel se ptal, jak to řeší ostatní, odpovědel jsem mu. Ne každého může tato varianta napadnout, do kanceláře nesežene takovou linku jako na housing a varianta nakoupit na záložní lokalitu další server může být finančně mnohem přijatelnější, než platit disk u někoho jiného.

[camel1cz]

Nebylo to podáno zrovna přímočaře, ale je to dobrý nápad!

Místo cca. 1000Kč za disk můžu pronajmout někde kolem 3000 server s dostatečným diskem. Můžu na něj zálohovat + ho použít jako nouzovku v případě poruchy hlavního serveru. Vlastně místo kompletního recovery.

Když přitlačím tak 1500 tak mám server schopný normálního provozu místo hlavního.

Rozhodně dobrá varianta - budu přemýšlet. Díky!

[Petr Tomášek]

Což ovšem řeší redundanci ale nikoliv zálohování. (Např. někdo/něco "omylem" smaže/změní soubor. Co se stane? vypropaguje se to na další dvě místa a soubor to v prd*li...)

[Max]

Jen v případě, že to je tak, jak myslíš a Heron při té záloze do trojúhelníku nenechává historii záloh (třeba v podobě snapshotů).
Zdar Max

[Heron]

Tak jistě. Kromě historie se to ještě dává na pásky, které se odvezou do trezoru.

[Jendа]

ale máme slabou linku a pokud by nastal problém, tak restore bude trvat 14 dnů

Aha, tak tohle bych řešil tak že bych naházel disky do batohu a šlapal do datacentra . Máte ho nějak moc daleko?

Bacula ale vytváří velké soubory a při obnově je zřejmě celé čte, takže obnovení pár mega dat trvá přes síťový disk na pomalé lince fakt dlouho

Vykašlal bych se na Baculu a zálohoval rsyncem. Pak máš přístup normálně k jednotlivým souborům.

[Kriegel]

Bacula ale vytváří velké soubory a při obnově je zřejmě celé čte, takže obnovení pár mega dat trvá přes síťový disk na pomalé lince fakt dlouho :(

Bacula pouziva koncept pools/volumes z dob, kdy pasky vladly svetu, proto ty "velke soubory". Samozrejme v dnesni dobe je mozne mit samotne "fyzicke" medium definovano jako soubor na disku.

V pripade restoru, pokud informace o backupu nebyly odstraneny z katalogu, Bacula zna vse potrebne a rozhodne necte "velky soubor" sekvencne. To dela/umi v pripade, ze uz informace k danemu backup jobu byly z katalogu odstraneny, nicmene data na volume zustavaji dal, pokud nebyl zpracovan jinak (prepsan, smazan z jakychkoli duvodu), coz se nekdy muze hodit. Navic takto je mozno obnovit bud vse, nebo definovat regex, ktery zajisti obnovu pouze definovanych filu.

Heronovo reseni bude asi optimalni, nicmene muzes zkusit treba kombinaci (kdyz uz tu zalohu mas a restore se ti zda pomaly), kdy velky file obnovis lokalne a rsyncnes ho s tim ve virtualu (pokud tam nejaky je). Zalezi, jak moc se ta data meni, ale to vis nejlip sam.

Baculy bych se nezbavoval, je to pomerne sofistikovane reseni, ted uz umi i copy joby, takze se da zaloha z jednoho storage daemona automaticky migrovat na jiny storage daemon.

[Josef Kufner]

Doma používám na zálohování notebooku rsnapshot běžícím přes SSH. Každý večer zálohuju cca 200GB dat, která se moc nemění, trvá to tak 15 minut po lokální WiFi. Na serveru vzniká pro každý den adresář s kompletní zálohou, ale nezměněné soubory jsou deduplikovány pomocí hardlinků, takže to nezabírá moc místa. Obnova několika souborů je prosté zkopírování několika souborů. Na obnovu není potřeba vůbec žádný specializovaný nástroj – stačí to prostě zkopírovat přes minimální instalaci, nejlépe rsyncem. Kdybych nastavoval zálohování VPS, udělám to na druhou VPS stejně, jako to mám mezi notebookem a domácím serverem.

[pavele]

Zajímalo by mě omezení počtu hardlinků - jestli už někdo narazil na limity při zálohování na např. ext4 filesystému u rsnapshotu.

[Jendа]

Používal jsem rdiff-backup a po pár letech denních záloh několika serverů to začalo být šíleně pomalé. Tak jsem to smazal a teď zálohuju na btrfs s jeho snapshoty a zatím OK.

[Josef Kufner]

rdiff-backup používá vlastní formát ukládání historie. Má tam nějaké další soubory, ve kterých to je. A obnova starších verzí je hodně pomalá.

Počet hardlinků je omezen jen počtem volných inodů a těch je obvykle dostatek. Rychlost by neměla časem nijak klesat, neboť hardlinky nepřidávají na složitosti filesystému.

[pavele]

To btrfs zálohování - vidět jde jen poslední snapshot? Pokud bych chtěl procházet historií jednoho souboru jako u rsnapshot, jak je to složité?

[Max]

Většinou se pojmenovává snapshot datumem a časem. Snapshot je dostupný v adresáři. Tzn., že máš např. takovou strukturu:

/mnt/datastore/data
/mnt/datastore/.snapshots/20150510-0209
/mnt/datastore/.snapshots/20150511-0209
/mnt/datastore/.snapshots/20150512-0209

Snapshoty jsou dostupné běžně v RO režimu, lze i RW režim, který na okolní snapshoty ani aktuální "živá" data nebude mít vliv.
Porovnání jednoho souboru je tedy otázkou porovnání onoho souborů v jednotlivých snapshotech (adresářích).
Možná na to je nějaký nástroj, nebo si na to člověk musí napsat skript (pokud to chce nějak zautomatizovat).
Zdar Max

[Heron]

Nevím, jak tu historii souboru myslíš, ale btrfs snapshot se v userspace tváří jako obyčejné adresáře, takže se procházejí pomocí obyčejných nástrojů, tedy "historie souboru" může vypadat následovně:

ls -lh tomas*/.bash_history
-rw------- 1 tomas tomas 7.0K Jul 14 21:23 tomas_20150715-060001/.bash_history
-rw------- 1 tomas tomas 7.0K Jul 15 23:14 tomas_20150716-060001/.bash_history
-rw------- 1 tomas tomas 7.0K Jul 15 23:14 tomas_20150717-060001/.bash_history
-rw------- 1 tomas tomas 7.0K Jul 15 23:14 tomas_20150718-060001/.bash_history
-rw------- 1 tomas tomas 7.0K Jul 15 23:14 tomas_20150719-060001/.bash_history
-rw------- 1 tomas tomas 6.9K Jul 20 00:14 tomas_20150720-060001/.bash_history
-rw------- 1 tomas tomas 6.9K Jul 20 00:14 tomas_20150721-060001/.bash_history
-rw------- 1 tomas tomas 7.2K Jul 21 21:34 tomas_20150722-060001/.bash_history
-rw------- 1 tomas tomas 7.2K Jul 22 11:41 tomas_20150723-060001/.bash_history
-rw------- 1 tomas tomas 7.2K Jul 22 11:41 tomas_20150724-060001/.bash_history
-rw------- 1 tomas tomas 8.8K Jul 24 17:27 tomas_20150725-060001/.bash_history
-rw------- 1 tomas tomas 8.7K Jul 25 16:56 tomas_20150726-060001/.bash_history
-rw------- 1 tomas tomas 8.6K Jul 26 11:47 tomas_20150727-060001/.bash_history
-rw------- 1 tomas tomas 8.6K Jul 27 16:21 tomas_20150728-060001/.bash_history
-rw------- 1 tomas tomas 8.6K Jul 28 20:21 tomas_20150729-060001/.bash_history
-rw------- 1 tomas tomas 9.5K Jul 29 20:14 tomas_20150730-060001/.bash_history
-rw------- 1 tomas tomas 9.4K Jul 30 21:36 tomas_20150731-060001/.bash_history
-rw------- 1 tomas tomas 9.4K Jul 31 23:33 tomas_20150801-060001/.bash_history
-rw------- 1 tomas tomas 9.4K Jul 31 23:33 tomas_20150802-060001/.bash_history
-rw------- 1 tomas tomas 9.3K Aug  2 21:18 tomas_20150803-060001/.bash_history
-rw------- 1 tomas tomas 9.3K Aug  2 21:18 tomas_20150804-060001/.bash_history
-rw------- 1 tomas tomas 9.3K Aug  2 21:18 tomas_20150805-060001/.bash_history
-rw------- 1 tomas tomas 9.3K Aug  2 21:18 tomas_20150806-060001/.bash_history
-rw------- 1 tomas tomas 9.3K Aug  2 21:18 tomas_20150807-060001/.bash_history
-rw------- 1 tomas tomas 9.5K Aug  7 21:17 tomas_20150808-060001/.bash_history
-rw------- 1 tomas tomas 9.5K Aug  8 14:37 tomas_20150809-060001/.bash_history

Tedy je to v podstatě stejné jako u rsnapshot, kde jsou jednotlivé (stejné) soubory hardlinkovány, tady je jedná o COW kopie (reflinky).

[Jendа]

Jak už odpověděli jiní, normálně vidíš v adresáři subvolume tak jak tehdy vypadal.

Protip: vypněte pro adresář se snapshoty mlocate, recoll a další indexovací služby, jinak se z toho zblázníte :)

[Heron]

Takovou věc dnes ještě někdo instaluje?

[Jendа]

Ano, hlavně to mlocate. Jak jinak vyhledávat soubory (a nečekat věky)?

recoll používám jenom na vymezené adresáře, opět, jak jinak fulltextově hledat v hromadě dokumentů?

[Heron]

Tak pomocí find -(i)name. Mlocate má tu zásadní nevýhodu, že se jeho DB aktualizuje jednou denně (pokud se tedy nic zásadního nezměnilo), takže pokud člověk hledá něco aktuálního, tak to většinou nenajde. Pokud se u findu nehledá všude, ale jen v omezeném stromu, tak je to rychlé dostatečně.

[Jendа]

Tak pomocí find -(i)name.

~ # time find / -xdev -name "*xilinx*"
(...)

real	0m30.948s
user	0m1.600s
sys	0m2.248s
~ # time locate xilinx
(...)

real	0m1.627s
user	0m0.412s
sys	0m0.008s

Pokud se u findu nehledá všude, ale jen v omezeném stromu, tak je to rychlé dostatečně.

Většinou hledám ve větší části svého ~ nebo v /usr a /var.

[Heron]

tomas@raid:~$ time find / -xdev -iname find
real    0m0.480s
user    0m0.132s
sys     0m0.184s

První hledání.

Druhé potom takto (klidně na jiný výraz):

real    0m0.199s
user    0m0.108s
sys     0m0.088s

Ale tak pokud někdo má velký adresářový strom, nebo málo změn na fs, může použít nějakou indexaci. Já jen, že jsem to hodně dlouho nikde neviděl a neznám distro, které to má dneska by default (z výběru debian, centos, rhel > 5).

[j]

A co takhle si ujasnit rozdil mezi zalohou a archivem?

Zaloha se dela vzdy a pouze lokalne, s kratkou historii, vzdalene se uklada archiv, pro pripad totalnich katastrof. V takovym pripade bude to, ze archivni zaloha je stara tejden, to nejmensi co se bude resit.

BTW: Taky bejva dobry zatloukat hrebiky kladivem a ne sroubovakem. Ucelem lokalniho backupu je mimo jiny i to, aby se spocital v klidku a mimo provozni HW diff, a do archivu se posila jen ten, takze misto 30GB to bude tak 3, spis jeste mnohem min, vzhledem k tomu ze celkem tusim jak to ty "zmeny" vyhodnocuje, blah.