Fórum Root.cz

Dobrý den.
Potřeboval bych něco s čím by šlo zálohovat disk/data v PC, mám ale tři podmínky:
- Musí to umět komprimovat
- Archiv musí jít rozdělit na více souborů
- Archiv jde připojit jako disk (read only)

Zkoušel jsem DAr, FSarchiver, partimage, SquashFS, clonezilla, ale nic z toho nesplňuje vše.
Kompresi umí vše, rozdělit soubor umí vše kromě SquashFS, ale jediné SquashFS jde připojit jako disk.
Neexistuje něco co umí spojit všechny tyto věci dohromady? Rozdělit SquashFS, připojit DAr ...

neporadim idealni reseni, jen par info:
- clonezilla umi pripojit image ale jen kdyz neni komprimovan...
- squashfs bys musel rozdelit tak ze budes zvlast archivovat urcite skupiny adresaru, pak jde pripojit vice squashfs pres unionfs (ci aufs)

Jeden oddíl jsem zkusil po složkách pomocí SquashFS a druhý oddíl přes DAr. Přes SquashFS je to víc ruční práce, ale jde to a můžu data procházej jako by byla na disku. K DAru jsem našel gui ve kterém šlo archiv procházet, ale načítání není rychlé a nejde s tím pracovat jak s normálním fs.  Nějaká alternativa k SquashFS, která by uměla archiv rozdělit neexistuje?

http://www.winarchiver.com/virtual-drive.htm ?
+ rarom si uz spakujes co potrebujes vratane splitu ...

Citace od: tomík kdy 16. 05. 2018, 18:22:53
[...]Přes SquashFS je to víc ruční práce[...]Nějaká alternativa k SquashFS, která by uměla archiv rozdělit neexistuje?

muzes si napsat par radkovej script co vytvori pro kazdej dir vlastni squashfs...
a nasledne pro cteni pripoji vsechny a zapoji do overlayfs (puvodne sem se spletl a psal misto toho o nejstarsim uniofs):
mount -t overlay overlay -o lowerdir=/mount1:/mount2:/mount3 /komplet

Komprese v dnešní době nemá moc velký význam, neboť velké soubory obvykle komprimovat nejdou (zejména multimédia). Malé soubory zase zaberou tak málo místa, že komprese přináší jen zanedbatelnou úsporu.

Z těchto pohnutek používám pro verzování a zálohování Git, protože většinu zmíněných problémů vyřeší za mne automaticky, včetně komprese komprimovatelných dat.

zkus se podivat na Duplicati

Komprimovat, rozdelit archiv na vic dilu, to umi treba 7zip, umi kontrololu dat, sifrovani, dobra komprese.
Pak program, co umi udelat ISO soubor ze slozky. Na Widle ImgBurn a na Linuxu taky neco je i prez terminal, ale baha, kdyz je slozita struktura slozek, nazvy souboru, muzou se podelat. A ten .iso soubor muzes zkomprimovat 7zip, vc. rozdeleni na vic casti.
Read only - pro ten .iso soubor dat prava 500 (muze pouze uzivatel, co to vytvoril, cist a soustet, psat (tedy menit soubor) ne, ale tou komprimaci 7zip ty prava se zmeni asi i. A kdyz chces .iso soubor pripojit, musis to rozbalit. Muzes udelat .iso soubor, pak to prohnat TARem, nakonec komprimace 7zip s rozdelenim archivu (a pro pripojeni ISO souboru musis 7zip i tar rozbalit).

Ale jinak zalohuji prez rsync, pouze na lokalu takto:
rsync -ahvc --delete --progress Zdrojova_Slozka s cestou Cilova_Slozka_S_Cestou

-Podle kontrolnich souctu porovna soubory, smaze v cilove slozce soubory, co ve zdrojove slozce nejsou, pokud je ve zdrojove slozce soubor s jinym checksum nez ve zdrojove, soubor se aktualizuje podle zdroje. Pravdou je, ze rsync blbne pri pouziti nohup.

s pristupem iso+7zip lze pomyslet i na to ze se zalalohuje komprimovane clonezilou a pro pristup cteni se image rozbali na "virtualni file disk" ;-)
ad prava, nevim jak 7zip, ale bezne se v GNU/Linuxu pouziva baleni do taru s kompresi, bud nejhorsi tar.gz, nebo bz2, pripadne nejpomalejsi komprimace, ale nejlepsi komprese, tar.xz, ve vsech pripadech se diky taru zachovavaji veskera prava a symlinky...
nicmene stale to neni reseni ktere tazatel chce, tedy mit komprimovane, rozdelene a moznost k tomu pristupovat BEZ rozbalovani :-)

Tak nejlepsi je zpaq s jeho neomezenou ram spotrebou... udelas tar a nechas to komprimovat pres zpaq, po dovolene se vratis a mas nejmensi mozny archiv ve srovnani s konkurenci.

Citace od: nobody(ten pravej) kdy 16. 06. 2018, 00:10:09
....nicmene stale to neni reseni ktere tazatel chce, tedy mit komprimovane, rozdelene a moznost k tomu pristupovat BEZ rozbalovani :-)

Tak to spojeni kousku by nejspis slo udelat pres nbd-server. Akorat by se muselo vyresit, jak to porcovat tak, aby clovek pod tim mohl pri zaloze menit media. Umi tohle tar?

jsou lepsi compressory nez zpaq (ten momentalne vede jen u druhu souboru Camera raw)


http://www.squeezechart.com/



http://www.squeezechart.com/SqueezeChart2018web.xlsx


http://www.squeezechart.com/SqueezeChart2018web.ods

V tom squeezechartu je pouzita metoda 57, kdyby pouzil 512 dosahne maxima. Jestli je tam nekde ten jeho dataset ktery pouzil stahnu a zkomprimuji. Samozrejme zalezi vzdy na datech, ale na testovacich datech v radu TB mi zpaq k memu prekvapeni vysel jako nejlepsi co se tyce kompresniho pomeru(do te doby jsem naivne spolehal na 7zip), ale rozhodne nejpomalejsi a na ram nenazrany.

on ten zpaq s metodou 5 komprimuje a dekomprimuje rychlosti 3.3 GB/24 hodin, to je fakt v praxi tezko pouzitelne


jestli tam ma ten dataset nevim zkusil bych ten web prozkoumat pripadne mu napsat, ta tabulka je neustale aktualizovana ...


jeste je tam treba zajimave


density 0.12.5 ktery sice skoro nekomprimuje ale je neuveritelne rychlej, skoda ze je to jen knihovna a ne binarka k dennimu pouzivani

Tech 3,3GB/24hodin asi ne, pouzivam zpaq misto 7zip a 20GB skomprimuje alespon na mych xeonech za par hodin (mohu dohledat casy z testu co jsem delal). Taky zavisi jestli komprimujes na 1jadre nebo mas tech jader 20. Na denni kompresi 2TB to neni, na archivaci neceho co pristich 5let nebudu chtit je to jedna z moznosti.

Citace od: kkt1 kdy 16. 06. 2018, 12:36:17
Tech 3,3GB/24hodin asi ne, pouzivam zpaq misto 7zip a 20GB skomprimuje alespon na mych xeonech za par hodin (mohu dohledat casy z testu co jsem delal). Taky zavisi jestli komprimujes na 1jadre nebo mas tech jader 20. Na denni kompresi 2TB to neni, na archivaci neceho co pristich 5let nebudu chtit je to jedna z moznosti.

btw jak by byl ten command line prikaz zpaq 512 pro kompresi celeho adresare vcetne vsech podadresaru a souboru v nich ?

ta rychlost je videt na https://quixdb.github.io/squash-benchmark/#results (https://quixdb.github.io/squash-benchmark/#results)   


u Ubuntu 14.04.43.10.80gcc-4.9.2[size=inherit]peltastIntel® Xeon® Processor E3-1225 v3 (http://ark.intel.com/products/75461/)x86_643.2 GHz20 GiBLenovo ThinkServer TS140 (http://shop.lenovo.com/us/en/servers/thinkserver/ts-series/ts140/)Fedora 224.1.6gcc-5.1.1ma rychlost cca 390 KiB/s tj. cca 1,39 GB za hodinu, to uz je lepsi ale furt nic moc pro kazdodenni pouziti

jeste lepsi kompresi ma bsc https://encode.ru/threads/586-bsc-new-block-sorting-compressor (https://encode.ru/threads/586-bsc-new-block-sorting-compressor)

a hlavne ma o nekolik radu lepsi rychlost komprese/dekomprese

Co vim tak zpaq umi komprimovat jenom jeden soubor, tudiz tar. Ja pouzivam zpaq a Archive.zpaq Archive.tar -method 512 -key heslo -threads 1, u mensich archivu threads dle dostupnych jader. Problem s vice threads je ze kazdy sezere xxGB ram tudiz sezrat 1TB ram neni v pripade vetsiho mnozstvi dat az takovy problem. Podivam se na ty veci az budu doma.

To uz se tu resilo.

zpaq umi jen jeden soubor ? To pak jen prez TAR.

7zip je o poznani rychejsi (100-200 GB za den nejlepsi komprese, hlavne dekomprese velmi rychla, 10-15 MB komprimovanych dat/s takze nekomprimovanych dat i 1 GB/s) prauje dobre tam, kde je velke mnozsti podobnosti. Nejvetsi slovnik muzes dat 1536 MB, coz za kazde zapocate 2 jadra sezere 16.5 GB ram (+ filelist). 64 MB slovnik sezere cca 750 MB RAM +filelist za kazde zapocate 2 vlakna.

paq8px jede cca 200 MB za den, stejna rychlost rozbalovani, nemoznost test archivu, umi 1 vlakno, max. slovnik -8 asi 1700 MB RAM. Nezvlada soubory nad 2 GB. Melo to byt s kompresi nejlepsi, vysledek ale nejlepsi nebyl.

xz jen jeden soubor umi, nejlepsi metoda -9e, pomalejsi a o trochu horsi nez 7zip, na jedno vlakno sezere asi 800 MB RAM tusim, pocet vlaken nastavis -T napr. T -8.

https://forum.root.cz/index.php?topic=15102.0

Ten pristup bez rozbalovani je problem, takze tezko poradit. To chces pristupovat bez rozbaleni kvuli malo mista na disku nebo CPU casu ? Pokud rozbalis komprimovany 7zip archiv s ISO souborem a dobrou kompresi, je rozbalovani desitky-stovky MB/s, s cca 0.01-4 GB ram podle slovniku. Pokud potrebujes pracova vzdy s jednim souborem, ne celym diskem, rozbal jen jeden soubor z archivu (7zip prochazi cely pevny archiv, nez vybrane soubory rozbali, ale az stovky MB/s). Samotny archiv muzes mit prava read-only, tak soubory uvnitr nezmenis.

Citace od: Honza1Ubuntu kdy 17. 06. 2018, 14:57:44
Ten pristup bez rozbalovani je problem, takze tezko poradit[...]

tak zkus neradit off-topic reseni ;-) ja mu radu ktera by splnovalo pozadavky dal (https://forum.root.cz/index.php?topic=18498.msg265347#msg265347) :-)

7zip je dobrej, ale já bych to rád procházel jako připojený disk, ale jde to taky, jen to rozbalení jednoho souboru není hned. Jinak díky všem. Dozvěděl jsem o několika nových kompresních programech/algoritmech o kterých jsem nevěděl. Data která se nedají zkomprimovat někdy hážu do ISO obrazu a připojuju.  Třeba si napíšu časem i ten script pro kompresi a rozdělení se SquashFS. Když SquashFS používá třeba i to lzma které používá i 7zip proč nejde SquashFS archiv rozdělit na více souborů? Ta podpora pro rozdělení je v algoritmu nebo v aplikaci?