Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
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í.
Řešení dotazu:
rsync
umí zachovat metadata i symlinky. Al pokud chcete použít tar
, přenášejte rsync
em ten tar
. Ale přenášejte to po síti protokolem rsync
, jedině tak využijete inkrementální přenos. Pokud budete mít namountováno vzdálené úložiště do lokálního souborového systému a rsync
em budete přenášet jenom v rámci toho lokálního systému (a po síti se to bude přenášet jiným protokolem), bude to na přenos dat horší, než kdybyste to jenom zkopíroval.
Ale přenášejte to po síti protokolem rsync, jedině tak využijete inkrementální přenos.Měl jsem pocit, že rsync umí přenášet inkrementálně jenom pokud jsou ty stejné části v souborech do nějaké vzdálenosti. Takže když na začátek toho taru přibude nějaký velký soubor, rsync nebude schopen zjistit, že konec taru je stejný, a přenese to celé.
Pokud budete mít namountováno vzdálené úložiště do lokálního souborového systému a rsyncem budete přenášet jenom v rámci toho lokálního systému (a po síti se to bude přenášet jiným protokolem), bude to na přenos dat horší, než kdybyste to jenom zkopíroval.Můj rsync tohle detekuje a delta přenos vypne (pokud ho explicitně nevynutím), takže to vyjde nastejno jako kdybych to jenom kopíroval. (--whole-file) Doporučil bych správně nastavit rsync a netrvat na taru. Dobrý začátek je podívat se do manuálu na volbu -a, případně ještě --numeric-ids.
Chci aby záloha ve výsledku měla vlastnosti taru, tzv. zachování metadat, symlinků, atp.
rsync --numeric-ids -aHAX
(viz manuál)
A pak aby se ~1TB sesynchronizoval za pár minut.Já mám bohužel s rsyncem podivné výkonnostní problémy, nejspíš když je tam spousta malých souborů. Teď si tedy uvědomuju, že to může být strašně starou verzí rsyncu na druhé straně (RHEL5).
Měl jsem pocit, že rsync umí přenášet inkrementálně jenom pokud jsou ty stejné části v souborech do nějaké vzdálenosti.O žádném takovém omezení jsem nikde nečetl.
rsync
používá blok o nějaké velikosti, na serveru si nejdříve vypočítá kontrolní součty pro všechna umístění takového bloku. Tj. umístí blok na začátek souboru, spočítá kontrolní součet, posune se o jeden bajt, opět spočítá kontrolní součet (který je speciálně navržený tak, aby tuhle operaci vyhození prvního bajtu a přidání jednoho dalšího bylo možné udělat rychle). Neprocházet takhle celý soubor, ale jenom jeho část, by mělo jediný význam - ušetřit paměť. Pak načte první blok klient, odešle jeho kontrolní součet serveru, a ten se podívá, jestli ten kontrolní součet zná. Pokud ne, pošle klient všechna data, pokud ho server zná, oba ještě spočítají bezpečný kontrolní součet, kterým ověří, že jsou data opravdu stejná (že jen náhodou nevyšel ten první kontrolní součet stejně).
Co (a jak přesně) zatěžují ty hardlinky?Přiznám se že nevím. Jenom jsem ve škole rušil několik let provozovaný rdiff-backup, protože záloha několika serverů trvala týden, přičemž na ZFS-on-linux i na btrfs to bylo hned.
Tak jsem to spočítalTrvalo to docela dlouho ;). Tip pro příště: df -i.
root@archer:~# df -i /mnt/backup/ Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md1 0 0 0 - /mnt/backup
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda 0 0 0 - /
Některé nemají ani diskové oddíly :)
(hint: ne všechny filesystémy mají inody ;)Třeba které?
Přiznám se že nevím.No jo, no. Hardlinky ve skutečnosti souborový systém moc nezatěžují - je to jen zvýšený inode count + mapování ve tvaru "jméno:inode" v adresáři. Nejsou to opravdové soubory/inody.
Jenom jsem ve škole rušil několik let provozovaný rdiff-backup, protože záloha několika serverů trvala týden,Rdiff-backup není rsnapshot. Je to zálohovací program klasického schématu, který uchovává rozdíly k souborům. Používá přitom stejné algoritmy jako rsync, což je IMHO jeho jediná podobnost s rsnapshotem. Nepoužívá hardlinky. Vzhledem k jeho způsobu práce je naprosto zřejmé, proč trvaly zálohy dlouho.
přičemž na ZFS-on-linux i na btrfs to bylo hned.Porovnáváte neporovnatelné, uchování historie na úrovni filesystemu se nic vyrovnat nemůže. Je to efektivní a velmi výhodné, ale má to i nevýhody. Např. když ty snapshoty nepřenášíte na jiný server, pak máte pouze historii, ne zálohu - co třeba požár? Jak odlišíte, co chcete a co nechcete zálohovat? Jak a kam tímto způsobem zálohujete padesát různých serverů? Každé zálohovací schéma má výhody i nevýhody. Já používám rsnapshot hlavně proto, že výhody pro danou aplikaci převažují. Jsem s ním velmi spokojen. Vždycky to chce ale napřed trochu uvažovat - což platí obecně.
Např. když ty snapshoty nepřenášíte na jiný server, pak máte pouze historii, ne zálohu - co třeba požár?Dělám to tak, že to vždycky rsyncnu na zálohovací server a pak udělám snapshot.
Jak odlišíte, co chcete a co nechcete zálohovat?rsync --exclude
Jak a kam tímto způsobem zálohujete padesát různých serverů?Mám jich 14 a mám na to R5 ze 4 2TB disků.
číst kompresovaný tarO kompresi nikde nebylo ani slovo. Ta by to samozřejmě dost komplikovala.
A jaký je důvod použít tar a ne strom adresářů ve file systémuTakový, že jeho FS je NTFS nebo nějaká podobná hrůza.
No ale tar mu stejně nepomůžeHuh? Zataruje ty věci co chce zazálohovat a práva jsou v tom taru, takže je jedno, na jakém FS to bude.
--listed-incremental
vytvářet samostatné inkrementální backupy.
Pokud to tlačí obráceně, tedy zálohu linuxového systému do NTFS, tak přímá kopie nefunguje a může buď tar nebo vytvořit velký soubor v něm udělat linuxový FS, který následně moutne loopem.Tak jsem to pochopil a to jsem mu už doporučoval výše.
Ale pracovat uvnitř taru jako by to byl normální FS, tedy věci přidávat a případně mazat mi přijde nesmyslné.Také tak.
Tiskni Sdílej: