Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Řešení dotazu:
Systém na konzistentní on-line zálohání asi nebyl prvotně navržen, takže jediná šance je zjistit zda použité technologie něčím na své vrstvě nedisponují.
Určitě bych začal klasifikací jaká data a kdy se mění. Případně do návrhu řešení zohlednil i to, zda v případě využití definované retence záloh (tj. doba než se záloha přepíše další zálohou) nemohu požadavek na obnovu (typicky atomického souboru) pokrýt z předchozí/následné zálohy.
Případně zda je technicko-organizačními opatřeními přijatelné zajistit neměnnost některých dat(souborů) po dobu záloh.
Například: MySQL má údajně umožňovat binary log, což předpokládám je protokol změn DB nejspíš obdoba archive log režimu u Oracle RDBMS (sloužícímu mj. k umožnění on-line backupu), manuál MySQL naznačuje i možnost replikace na slave a vykonávání záloh až na něm. https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html
Další nezmíněnou otázkou je křížová konzistence, tam kde v rámci procesu vznikají související data napříč technologiemi (DB, FS). Tam může být řešením (pokud to tedy technologie umožňují, preference umístění souborů do DB, tedy za předpokladu její podpory konzistentního zálohování a dostatku zdrojů.
Je třeba také zvážit zda případné řešení (díky zvýšenému opotřebení) nepošle do pekel SSD dříve než by bylo zdrávo.
Či zda řešení svou komplikovaností nezpůsobí větší nedostupnost či ztrátu dat, než nedokonalé jednoduché zálohování.
Backup/recovery není stav, ale proces. Nedílnou součástí by mělo být periodické ověřování scénáře obnovy (Murhyho zákony fungují v IT ještě účiněji než jinde a není dobré být nemile převapen).
Fascinuje mne obecně rozšířená fascinace technikou snapshotu.
Fascinuje mne obecně rozšířená fascinace technikou snapshotu.Nuž, keby si používal snapshoty VM na úrovni hypervízora typu VMware alebo Hyper-V, tak by to nebola až taká fascinácia.
Napadá vás jiná metoda, ideálně taková, která zachová konzistentní systém a nebude vyžadovat rebootování do pomocného Linuxu?
To dnes už nikoho nemusí "napadat" — taková metoda už dobrých 8 let existuje a funguje. (Dokonce existuje i déle než desetiletí, pokud vezmeme do úvahy ještě ZFS.)
…umí zmíněné řešení zajistit konzistentní snapshot napříč všemi?
Ne.
Mimo jiné proto se doporučuje nedělit zbytečně prostor na různé filesystémy. A proto také Btrfs podporuje RAID na úrovni filesystému — jediný skutečný RAID, který není pouze AID s iluzí redundance.
Nicméně pokud jde o databáze, většina z nich má (pokud vím) pořád ještě problém s využitím Btrfs. Pokud používají Btrfs stejným stylem, jako by to byl nespolehlivý filesystém ve stylu 90. let (Ext4, JFS, XFS atd. atp.), zpravidla to s sebou nese velmi chabý výkon.
Osobně si nemyslím, že ve standardní implementaci RAID1 se hlasuje o výsledkuDefaultně během běžného provozu ne, minimálně Debian a CentOS ale každý měsíc (cronem) přečtou všechny disky ze všech RAIDů a kontrolují to.
Takže si dovedu představit paranoidní implementaci, kdy se povinně vyčítá stejný stripe ze všechny členů a o správném výsledku rozhodne většina.Ano, ale to vyžaduje větší redundanci než se běžně dává (např. RAID1 se 3 kopiemi, RAID5 nejde vůbec, RAID6 jde; pokud se taková chyba zjistí během rebuildu, tak máš zase smůlu).
Pokud si vzpomínám tak v devadesátých letech na Novell SFT III byla na úrovni storage redundance min. 800%, takže proč ne.Osobně mi přijde overkill mít redundanci nad 200-300%, pak je větší pravděpodobnost, že shoří něco jiného a stejně budeš muset obnovovat ze zálohy.
rsync -a -H -A -X --exclude '/proc/*' --exclude '/sys/*'Z běžícího slackwaru a pak jsem měl rozházený služby. Takže bych doporučil to dělat třeba z nabootovanýho systemrescuecd. Jinak funguje to super. Taky by šla použít clonezilla.
-x, --one-file-system don't cross filesystem boundariesjinak rozhazene sluzby? nevim co tim myslis, kazdopadne s Ubuntu/Debian/Mint to za chodu funguje za predpokladu
rsync -avH --delete --exclude=/mnt/ --exclude=/proc --exclude=/dev --exclude /home --exclude=/sys / /mnt/storage/AutoBackup/DebServer/... takže lepší bude:
rsync -avHx --delete --exclude=/mnt/ --exclude /home / /mnt/storage/AutoBackup/DebServer/.. jinak pokus o obnovu se uplne nezadařil, ale spíš byl problém na úrovni LILO/GRUB. Další pokus chci udělat přímo se systémem ze serveru, kde je Debian s custom kompilovaným jádrem, bez initramfs, fstabu kde jsou UUID místo klasicky /dev/sdxx apod.
--numeric-ids
nebo to správně namapovat).
Co se týče bootování, osvědčilo se mi udělat na obnovovaném stroji minimální instalaci ve stejné verzi jako je obnovovaný systém a tuto instalaci pak přeplácnout zálohou. Vyřeší se tím rozdělení disku, bootloader, minimální /dev i instalace rsync a ssh.
[...]Vyřeší se tím rozdělení disku, bootloader, minimální /dev i instalace rsync a ssh.to mi pripomelo ze sem zapomel, uz sem to s nekym(kdo me na to take upozornil) zde pred casem resil, --one-file-system opravdu vynecha zakladni zarizeni v /dev, misto --one-file-system je tedy vhodnejsi:
sudo mount --bind / /mnt/holej_rootfsa pak rsyncovat misto / prave ten /mnt/holej_rootfs, tim se nesyncuje jak proc, sys tak dev (kde v nabehlem je zarizeni generovane udev), ale prave ze se ponechaji ty zakladni/vychozi/staticke zarizeni v /dev...
Tiskni Sdílej: