Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
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 ) ak by ho neobnovilo, je mozne sa vratit do nejakej starsej verzie, v ktorej by ten subor bol? viem si predstavit este viac 'okrajovych pripadov' (napr. ze by bol ten file2 znovy vytvoreny a zavolany rdiff-backup a clovek by sa chcel vratit k situacii bez file2, alebo so starsou verziou file2), ale toto by asi stacilo na rozumne zalohovanie...
--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í.