Názory k článku Domácí zálohování dat pomocí dvou úložišť a nástroje Syncthing

Nešlo by to řešit přes BTRFS, že by to znělo
rovnou kompresii, deduplikaci a verzování? :-)

https://www.root.cz/clanky/souborovy-system-btrfs-jak-pohodlne-a-efektivne-zalohovat/

18. 5. 2021, 02:35 editováno autorem komentáře

Presne tak priklanam sa aj ja za BTRFS. Sam ho pouzivam ako NAS v rezime mirror (raid1).

BTRFS dokaze za jazdy pripajat/odpajat disky a samo sa stara o to, aby tie iste data boli na 2 fyzickych diskoch. Ja mam napr 3TB+3TB+6TB. Ak dojde miesto pridam dalsi 6TB disk a spustim ballance.

Jasně šlo. Zvolil jsem syncthing pro jednoduchost a možnost připojit i jiné platformy jako android a windows a je to pod jednou aplikací.

Také jsem pro btrfs. Mám ho na domácím úložišti (10 TB RAID1 - 3 + 3 + 3 + 3 + 8 TB) a můžu disky libovolně přidávat/odebí­rat/měnit za chodu. Dál to samozřejmě umí i snapshoty kvůli zálohám.

Jinak myslím že používat dnes RAID5 vzhůedem k ceně disků už nedává smysl a nestojí za potenciální problémy.

BTRFS by to řešit nešlo, protože autor chce zálohovat. Pokud by se mu sesypal libovolný FS na jednom stroji, tak na druhém data má. V případě BTRFS (nebo ZFS nebo libovolného jednoho FS) pří pádu FS přijde o všechno (což by se mu stalo i dříve, dokud používal jen jeden RAID). Takže si vlastně polepšil. RAID, ani snapshoty na stejném FS nejsou záloha.

Snapshoty nejsou záloha, ale prostředek zálohy. Já to dělám tak, že každý den o půlnoci odesílám snapshot na zálohovací stroj, což je RPi, které mám u rodičů. Přenáší se pouze změmy, a mám tam historii snapshotů 30 dní zpět.

Já bych se bál, že btrfs send/receive nebude odolné proti úmyslně rozbitému vstupu (a nebo ani neúmyslným chybám), a poškodíš FS tak, že se nedostaneš ani k předchozím snapshotům. Proto raději používám rsync (a následně snapshotnu výsledek).

Tuším, že btrfs_send / recieve je tvořen vlastně streamem příkazů, co se má na cílovém FS nastavit. Takže by to mělo být vcelku odolné.

Např. vím, že se rozumně chovalo, když jsem se snažil "receive" stream na zařízení, které nemělo v kernelu zakompilované extended permissions (Asustor NAS, "vyřešil" jsem to instalací vlastního OS, čímž jsem ovšem přišel o veškeré přednosti toho, že to je NAS a moh sem si rovnou postavit něco vlastního, žejo....).
Při prvním pokusu o nastavení těch extended práv, to zařvalo, receive se ukončilo, a v cílovém FS zbyl korektně vytvořenej subvolume, jen s "polovinou" obsahu co tam měl bejt.

Takže bych si tip, že to vcelku rozumně odolné bude. Samozřejmě, chyba může bejt všude....

Rsync a snapshot – dával bych tu bacha na rsync, zejména u obecných věcí, kde se mohou například přesouvat soubory. Rsync oproti snapshotům nemusí zachytit konzistentní stav. Dávalo by mi naopak smysl udělat prvně snapshot a z něj pak rsync.

Přesně tak snapshoty na jiný disk. A synchronizaci z androidu jde řešit pořád přes syncthing nebo rsync.

Cele riesenie ma este jeden problem a to je georedundancia. Jeden barak je velmi blizko. Tu sa da vyuzit prave vlastnost syncthing, kde je to mozne umiestnit uplne kdekolvek, teda aj u kamarata doma. Treba mu do ruky dat nieco ako https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/ a nech to zapoji do siete. Vzdialeny pristup riesim cez wireguard.

Syncthing je inak velmi zaujimavy nastroj, pouzival som ho, ale iba v jednosmernej synchronizacii na zalohovanie.

Ako domaci NAS mam https://kobol.io/helios4/, kde je RAID, ale RAID nie je backup. Na tom okrem, ineho bezi aj NextCloud a data sa mi synchronizuju cez 2 pocitace, teda mam 3 kopie /2x notebook, 1x nas/

Provozuji Odroid-HC2, má bohužel SATA připojený přes JMicron JMS578 USB 3.0 to SATA Bridge, pokud nepotřebujete dávat více zařízení na sebe (stackovatelnost), tak asi bych dnes volil spíše Odroid-HC4, ten má SATA připojen přímo k PCIE.Původně mi to vůbec nevadilo, ale když jsem začal provozovat nextcloud, tak se přístup na disk stal úzkým hrdlem.

u mna incrementalna zaloha na plateny cloud pomocou duplicati (https://www.duplicati.com) - zalohy su samozrejme sifrovane ;-)

Moc pěkný článek, díla za něj. Inspiroval mě sepsat moji zkušenost do blogu, sem napíšu jen krátkou reakci. Prošel jsem si velice podobným poznáním, ale výsledek je trochu jiný. Dlouhá léta jsem se pokoušel udržovat RAID5, nejdřív btrfs, ale to ještě není stabilní, tak jsem přešel k mdadm, ale tam nelze rozšiřovat pole, takže jsem skončil u komerční NAS Synology, která řeší RAID5 i rozšiřování a hlavně, má naprosto parádní GUI, to se. nedá například s OpenMediaVault vůbec srovnat. Jinak jak píše kolega v komentáři, neřešíš geobackup. Pro ten jsem zvolil https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/ který mám u rodičů s jedním velkým diskem. Ale pro jednosměrnou synchronizaci nepoužívám Syncthing, ale klasicky rsync. Je mnohem rychlejší pro velký počet souborů. Syncthing používám pro oboustrannou synchronizaci desktopů navzájem, samozřejmě přes domácí server, aby nemusely být oba desktopy zapnuté v jednu chvíli.

Jsem si vědom, že geobackup nemám pořešený a ani momentálně nemám jak pořešit. Nicméně Syncthing umí sdílet mimo interní síť. Takže je možnost vyřešit i tento problém.

18. 5. 2021, 09:27 editováno autorem komentáře

To nemáte rodinu, známé, ke kterým byste takové zálohovadlo mohl strčit? Já mám na tohle RPi s externím diskem u rodičů.

Tohle tady nechci rozebírat.

Existují velmi levné raspberry pi hostiny, to by mohlo být řešení.

Nakonec jsem sepsal blogpost o tom, jak to mám doma já https://www.miroslavbucek.cz/blog/konecne-reseni-zalohovani/

s mdadm jde pole rozsirovat uplne v pohode, uz jsme to nekolikrat resil za behu a dokonce vzdalene

Já syncthing používal pár let zpět na synchronizaci PC, NB a telefonu. Do té doby než jsem připojil nový telefon a syncthing si to vyložil jako, že jsem všechno smazal a smazal mi to všude. Naštěstí jsem měl další zálohu a přešel jsem na btrfs.

To by me zajimalo jak jsi to nastavil ze ti to syncthing smazal? Kdyz pridavam nove zarizeni, tak ho necham najit si nejaky muj nod, a nasdili se mu data ktera jsou tak nastavena. Pak provede prvni stazeni dat a vsechno ok.

V dřevních dobách tam opravdu několik bugů tohoto typu bylo, obzvlášť na Androidu, kde se do toho míchá hromada media scannerů a dalších služeb. Ale to bylo tak 2017, od té doby je to už dospělý produkt.

Jak bych to asi dělal. Přesně jak píšeš, našel jsem si svůj nod a vybral jsem si složky jaký jsem chtěl mít na tom zařízení.

Přeju ti, aby jsi neměl stejný problém. Radši si zálohuj někam stranou, kam syncthing nedosáhne. To mně poučilo, abych nedůvěřoval a radši víc zálohoval.

Koukám do logu a začal jsem syncthing používat v roce 2016 a ukončil jsem ho v roce 2017.

[2016-06-08 14:30] [PACMAN] Running 'pacman -S syncthing'

[2017-08-11 09:46] [PACMAN] Running 'pacman -Rs syncthing'

Jak uvádí Cabrón asi tam ty chyby byly. Vím, že to mělo v tý době problémy se SD kartou. Sice dřevní doba, ale moji důvěru už si to nezíská.

No ja syncthing nepouzivam na zalohovani, jen na synchronizaci. Pamatuju si ze kdysi bylo v navodu psane, ze syncthing neni na zalohovani urceny, i kdyz ted uz to tam nemuzu najit. I tak doufam ze uz ty chyby jsou fuc.

ja mam napr REDMI telefon a ten ponuka cistenie disku. A to cistenie mi raz zmazalo .syncthing adresare. takze verim tomu ze sa to mohlo "samo" zmazat. Nie je to chyba androidu je to vylepsenie Xiaomi.

mně na tomhle způsobu zálohování vadí, že nemohu oddělit data jednotlivých členů domácnosti, že se cokoliv špatně maže a data pouze přibývají nebo naopak nad mazáním není kontrola a není možné mít něco jako 30 dní koš.

18. 5. 2021, 09:28 editováno autorem komentáře

Data členů domácnosti, odděluji složkami. Víc jsem zatím nepotřeboval.
Nevím jak dříve, ale Koš na 30 dní je možné nastavit.

Syncthing je IMHO dobrej na synchronizaci např. notebook - domácí NAS. Což vyřeší nějakou část zálohování, ale ne vše.

Na opravdový zálohování jsou ale lepší technologie, např. BTRFS/ZFS + snapshoty. Jednak je to rychlejší, jednak tam je historie, jednak jde opravdu o kompletní kopii 1:1 (u syncthing např. nejde zálohovat konfigurace samotného syncthingu) a jednak při dnešní ceně disků bych nechtěl mít "hlavní úložiště" bez RAIDU kvůli spolehlivosti.

Samozřejmě, pak je ještě třeba vyřešit "geografickou zálohu", pokud to má bejt "neprůstřelný".

18. 5. 2021, 09:46 editováno autorem komentáře

Univerzální řešení neexistuje. Syncthing jsem používal, dokud se mi nedojebal disk s OS a konfiguracemi. Dávat to znovu dohromady se mi už nechtělo (+ minimálně týden trvá synchronizace dat). Teď prostě vložím disk, udělám zálohu přes cobian a uložím do skříně. Tu samou zálohu kopíruju ještě do NAS. Tím mám alespoň nějaké verzování. Sice přijdu občas o kus nekritických věcí, ale časově to vyjde ve výsledku lépe. Z notebooku jsem udělal holý systém, z kterého se napojuju na pracovní PC.
Složité konfigurace (visual studio, simatic), kde jen samotná instalace a nastavení trvá týdny, mám na serveru na zfs virtuálech, které zálohuji celé přes snasphoty a kopíruji na NAS.

Hezky den ve spolek,
take se snazim delat neco podobneho. Z obousmertne synchronizace jsem se vylecil - chyba na jedne strane = chyba vsude. Svuj "komercni" NAS zalohuji take na Raspberry s externim HDD rameckem - zaridil jsem to tak, ze jsem koupil i-tec MySafe USB 3.0 (neni to idealni volba, priste bych kupoval jiny - napriklad musite upgradovat FW + nastavit timeout pro usinani HDD, vyrobce prodava s hodne historickym FW), osadit jen jednim diskem a misto druheho zabudovat to RPI. Napajeni RPI ze SATA power konektoru do GPIO headeru (ustrizena redukce), takze jen jeden napajeci zdroj. Chlazeni je kontrolovane RPI - zalohuji jednou dene a kdyz to nic nedela, HDD spi, RPI vychladne pod 60degC a ventilator vypne. Napoveda pro ne-hardwerare - GPIO ovladajici ventilator je potreba posilit FETem (treba BUK9832), Gate navic pripojit pres odpor cca. 33k na 3V3 z RPI - tim padem vetrak jede kdyz je RPI v resetu, take je potreba dioda antiparalelne k vetraku, aby pri vypinani induktivni zateze prepetova spicka neodpalila FET.
Nepouzivam Syncthing ale Borg, a protoze jsem na SW natvrdly, s GUI - Vorta. Instalovano pres Flatpak na 64-bit RaspberryPi-OS. Uvitam komentare od ostatnich kdo pouzivate Borg / Vorta !!!

Ked uz tu vidim BORG, tak som popisoval iba domace zariadenia.

Servery sa zalohujem cez restic, co je podobne ako borg. Ale servery to by bolo na samostatny clanok a kazdy to z nas robi po svojom.

Ahoj,

nedavno som i ja spravil switch na Borg. Povodne som pouzival duplicity + MediaFire backend, ale to bol krok vedla. Pomaly upload, pomale mazanie (MediaFire sdk je uz niekolko rokov bez maintainera a teda aj ked by sa dalo vela callov urychlit, jaksi to nema kto spravit), pomale prechadzanie fuse mountu, zavislost jednej inkr. zalohy na dalsej (a nasledne teda bud sialene dlhy backup chain a dufat, ze sa to pri restore nerozbije alebo niekolkodnovy upload dalsieho fullbackupu) - zalohy boli utrpenie.

A potom som nahodou narazil na Borg. Vlastne mal vsetko veci, ktore som od backupu ocakaval (mozno chyba len sirsia podpora backendov): sifrovanie, deduplikacia, kompresia (ale ta sa na mojich backupoch nejak neprejavuje - asi tym, ze vacsina su videa/fotky), ziaden koncept full/incr backupov, slusny vykon a aktivny vyvoj. No a nakolko sa v testoch osvedcil, tak pomaly migrujem nan.

Rsync.net ma specialny pricelist pre Borg (https://rsync.net/products/attic.html - ceny MediaFire su o dost nizsie, ale ta rychlost je tiez inde) a tym mam poriesenu georedundanciu (datacenter vo Svajciarsku), druhy backup ide do domaceho NASu a treti pojde raz za cas offline na nejaky ten spare disk.

Rovnako pouzivam Vortu - akurat dufam, ze sa vyvoj trosku rozbehne, este dost veci mi tam vadi/chyba.

Kdesi som videl odporucanu kombinaciu rear (http://relax-and-recover.org/) + Borg, ale toto asi ja potrebovat nebudem.

j

Nevím jak bych bez Syncthing fungoval. 2xPC, 2xNTB, telefon a gigabajty dat (do cloudu to prostě nevleze bez paušálu). Takhle mám taky doma jen píchnuté Raspberry ať je pořád nějaký node online a šlape to pěkně už několik let.

XigmaNAS jsem tady jeste nezahledl, kazdopadne neznam lepsi reseni.

Pozor, syncthing není zálohovací nástroj a poté co jsem přišel o část dat, mi to potvrdili přímo i vývojáři syncthingu s větou, kterou zopakuji pro jistotu ještě jednou: syncthing není zálohovací nástroj!

Je tu několik důvodu proč: jednak pokud nemáte všechny zařízení pořád živé, může se stát, že některé soubory se prostě nezesynchronizují. Další věc je, již zmíněno i v diskuzi, při smazání souboru dojde k replikaci této operace všude a hrozí i horší věc - po přidání zařízení se z něj stane master a vymaže to vše.

Ano vše jde řešit, je tu verzování, ignore-deletes direktiva a read only režim, sync přes více úrovní, atd ale je třeba na to myslet a nezkušený uživatel by mohl nabýt dojmu, že mu všechno funguje i když to tak není (tak jak se to stalo i mě). Takže, před nasazením na ostrá data doporučuji otestovat zda všechny popsané scénáře opravdu dávají plánováné výsledky.

A btw syncthing jede v pohodě i na 512MB RAM.

Odložím si tu sem https://infinit.sh.gruntech.org/product

Měl bych dotaz na autora úplně nesouvisející s článkem, protože mou pozornost mimo vlastní téma upoutalo i tohle: vypínání Wi-Fi na noc, v domě mám dvě AP, jeden D-Link a druhý TP-Link a mám nasimulované klikání v jejich GUI.

Jen tak ze zvědavosti, jak to je realizované? Je to jen přehrání nějakého sledu událostí, nebo je tam i nějaká zpětná vazba?

AP mají přístup přes webové rozhraní a pomocí chrome-driveru je nasimulované klikání myší, jak se dostat k checkboxu pro ovládání wifi, kde se dá zkontrolovat zda je zaškrtnutý nebo odškrtnutý, provést požadovanou akci a uložit formulář. Když bych na to během dne sáhnul a wifi vypnul, tak večer pochopí, že je vypnutá a hloupě ji nezapne. Na toto jste se ptal?

18. 5. 2021, 11:40 editováno autorem komentáře

Ano, přesně na to jsem se ptal. Děkuju za odpověď!

Vypínání a zapínání Wi-Fi podle nějakého rozvrhu mají snad všechny routery, co jsem za posledních 5-10 let měl v ruce. Namátkou Dlink, Mikrotik, Netgear. Samozřejmě to lze nasimulovat v nějakém Selenium-based nástroji, ale otázkou je proč.

Alespoň v mém případě. Protože pokud jsou routry v režimu bridge a tak přestala fungovat aktualizace systémového času a plánování zapínání a vypínání přestalo úplně fungovat. Za další pokud v noci vstanu jsem schopen wifi přes raspberry zapnout jedním příkazem a udělá to asi za 5s.

Mně by spíš zajímalo, jaký smysl má vypínat WiFi na noc.

Možná někdo věří, že mu Wi-Fi narušuje kvalitu spánku.

Nebo nechce, aby děti místo spánku v noci pařily na mobilu ;)

Vetsinou lidi kteri maji hned na protejsim baraku BTS :-P

Kvalitu spanku spis narusuje debilne udelana elektronika ktera crci a piska - tj produkuje slysitelny zvoj. Pak taky EMG vlny maximalne desitky Hz a to uz s tim musim spat u hlavy a mit nejaky naprosty kram. To jsou jedine prokazana ruseni ktere bezny clovek (tj. ne pracovnik u vysilacu nebo radaru) muze pocitit.
Plus beru v potaz par vyjimek jako blbe udelane zuby funguji jako detektor v blizkosti rozhlasoveho vysilani.

Nezapomeňte, že všechno, co lze zapojit do elektřiny, má modrou ledku, která i po přelepení prosvítá spárami a otvory v krabičce (Číňan tím asi brání nočnímu zatemnění pro případ bombardování).
Čistě pocit "mám vysílač kousek od hlavy a co kdyby" může prokazatelně zhoršit spánek. Pak je prostě nejzdravější neplýtvat energií na sebepřesvědčení (vědeckých studií lze přečíst mraky, ale ono i kouření a azbest byly svého času OK, takže stín pochybností zůstane) a vypínat.
Krom zvuku, světla a pocitu může jít o (sebe)disciplínu - v noci se spí a tečka. Jako bonus se sníží zarušení sítě sousedům :-)

Spíš bezpečnostní hledisko: do vypnuté wifiny se žádný útočník nedostane. ;o)
Já sice na noc nevypínám (jede mi přes ni "technický" provoz), ale taky si jednotlivá AP zapínám "jen když potřebuju".)

To je trochu rozdil nez uplne vypinat. Tohle delam taky. Napr pri odjezdu na dovolenou.
Na technicky provoz preci jen je dobre mit wifi zapnutou. Ne vzdycky ma v noci chut podivat se jak zapojit ethernet kabel do mobilu kdyz zacina meeting.

Deti se sami musi naucit zodpovednosti a ja jim cely zivot za zadkem stat nebudu abych je hlidal jako andel strazny. Ja jsem jen pruvodce, ne rodic diktator.

Bohuzel mam taky trochu sloziteji udelanou sit, protoze ta hujaja krava od vodafonu neumi/ma v provisioningu deaktivovane vlany a CTU mi stale neodpovedel na pravo uziti vlastniho koncoveho zarizeni.

Dříve to bylo, abych se neponocoval, najednou nejde wifi a víte kolik je hodin, čas mi mnohokrát utekl. Pak jsou děti a těm je jedno, že jste v noci nespal a ráno by jste pospal. Ze stejného důvodu se vypíná switch, prostě nejde internet v domě ani nejde koukat na filmy, tak se se ženou sebereme a jdeme spát. Takto to máme asi 5 let a ve směs jsme s tím spokojení, jen na Silvestra čas protahuji. Všechno můžu během chvíle zapnout. Tím jak to jede na raspberry mohu všechno vypnout až dokoukáme film aj. možnosti. Ale k tomu prostě nebyl důvod. Neříkám, že to tak musíte mít. Nám to jen nedovolí sedět u počítače/tele­vize/mobilu/ta­bletu do noci. Ne-Čt se vypíná v 22:00 a Pá,So v 23:00. Normálně chodíme brzo spát, ještě před blackoutem, takže nás to neomezuje.

Osobne mam obdobny scenar (domace nas), kde som mal najprv mdadm v rezime raid10 s layout n3 (teda 9 diskov a vsetko bolo ukladane ako 3 kopie). Parkrat sa mi to rozislo (ono mat nejake lacne sata multiplikatory, ktore obcas odpoja disk nie je rozumny napad. Vyriesil to ale pasivny chladic, ale to uz preslo par rokov a od mdadm som odisiel). Uvedomil som si, ze mojim cielom je mat "zalohu" a nie "online redundanciu". Predsale, ked odide disk, nepotrebujem bezat dalej. Mozem si doma dovolit vypadok sluzby... Tak som skoncil na btrfs a cez send+receive som zalohoval na "lokalny" (cez nic moc linku a iscsi pripojeny) disk. Ten disk bol zaroven sifrovany lokalne. Takze lokalne btrfs bolo nesifrovane, ale to vzdialene uz bolo sifrovane. Problem v nestabilnej linke a zaroven moznost pri sw chybe pokazit "obe kopie" ma odviedli od tohoto riesenia. Aktualne som na jednom nasku (nejaky atom, 6 sata portov a dva z nich su obsadene multiplikatormi na 5 sata portov = 14 diskov. Tusim vsetko 320gb notebookove, relativne lahko vycitatelne pri chybe) a mam tam len btrfs raid 1... Obcas data vypalim na dvd, ale posledne vianoce nebola chut/cas, tak som kus bez zalohy... Geolokacne ale mam dve miesta, kam by som to rad dal, len nieto casu.

PS: Pekny clanok a aj popis sluzieb beziacich na rpi je pekny. Zaujimalo by ma viac o tych zaluziach...

Jsou to žaluzie od somfy, našel jsem článek jak to řešit pomocí vlastního HW. https://blog.grames.cz/clanky/ovladac-rolet-s-pohonem-somfy-rts/ ale šel jsem tou cestou, která je jedním bodem popsaná, že simuluji stisky tlačítek na originálním ovladači, protože na tak nízké úrovni HW nerozumím.

Z aliexpresu jsem pořídil desku s osmi relé a pomocí GPIO ovládám ta relé, která právě simulují ty stisky. Jaká se pak navěsí logika kolem je na fantazii a potřebách. Momentálně to mám asi 3 měsíce funkční. Ale nejlepší je když se zapne televize, tak žaluzie do kterých jde slunce se zavřou. Pak se zavíraj se západem slunce. A na léto plánuju, aby se nevyhříval dům, že to budu zavírat podle pohybu slunce.

Pohyb slunce jde pomocí API https://ipgeolocation.io/documentation/astronomy-api.html

Východ západ slunce https://sunrise-sunset.org/api

Na počasí mám https://api.weatherapi.com ale je to takové nespolehlivé, takže k tomu scrapuju z html data z meteostanic co jsou v okolí. https://www.meteo-pocasi.cz

Raspberry si s tím poradilo, daní je trošku snížená čtecí i zapisovací rychlosti. Konkrétně nyní zvládá čtení 35 MB/s a zápis 28 MB/s.

No to bude absencí instrukcí AES v Raspberry Pi. Daleko lepší je použít šifru chacha/adiantum. Jenoduchý test:

cryptsetup benchmark -c aes-xts -s 256
cryptsetup benchmark -c aes-xts -s 512
cryptsetup benchmark -c xchacha12,aes-adiantum
cryptsetup benchmark -c xchacha20,aes-adiantum

Pak přešifrovat disk by mělo jít pomocí cryptsetup reencrypt

To vypadá zajímavě, děkuji.

Ahoj, mě by zajímala ta android aplikace na tu garáž, to je něco univerzálního na https rest volání?

18. 5. 2021, 15:16 editováno autorem komentáře

Ne nic univerzálního to není. Napsal jsem si REST API a to si pak volám.

Děkuji za článek, zajímavé řešení a se Syncthing jsem také koketoval. Dříve jsem měl i 5 diskové Synology s Intel Atom (což ve své době byl v podstatě strop nabídky pro domácnosti a zasahovalo to do SMB). Už několik let provozuji vlastní server s mdadm + XFS a mám za sebou různé věci od rozšiřování pole, vyměňování disku, změnu úrovně RAID z 5 na 6 za běhu apod. Rozšiřování kapacity jsem řešil tak, že jsem prostě koupil větší disky a mám na nich menší partition, kterou ale časem můžu zvětšit.

Nedávno jsem si taky přikoupil (podstatně větší) disky a dal je do jiného stroje, kde mám RAID1/ mirror pomocí ZFS a první stroj na toto zálohuji pomocí rsync/ rsnapshot.

Jeden čas jsem si doma dokonce rozjel Baculu/ Bareos a dokonce jsem si připojil tape autoloader, ale nikdy jsem to nějak víc nezautomatizoval. Taky to mělo tendenci být hlučné řešení, což do bytu není úplně značka ideál, jestli mi rozumíte.

V současné době je hlavní server vzdálený od zálohovacího asi 200 km, takže jistá georedundance tam je. Hodně důležité věci mám dále v OrgPadu, kde se zálohy řeší samozřejmě ještě výrazně lépe a to je už samo o sobě redundantně vyřešené. Tam používáme kombinaci rsnapshot a borg a nestěžujeme si. :-)

Ludia to co mate doma za data? Sa tesite ze mate zakryptovanu zalohu svojich fotiek ktore sa nechce pozerat uz ani vam? Vsetci pracujete v NASA alebo pre tajne sluzby?
Zaloha kazdy vecer? Tolko nezalohujeme ani u nas vo firme, proste zijeme s tym ze stratime niekolko dni roboty ale pravdepodobnost je skoro nulova lebo keby k tomu doslo isto to ma niekto este na desktope.
Bezime aj kriticke aplikacie tam sa riesi zaloha DB cez redo logy ale bezne data ako su fotky, dokumenty a cele to este kryptovat, aj na disku aj zalohy aj ... nemate trochu paranoje?

Ono dost záleží na tom, kolik to bude stát, když to nepojede :) Vy ztratíte několik dní roboty, ale v jiné firmě se bude kumulovat práce týdny.
Když už je nastaven nějaký zálohovací systém, tak nevidím důvod nezálohovat tak často, jak to jde.

> v jiné firmě se bude kumulovat práce týdny
Nadpis clanku znie 'Domaci zalohovani ...' preto mi to cele nejde do hlavy o com tu je rec. Toto co tu ludia popisuju pre mna absolutne pre domace pouzitie nedava ziadny zmysel.

Je absolutně v pořádku, když Vy to děláte u sebe jinak. Někdo jiný ale může mít vyšší nároky, třeba se to prostě chce naučit a osahat si reálný hardware a RAID a provoz toho řešení na něco pro tu osobu užitečného. Někdo jiný se nechce spoléhat na cloud/ nemá rychlou linku a třeba rád fotí nebo točí zážitky se svou rodinou apod. Někdo rád hudbu a má obří kolekci bezztrátových záznamů. Někdo analyzuje jako hobby různá data a tam se taky věci rychle nashromáždí.

Někdo třeba jen vykuchá starý laptop, přidá druhý disk do RAID1 a ukládá si na to třeba zálohu dokumentů kolem domácnosti a pár fotek, které tu a tam pořídí. Na to bohatě dva např. 320 GB disky stačí úplně v pohodě a těm lidem se potom třeba lépe spí nebo co já vím.

Na presne to vsetko co ste napisal absolutne nepotrebujete kryptovane lokalne disky, kryptovane zalohy a ani zalohu kazdy vecer.

K velikosti dat: Ano, spousta toho jsou fotky, různé ripy DVD a CD s hudbou nebo filmy, část toho je takové odkladiště, když někdo např. přeinstalovává laptop a chce nějakou dobu mít jistotu, že opravdu nic nezapomněl. Dělá se potom prostě obraz disku...

Jinak já osobně se zabýval třeba analýzou síťového provozu z metadat, takže jsem měl i poměrně dost dumpů právě jenom těch metadat. I tak toho ale byly stovky GB. V OrgPadu dnes běžně něco natáčíme a potom se to různě stříhá apod. takže toho materiálu přibývá taky docela dost a bude se to muset řešit nějak koncepčněji, nejspíš pomocí toho NASu. Výsledný materiál je normálně na YouTube, ale to je zlomek celkových nároků.

Dělat věci "tak nějak" a dělat je už celkem slušně je z hlediska užitku velký rozdíl, ale z hlediska vložené práce je to hodně podobné. Pokud už se rozhodnete pro NAS/ skládání vlastního úložiště, tak řešíte hardware a různé nastavování a to je vždycky poměrně časově náročné. Myslím si, že už to potom chcete dělat na určité úrovni, když je ta investice času (a peněz) spíše netriviálního charakteru.
U někoho to může být paranoidní, ale ztratit pár dní práce je podle mě celkem hloupé, když se proti tomu dá technickými prostředky poměrně efektivně zakročit.

Jinak k těm fotkám. Ano, moc lidí se na to nedívá. Ale třeba po 10 letech si vzpomenete a potom budete koukat, že Vám půlka té dovolené chybí a že už na ni třeba nikdy nepojedete. Místo je zbořené, třeba protože shořelo, lidi stárnou a umírají, přátelství a vztahy obecně nemusí vydržet věčně. Někdo trochu té nostalgie ocení a potom mají třeba i amatérské fotky pro něj určitou hodnotu. Kdo si je jist, že na fotky koukat nebude si je prostě nepořizuje a vychutnává si moment samotný.

Většinou tak 100gb až 200gb z každé dovolené. Je pro mne mnohem levnější přidávat kapacitu než to třídit stylem : na této milionte fotce žere slon po7me stébla trávy a mi přátelé jsou zde v poloze 7A.

Ani nevíš jak se mi to 2 roky bez možnosti vycestovat hodilo.

A co set tyce zalohovani rodinná alba některá s fotkami temer sto let starymi taky nedavam jako podlozku pod kamna.

23. 5. 2021, 20:41 editováno autorem komentáře

Není čas ztrácet čas. Celý článek je o nějakém strašně časově náročném a navíc komplikovaném bastlu . Stačí někde udělat chybičku a data v ****.

Já bych to bral asi takto:

A) Dobrá varianta - ideálně Synology NASka na RADI5.
B) Lepší varianta - dvě NASky geograficky oddělené a synchronizované.
C) Ultimátní varianta - syncované dve NASky s odkopčením dat do cloudu.

Syncthing taky používám, ale na synchronizaci. Na zálohování je to nesmysl. Pokud přidávám zařízení, první týden je nastaveno jenom jako příjemce, pak zkontroluju data a povolím tomu i odesílání. Ještě jsem o nic nepřišel.

Záloha by nikdy neměla být jednou z pracovních kopií. V mým případě:
- O zálohu se zásadně nestará zařízení, kde jsou data. Při havárii disku je to jedno, útočník vodítka ohledně systému záloh a jejich URL ocení a pomáhat mu nehodlám.
- Na zálohy je stroj ve VLANě, který nemůže ven a je nedostupná z vnitřních sítí. To je obrana proti nechtěnýmu poškození (několik výhod offline zálohy).
- Zálohovací stroj jede na BTRFS, kapacita disků 150-200% velikosti zálohovaných disků. Mirror na několik disků (tohle kluci okolo BTRFS vymysleli dobře).
- Stroje jedou na BTRFS. Udělá se snapshot, který omezí dopad na uživatele a udržuje první level zálohy.
- Snapshot se zkopíruje RSYNCem do příslušnýho subvolume
- Vytvoří se nový subvolume s časovou značkou na zálohovacím stroji (verzování)

Zálohovací stroj má vždycky na TOPu aktuállní stav dat z posledního zálohování, snímky zaberou jenom tolik místa, kolik se změnilo dat...

V případě poškození dat je první instance lokální snapshot, druhá instance přihlášení na konzolu zálohovacího stroje a RSYNC.
Geo zálohu zatím nemám. A co se četnosti záloh týká, je to jenom jeden parametr...

Pouzivam na zálohy paskovou jednotku a m-disc blu-raye. Takže airgap a worm media prevazena do blize nejmenovaneho mista spratelene mocnosti.

Vsechno ostatni je jen "pojd na mne z boku" replikace ktera není odolna proti ransomware.

Nebo clovek by syncoval mesice s ubohym uploadem.

Nechápu ten Rsync. Proč ne rovnou snapshot zálohovaného a synchronizovat přímo ten? Takhle se data nutně duplikují.

V kanceláři máme 2x QNAP NAS a na obou jede jejich QuTS hero se ZFS a to už je jiné kafe ;-) Nastavený máme SnapSync (+ i Hybrid backup sync) a ve finále velká spokojenost i z toho důvodu, že jednoduše zapnu NAS, nastavím v GUI a celé to funguje, aniž bych ztrácel čas v příkazové řádce nebo studováním jiných možností.

Kdyby to někoho zaujalo, tak ideálně kouknout na informace tady:
https://www.qnap.com/quts-hero/cs-cz/
https://www.qnap.com/cs-cz/product/?conditions=4-3