Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Btrfs send pracuje na úrovni pododdílu, takže pokud pošleš všechny, které potřebuješ (možná máš jen jeden), tak by to mělo být ono.
Nicméně u takovéto úlohy bych se nespoléhal na internetové diskuse ani na dokumentaci a prostě si to vyzkoušel sám. Pokud je těch dat moc, tak si stejnou konfiguraci nasimuluj s menším objemem dat a zkus si je poslat tam a zpátky (resp. na prázdný oddíl).
>btrfs subvolume snapshot -r / /.snapshots/root-$(date +%Y-%m-%d_%Hhod-%Mmin)
>sync
>btrfs send /.snapshots/root.../ | btrfs receive /media/data/Img/snapshots-root/
poslal na datový disk
a následně další snapshoty pomocí
>btrfs send -p /.snapshots/root... /./snapshots/root...2 | btrfs receive /media/data/Img/snapshots-root
řeším jako přírůstky, pak podle potřeby mažu staré snapshoty
a ten datový i s "obrazem" systémového zase jednou za čas pomocí rnsapshot posílám přes NFS na NAS
takže je to spíš záloha pro případ nějakého kolapsu na systémovém disku, nebo pro případ smazání něčeho co jsem nechtěl
akorát jsem zjistil, že vlastně nevím, jestli bude zpětně fungovat (na úrovni nakopíruj zpátky /etc /home /root určitě bude, ale jestli pomocí send | recieve obnovím celý oddíl/disk jsem ještě nezkoušel)
on to není úplně celý postup - mám datový a systémový disk na btrfs. Ten systémový jsem pomocí:Ale přesně to jsem měl na mysli. Představ si, že vznikne chyba, která způsobí, že ten FS nepůjde namountovat. No a ty ji pomocí send a receive zreplikuješ i na tu „zálohu“.>btrfs subvolume snapshot -r / /.snapshots/root-$(date +%Y-%m-%d_%Hhod-%Mmin) >sync >btrfs send /.snapshots/root.../ | btrfs receive /media/data/Img/snapshots-root/
poslal na datový disk a následně další snapshoty pomocí>btrfs send -p /.snapshots/root... /./snapshots/root...2 | btrfs receive /media/data/Img/snapshots-root
řeším jako přírůstky, pak podle potřeby mažu staré snapshoty
Ted nevim, jestli to dobre chapu - kdyz ten systemovy disk nepujde mountnout, tak ho nikam posilat nebudu, ale zkusim ho z toho datoveho obnovit.Měl jsem na mysli situaci, kdy vznikne chyba, systém stále běží, ale po rebootu už to mountnout nejde. (přiznám se, že jsem takovou chybu ještě nezažil, ale jinak mi btrfs dělalo „corrupt leaf“ i když pravidelný scrub bez problémů procházel)
A kdyz se sesype i ten, tak na sitovem disku bych mel mit zalohu systemu i dat z doby kdy vsechno fungovaloJo, to jo, ale asi bude starší než poslední snapshot.
Měl jsem na mysli situaci, kdy vznikne chyba, systém stále běží, ale po rebootu už to mountnout nejde. (přiznám se, že jsem takovou chybu ještě nezažil, ale jinak mi btrfs dělalo „corrupt leaf“ i když pravidelný scrub bez problémů procházel)
já už jo - na archu asi 2x co pamatuju - jednou to byl nějaký bugr v nvidia ovladačích řady 340, podruhé nesoulad mezi aktualizací jádra a zase ovladačů grafiky
první vyřešilo, že jsem chvíli (možná měsíc - už si to nepamatuju, ale řešil jsem to i tady na abičku) jel na nouveau
ovladačích a pak reinstaloval, druhé se bylo ráno opraveno - pacman Syu stáhnul novou verzi a bylo to ok
při obojím to ale nešáhlo na data - z konsole, nebo live distra jsem je byl schopný obsluhovat.
tím jsem se dostal k postupu, kdy zálohy dělám ráno, když počítač naběhne a tváří se funkčně, nebo když vidím nějakou větší aktualizaci, tak před ní + o co nechci přijít mezi aktualizací a před vypnutím (nebývá toho zas až tolik) kopíruju mimo zálohy na další disk, at to mám aspoň 2x
a jo - na sítovém je záloha starší, ale to beru jako přijatelné riziko - je to domácí počítač a nejdůležitější data (fotky/filmy) se tak často nemění a dost často jsou třeba ještě ve foťáku, nebo kameře - tam je mažu až když potřebuju místo na kartě
spíš teď louskám, jak funguje to send | recieve - jako princip se mi to dost líbí
Stejně tak můžeš říct, že mít disky, řadiče, paměti, procesory… jedné značky je riziko, protože by v nich mohla být chyba, která způsobí poškození dat. Pokud se např. spokojíš s tím, že RAM prošla memtestem nebo má ECC, tak proč se nespokojit s tím, že souborový systém prošel tvými testy a i sám počítá kontrolní součty dat?
Takže ono to není tak černobílé, není to buď a nebo – jde spíš o to, kde si nastavíš tu hranici a proti jakým rizikům se ještě chceš chránit.
Jasně, pokud to budou nějaká životně důležitá data, tak bych je pravděpodobně taky zduplikoval na dva různé FS1 nebo ta nejdůležitější vytiskl na papír :-) Ale asi bych se vyhnul kategorickým soudům typu: „když je to stejný typ FS, nejde to považovat za zálohování“.
A spíš než dávat data „jen tak pro jistotu“ na různé FS mi přijde smysluplnější nějak kontrolovaně upgradovat Jádro a ověřovat, že po aktualizaci daný FS funguje pořád stejně dobře. Tzn. mít nějakou sadu testů, která bude ověřovat integritu dat na disku a pouštět ji na různých prostředích. Takže pokud by se v nové verzi objevila chyba, můžu zastavit aktualizace a nenechat si zničit data tam, kde mám zálohy.
[1] např. plné zálohy dělal na jiný FS a inkrementální dělal přes snapshoty odesílané jen na jiný disk se stejným typem FS
sám počítá kontrolní součty datPozor, kontrolní součty u btrfs pouze říkají, že tam je to, co tam zapsal, nikoli že je FS konzistentní.
Takže ono to není tak černobílé, není to buď a nebo – jde spíš o to, kde si nastavíš tu hranici a proti jakým rizikům se ještě chceš chránit.Jo, je škála možností od lidí, co tvrdí, že zálohy nepotřebují protože mají RAID1, po lidi, co data tesají do kamene. Já jsem jenom chtěl upozornit na tohle riziko, které podle mě není na první pohled úplně zjevné (alespoň pro člověka jako já co do teď dělal zálohy rsyncem/rdiff-backupem) a pro mě osobně už je trochu přes čáru (hlavně vzhledem k tomu co jsem s btrfs zažil).
tak bych je pravděpodobně taky zduplikoval na dva různé FSTady nejde o to aby to byly dva různé FS (ve smyslu ext4 a XFS), ale aby se nepoužíval ten přímý způsob replikace změn.
To nedela zadnej diff, […]. Jinak receno, veme to bloky ktery se od minule zmenily […]Tedy, udělá to diff. Že se ten diff počítají snapshoty průběžně je druhá věc. Právě proto se ptám, jak to btrfs dělá interně, neboť od toho se odvíjí odolnost vůči chybám a chování v krajních případech.
[root@archlinux marek]# ls /media/data/Zalohy/
arch deska lko snapshots-data snapshots-root
(snapshot /media/data/ je uložený do /media/data/Zalohy/snapshots-data)
[root@archlinux marek]# ls /media/data/Zalohy/snapshots-root/root-2019-05-28_16hod-01min/
bin boot dev etc home kdeinit5__0 lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
[root@archlinux marek]# ls /media/data/Zalohy/snapshots-data/data-2019-05-28_16hod-11min/Zalohy/snapshots-root/root-2019-05-28_16hod-01min/
[root@archlinux marek]#
snad jsem to napsal trochu srozumitelně a dá se to pochopit - když tak mě nekamenujte prosím
[…] tak sa to neprepise do zalohy, pretoze to nie je "oficialny" update bloku […]A jak se liší oficiální od neoficiálního? Na disku ty bity jsou stejně ať je někdo zapsal úmyslně, nebo se změnily chybou. Asi někde nebude sedět nějaký checksum. Otázka je, co s tím btrfs send/receive provede, zda ten checksum bude v daný okamžik kontrolovat a zda pochroumaný blok prostě nepošle dál tak, jak je. V těchto situacích to bude navíc doprovázené nějakou chybou v implementaci toho filesystému, takže stát se může prakticky cokoliv a je na přijímajícím konci, aby si s tím poradil a zajistil konzistenci a úplnost zálohy (nebo to alespoň ohlásilo chybu).
Asi někde nebude sedět nějaký checksum.Ne, checksumy se v btrfs počítají právě z těch bloků, ale už nic neříkají o konzistenci FS. Podařilo se mi vyrobit btrfs, které projde scrubem (který tyto checksumy kontroluje), ale čtení souboru skončí s corrupt leaf.
Tiskni
Sdílej: