Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Docela dlouho jsem pro zálohování dat a současně synchronizaci mezi počítači používal rsync. Při posledním spuštění skriptu a kontrole zálohy jsem však zjistil, že se něco stalo a dlouho funkční skript nefunguje. Nevím, zda došlo k nějaké změně přímo v rsyncu, v implementaci fatu, nebo je problém s flashkou. Pokud se zálohovaný soubor změní, skript ho na flasku nepřekopíruje. Po formátu flashky vytvořil skript pouze adresářovou strukturu bez jediného souboru, i když celá akce trvala srovnatelně, jako by se skutečně kopírovalo.
Protože mám teď docela dost času na hraní, a navíc mám o prázdninách všechny kompy doma, takže odpadá nutnost synchronizace (používám více méně jen jeden), rozhodl jsem se vyzkoušet rdiff-backup, který mi byl doporučen v diskuzi pod minulým zápiskem o zálohování.
Následuje jednoduchý skript, který se stará o zálohování:
[nik@venice ~]$ cat /etc/cron.hourly/rdiff_backup_0.1.sh #!/bin/bash #Backs up the whole $HOME directory to /backup/$USER #Specified directories are excluded #Cleans up backups older than specified time #Intended to be run by Cron daily or hourly #For more consult http://www.nongnu.org/rdiff-backup or man rdiff-backup #Put paths to $source and $target variables source=$HOME target="/backup/$USER" #How long to keep old backups period="1W" #Directories to be excluded e1="/home/nik/Dokumenty/Video" e2="/home/nik/Dokumenty/Hudba" e3="/home/nik/Dokumenty/Torrent" #Rdiff driven backup, rdiff itself makes log rdiff-backup --exclude $e1 --exclude $e2 --exclude $e3 $source $target #Chown rdiff-backup files chown -R $USER:users /backup/$USER/rdiff-backup-data/ #Removes older backups rdiff-backup --remove-older-than $period --force $target
Volby --exclude umožňují vyjmout jednotlivé složky ze zálohování, u mě se tak děje především kvůli nedostatku místa na cílové partici. Volba --force je při mazání starých záloh užitečná, bez ní nedojde ke smazání většího počtu starších záloh, což se projevilo rychlým zaplněním /backup.
Protože skript vytvářel adresář /backup/$USER/rdiff-backup-data vlastněný rootem, přidal jsem ještě řádek, který mění vlastníka na aktuálního uživatele. To mu umožní provést užitečné příkazy vypisující všechny diffy daného souboru nebo například zobrazit statistiky:
[nik@venice ~]$ rdiff-backup -l /backup/nik/japan.jce Found 5 increments: japan.jce.2008-07-18T12:01:01+02:00.diff.gz Fri Jul 18 12:01:01 2008 japan.jce.2008-07-20T11:01:02+02:00.diff.gz Sun Jul 20 11:01:02 2008 japan.jce.2008-07-22T13:01:02+02:00.diff.gz Tue Jul 22 13:01:02 2008 japan.jce.2008-07-22T14:01:03+02:00.diff.gz Tue Jul 22 14:01:03 2008 japan.jce.2008-07-23T10:01:01+02:00.diff.gz Wed Jul 23 10:01:01 2008 Current mirror: Wed Jul 23 18:01:01 2008 [nik@venice ~]$ rdiff-backup --calculate-average /backup/nik/rdiff-backup-data/session_statistics* --------------[ Average of 43 stat files ]-------------- ElapsedTime 67.14 (1 minute 7.14 seconds) SourceFiles 55040.2093023 SourceFileSize 15648105481.5 (14.6 GB) MirrorFiles 55023.1860465 MirrorFileSize 15629970536.8 (14.6 GB) NewFiles 101.209302326 NewFileSize 85438806.3721 (81.5 MB) DeletedFiles 84.1860465116 DeletedFileSize 65418928.5581 (62.4 MB) ChangedFiles 142.930232558 ChangedSourceSize 89133032.9767 (85.0 MB) ChangedMirrorSize 91017966.093 (86.8 MB) IncrementFiles 328.488372093 IncrementFileSize 67880095.186 (64.7 MB) TotalDestinationSizeChange 86015039.8837 (82.0 MB) Errors 0 --------------------------------------------------------
Obnovení zálohovaných souborů je možné několika způsoby:
Pokud důvod pro obnovu vznikl v době od poslední zálohy, stačí zkopírovat příslušný soubor pomocí preferovaného souborového manažeru, nebo konzole:
[nik@venice ~]$ cp /backup/nik/japan.jce japan.jce.orig
Pokud se něco pokazilo dříve, je vhodné nejprve zjistit, ze kterého diffu obnovovat (viz výše uvedený příklad vypsání diffů), a pak vybraný diff obnovit příkazem:
[nik@venice ~]$ rdiff-backup /backup/nik/rdiff-backup-data/increments/japan.jce.2008-07-18T12\:01\:01+02\:00.diff.gz japan.jce.2008-07-18
Mnoho příkladů použití nástroje rdiff-backup obsahují oficiální stránky projektu.
V této chvíli mě rdiff-backup chrání především proti vlastní nepozornosti. Pokud bych zálohu prováděl na druhý disk, případně na domácí server (ani jedno však v tuto chvíli nemám), byl bych docela dobře zajištěn i proti selhání hardwaru. S dostatečně velkou flashkou nebo externím diskem by šlo vyřešit i problém synchronizace.
Tiskni
Sdílej:
%dir1=file1 file2 file3 rdiff-backup delete dir1/file2 rdiff-backupked potom zavolam obnovu zo zalohy, znovu by to obnovilo aj ten file2? (to by som chcel, aby ostal zmazany
--force
, ale nejsem si jist, jestli v takovém případě nezačne rovnou z čistého stolu a nesmaže starší verze záloh. Pokud jsou porušené diffy, asi mu nic jiného nezbyde...
sync
, nevyprázdní se cache přímo na disku a po vytažení USB kabelu se to už bez napájení samozřejmě nezapíše. Řeším to tak, že před vytažením kabelu provedu hdparm -t /dev/sdb
, to obvykle pomůže.
getfacl /var/www/drupal/modules/ getfacl: Removing leading '/' from absolute path names # file: var/www/drupal/modules # owner: apache # group: apache user::rwx user:tomas:rwx group::rwx mask::rwx other::r-x #backup, restore - oba lokalni fs a umi ACL getfacl /root/tmp/modules/ getfacl: Removing leading '/' from absolute path names # file: root/tmp/modules # owner: apache # group: apache user::rwx group::rwx other::r-xŠkoda
#rdiff-backup --never-drop-acls /var/www/ /BACKUP/www Fatal Error: --never-drop-acls specified, but ACL support disabled on destination filesystem
#tune2fs -l LABEL=backup tune2fs 1.39 (29-May-2006) Filesystem volume name: backup Filesystem UUID: 15829cd4-5d25-496c-90f4-32d62ef7865c Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options: user_xattr acl
python-pylibacl
.
rdiff-backup-data
; samozřejmě při obnově to pak chce používat 'rdiff-backup -r ...
', jinak se práva k souborům neobnoví.