Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Honza1Ubuntu

Stran: [1] 2 3 ... 13
1
arrange

... A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.
Urcite nekontroluje bez -c kontrolni soucty zdroj-cil u souboru, ktere se neprenasi - jmeno a timestamp zdroj-cil souhlasi, tak se ty soubory neresi. Ale jestli kontroluje spravnost zapisu na disk prenasenych souboru ? Urcite kontroluje spravnost prenosu po siti. Kontrolni soucty pak by mel kontrolovat nejmene sam proces zapisu na HDD.

Az takhle jo, to se ti fakt menil obsah souboru, to velke zmeny, nebo jen zmeny par bajtu ?

Ja pouzivam klasicky HDD na notasu, popr. extreni HDD. Zatim se mi to nikdy nestalo - zmena dat bez toho, aby to hodilo chybu cteni-zapisu. Kdyz se zacal podelavat disk a byla chyba cteni-zapisu, tak se to cele hodilo do read-only, nebo proste soubor nejde precist. Zatim jsem nezazil ODHALENOU zmenu dat na HDD. U archivu napriklad i mala zmena odrovna cely archiv, u textu, obrazku, videa malou zmenu nepoznas. Zmenu bit jen jednoho bajtu ve skriptu nemusime rozebirat, muze udelat paseku:

Kód: [Vybrat]
cd ${cesta}
rm -fr *

nebo

Kód: [Vybrat]
cd ${cista}
rm -fr *

HDD, SDD, USB klice by meli mit pri cteni-zapisu kontrolni soucty, ktere odhali vadny sektor a chybny zapis-cteni, tedy pozkozena data (data corrupt). Nechytnou ale vsechno, pri velkem mnozstvi dat se obcas bit-flip (zmena bajtu-bitu) obevi. Snad jednou za X stovek GB jsem nasel. SD karty snad ani tyto kontrolni soucty nemaji (nebo jiny mechanizmus nemaji), nebo jsou ty kontrolni soucty maji SD karty slabsi bych spis rekl. To uz je ale mimo rsync.

Verze s -c ochrani-odhali spatne soubory v cili (podelany disk), bez -c neprenese podelane soubory ve zdroji a v cili zustanou spravne. Ale Pri vadnem sektoru by se mela ozvat chybn hlaska ze nejde cist-zapisovat, pri chybnem zapisu se disk hodni do read-only a stop. NE zapsat jina data.

2
Arrange

O to prave jde, spravnost prenosu po siti se resi vzdy pomoci kontrolnich souctu. At uz s -c nebo bez. Ale to tu prave resime, jestli je kontrolovano, zdali jsou spravne i soubory zapsany v cili (spravny zapis na disk, vadne sektory).

Na druhou stranu volba s -c muze prenest poskozeny soubor ze zdroje a prepsat v cili OK soubor, pokud je vadny sektor ve zdroji.

O chybnem zapisu na disk (zmena dat) se tu uz tusim diskutovalo, jestli se to muze stat. S tim ze by to nehlasilo chybu disku a precetl by se ve zdroji nebo zapsal v cili oubor chybne. Otazka je, jak casto, snad se pocita jedna zmena bitu (bit-flip) za X TB nebo dokonce X PB tusim. S urcitou, byt malou pravdepodobnosti se to muze stat jak ve zdroji tak v cili, tak ani spustit po druhe rsync s -c neni stoprocentni.

Pokud v cili nejde neco prepsat-zmenit (zmenit casy, prava, prepsat soubory), protoze napr. uzivatel nema opravneni, tak to rsync hlasi - ze nejde synchronizovat  kompletne a vypise chybu. A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.


[...]Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)
napr. tak:
Kód: [Vybrat]
cp -a soubor soubor.bak
echo "neco" >>soubor
touch -r soubor.bak soubor

Presne tak

Jestli je soubor nepatrne, nebo kompletne odlisny, to uz se neresi, checksumy by se mely lisit prakticky vzdy, i pri nepatrne zmene (neni to uplne pravda, ale pravdepodobnost odlisnych souboru se stejnym checksumem je naprosto minimalni).

Pri beznem provozu, praci a zalohovani me nenapadlo, jak by se to mohlo stat.  Ale pokud nekdo bude ve zdroji nebo cili delat nepravosti a umyslne skodit, tak to mozne je. Nedopatrenim se to taky muze stat pri zpracovani dat, ale ne uplne snadno.


3
Software / Re:Rozpadající se weby při blokování JS
« kdy: 02. 09. 2020, 22:46:37 »
Tech 20 JS skriptu na nekterych strankach a reklamy - to je  dobre poznat, kdyz na takove strance jsem - zacne hucet vetrak. A i na RAM to poznas. Kdyz mas takovych stranek otevrenych vic, docela to zpomaluje komp. Bez JS zatizeni CPU minimalni.

Takze ne jen bezpecnost, ale vytizeni PC je duvod k blokaci. Nektere stranky ale bez JS nejdou.

4
Bez -c se může chybně vyhodnotit nutnost soubor přenášet. S -c se nutnost vyhodnotí na základě checksumu, takže je záruka, že se přenese vše, co se změnilo. Přenos a zápis do souboru se pak provede i s kontrolou konzistence. Takže při -c by nemělo být potřeba zadávat příkaz 2x. Tak tomu rozumím já.

Taky tomu rozumim tak, ze -c akorat vyhodnocuje pomoci kontrolnich souctu, zdali je nutne soubor prenaset. Bez -c se nutnost prenosu hodnoti podle toho, jestli se shoduje timestamp, jmeno a umisteni souboru. Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)

Ta kontrola konzistence zapisu v cili a prenosu po siti by snad mela podle vseho probehnout vzdy, nezavisle na -c, tak tomu rozumim.

2x rsync spoustet nejdriv bez -c a pak s -c by snad melo odhalit jen soubory zdanlive stejne (jmeno, cas, umisteni) ale s jinym checksumem. Stejne tak, pustim li rsync jen jednou s -c. Spousteni 2x (podruhe s -c) by odhalilo i chybny zapis s cili, ktery by nemel kvuli kontrole konzistence VZDY nastat.

Pokud je datovy soubor velky (stovky GB) a soubory, ktere se maji prenest jednotky GB, tak samotny prenos muze trvat minuty, kontrola checksumu na obou stranach i par hodin.

5
Diky, to jsem potreboval vedet. Jestli je ma smysl davat -c nebo poustet rsync 2x i v pripade, ze o (ne)prenosu souboru staci ridit se casem posledni zmeny souboru. -c tedy nema vliv na odolnost proti pozkozeni dat po siti a pri zapisu  v cili. Jenda mi potvrdil presne to co jsem potreboval vedet.

Takže dotaz zní, zda je rsync protokol odolný proti poškození dat během síťového přenosu, případně během čtení či zápisu na disk? Bude asi záležet na přenosovém médiu - já většinou přenáším přes ssh a navíc s kompresí a tam bych automaticky čekal kontrolní součty a tedy jistotu bezchybného přenosu. Že by ovšem rsync opětovným čtením kontroloval, že se na disk zapsalo to, co se zapsat mělo, o tom bych si dovolil pochybovat.

Prave na to jsem se ptal, -c rozhoduje, zdali bude soubor prenesen nebo ne, podle kontrolnich souctu, pokud to tam nedam, tak podle datumu a casu. Zajimalo me, jestli je i v pripade volby BEZ -c rsync odolny proti poskozeni dat pri sitovem prenosu a take zapisu na disk. Protokol take pouzivam ssh, i kvuli bezpecnosti. Parametr pouzivam takto, aby byl vzdy cil stejny jako zdroj:

Kód: [Vybrat]
rsync -ahvc -e ssh --delete --progress ZDROJ CIL

A otazkou je smysl pouzit -c v parametrech, nebo pustit rsync vicekrat, jestli to ma smysl. Pri velkem obemu dat kontrolni soucty uz vyznameji zatezuji system (cteni na disku) ve zdroji a cili, a nejaky cas to trva, az hodiny pri velkem mnozstvi dat. A podle vseho samotne -c a nebo sposteni rsync 2x nezvysi odolnost proti poskozeni pri prenosu po siti nebo zapisu v cili. I kdyz u opravdu dulezitych dat je to mozna lepsi 2x spustit s -c.

6
Prenos souboru mezi soubory delam pomoci rsync. Kdyz pouziju volbu -ahvc tak c znamena, ze se obsahy souboru ve zdroji a v cili porovnavaji pomoci kontrolnich souctu, ne podle datumu posledni zmeny. Kdyz dam jen -ahv znamena, ze se soubory ve zdroji-cili porovnavaji podle datumu posledni zmeny, co se ma aktualizovat, a co ne.

Otazkou ale je, zdali pri samotnem presnosu po siti ma vliv volba -ahv vs. -ahvc na spranost prenosu dat. (jestli c, jez pocita ve zdroji a cili kontrolni soucty, kontroluje pomoci kontrolnich souctu i spravnost prenosu po siti pri zapisu do cilove slozky).

Zdroj a cil je na jinem serveru, takze prenos je po siti.

7
Velmi dobre to zvladal (pripad z obrazky a dilcimi soubory linkovanymi na jiny server) Teleport Pro. Jenze bohuzel teleport je proprietali komercni software pro Widle, nejak emulovat pujde, coz zase dost zere vykon. Navic teleport pro zvladal max 65536 odkazu v databazi, jen Teleport VLX zvladal opravdu velke weby - za 40 000 000 linku, takze driv dojde RAM. Nejvic mi ale vadi, ze teleport je komercni, proprietalni a pro Widle. Navc teleport dost spatnym zpusobem resil ukladani na disk.

Na stahovani webu pouzivam wget - je skriptovatelny a nezere zbytecne CPU, na disk uklada taky dobre. U slozitejsich stranek zmrsi nazvy, ale u jednoduchych stranek bez podivnych adres funguje konvert odkazu OK. Problem je, ze obrazky jsou linkovane mimo web blog.cz Tusim ale ze wget ma volbu, kde se stranka stahne se vsemi soucastmi,k i kdyz jsou mimo.

Pozor na cyklicke odkazy, odkazy, jez jdou porad hloubs a hloubs, kalendare, kde se do nekonecna stahne jedna webova stranka ke kazdemu dni a pod.

Uz se to tu kdysi davno resilo - program na stazeni celeho webu:

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

8
SpaceExit

PNG, GIF, JPG, BMP a mnoho dalsich, to jsou vsechno rastrove formaty, kde je ke kazdemu bodu prirazena barva, tedy hodnota. Barevna hloubka je rozpeti - pocet ruznych hodnot,ktere dany bod muze mit. Barevna hloubka obrazku X bitu znamena, ze kazdy bod muze nabyvat 2naX ruznych hodnot. X muze byt 1,4,8,16,24,32 i 48 ci jina hodnota.

BMP - to je surova tabulka hodnot nebo databaze, bez jake koliv komprese, neco jako textovy soubor. PNG, GIF, JPG pouzivaji ruzne kompresni algoritmy (napodobne jako zip, rar, 7z,bz2 paq pro obecnou kompresi dat). GIF, PNG, tam je komprese bezstratova, data pri kompresi nejsou nijak modifikovana. JPG se poiziva hlavne na fotky, komprese je to ztratova, dojde k modifikaci dat trochu, za co dostaneme lepsi kompresi. U fotek mirna ztrata dat nevadi narozdil od schemat. GIF a PNG umoznuji jeste pridat krome barev kanal pruhledosti, jak moc je kazdy pixel pruhledny a je videt pozadi za nim. Ted nevim, jestli si to pamatuji dobre, tak GIF ma pro kazdy pixel hodnotu pruhlednosti 0-1, tedy zcela pruhledy-nepruhledny. PNG by melo mit pro kazdy bod 8-bitovou pruhlednost, tedy neco jako 256 odstinu pruhledosti. Kazdopadne ted nevim, jestli si to pamatuji dobre. Kanal pruhlednosti (jedna se o Alfa kanal ? Ted nevim) muze-nemusi obrazek obsahovat.

Puvodni dotaz znel, jak velikost obrazku snizit na minimum, protoze budu pracovat s mnoho obrazky. Tedy kanal pruhlednoti by nemel obsahovat, barevna hloubka 8 bit (256 barev). Hlavni problem je snizovani barevne lhloubky s vyssi (16, 24 bit ci vic) na 8 bit, aby moc to nenarusilo kvalitu, ale velikost byla co nejmensi. Dirhetaceruzne barvy promicha okolo, takze neni videt snizeni barevne hloubky tolik. Zase je tam vic rozdilu mezi okolnimi pixely, soubor je pak vetsi. Proto chci dirhetaci vypnout. Pri snizeni barevne hloubky na paletu s 256 barvami bez dirhetace je velikost souboru nejmensi, kvalita u daneho typu obrazku prakticky stejna. Dalsi veci je zpusob ulozeni PNG dle parametru. Je to bezstratova komprese. PNGCrunch podle vseho zkousi ruzne typy parametru a zvoli parametry, kde je nejmensi velikost souboru. Tedy pokud se nepletu. Mozna ze proces bezi jinak.

Pouzivam prakticky stejne-podobne typy dat, jako jsi dal odkaz. Co se tyce tech radarovych snimku od CHMI, tam jsou data jen par dni dozadu, pak uz odkaz nebude fungovat. Dany obrazek ma podle vseho pruhlednost v ruznych bodech, hlavne tam, kde neprsi a radarove odrazy nejsou, je pruhlednost maximalni. Pod timto obrazkem jsou dalsi, casto nemenne PNG, mapove podkady a pod. A dalsi vrstva je pruhledny obrazek s krizem, jez zaskrtne zvolenou pozici. Jinak PNG je samozrejme komprimovany datovy soubor v tomhle pripade. Komprese je lepsi vetsinou nez CSV + 7zip.

Jeden z typu map, u kterych je ta komprese dulezita, jak vyjit s co nejlepsi variantou, je prave radar Evropy:
http://pogodynka.pl/http/assets/products/radar_europa/T_PABH21_C_EUOC_20200306170000.png

Data jsou tam par hodin dozadu jen tusim, odkaz moc dlouho fungovat nebude, pak se musi zmenit datum.

Vyhodou je v jednom PNG cela mapa a radarove odrazy.

A pokud je dat vic - komprese je problem. Puvodni obrazek s hloubkou 24 bit PNG ma v prumeru cca 630 kB. Klasika prez covert (tedy imagemagick), nejdriv convert na GIF, pak na PNG quality 95, hodi mi to v prumeru . Kdyz dam, tak jak navrhoval Petr bez mezistupne GIF a s vypnutim dirhetace, stale -quality 95, tak dostanu prumerne 770 kB, nechapu. Kdyz dam nejdriv na GIF s vypnutim dirhetace  +dither -colors 256 a pak na PNG quality 95, tak dostanu velikost v prumeru 280 kB. S Xnview starym, ktery umel vypnout dirhetaci pri prevodu na GIF a pak na PNG s kompresi 9 jsem dostal v prumeru 180-190 kB a s novym XnView s konverzi na GIF, pak na PNG komprese 9 jsem dostal v prumeru 330 kB, nenasel jsem, jak vypnout dirhetaci.

U convert-image magick -quality u PNG neznamena kvalita, ale parametry ulozeni. Kvalitu to znamena u JPG.

Dalsi typ obrazku, u ktereho jsem to ladil, je tady:
https://meteomodel.pl/AKT/IMG/temp99.png

Puvodni velikost prez 800 kB (muj vzor 811 kB). Prevod na GIF a pak na PNG (pri prevodu na PNG vzdy parametr -quality 95) 251 kB a pak jak mi poradil Petr s vypnutim dirhetace  +dither -colors 256 vyjde vysledne PNG 227 kB. Kdyz nedam parametr -quality 95, je vysledny soubor 231 kB.

9
MarekKnapek

IrfanView  a podobny XnView umi dobre davkovou konverzi obrazku, vc. podslozek. Skriptovaci sice neni (nebo jsem neobevil, jak na to v bashi). Ten byl diskutovan hned na zacatku. U XnView sla vypnout dirhetace jen u starsi verze, kterou jsem mel (a jeste mam ten program) pod Widlema, takze nic moc. Novy XnView neumi dirhetaci vypnout resp. nastavit barevny profil pri snizeni barevne hloubky, navic (a nenasel jsem jak to vypnout, stary XnView to nedelal) se nacitaji vsechny soubory ke konverzi jako miniatury, coz zere dost systemove prostredky a pri velkem poctu souboru ti dojde RAM a zamrzne system.IfravView na tom podle vseho bude podobne.

PNGCrush a brotli / zopfli vypada ze jde prez find v bashi, coz je idealni. Komprese PNG vypada jeste lepsi. Zabere to vic procesoroveho casu, to je ale vhledem k dotazu a pozadavkum samozrejmosti. I samotny convert resp. ImageMagck umi vypnout dirhetaci, jak poradil hned uzivatel Petr Krčmář.

Vysledne obrazky jsou pak pro BFU, pro me, a mohou se v budoucnu, az budu lepe umet skrptovat treba, pouzit pro program ke zpracovani. Pro web browser taky mohou byt pouzita. PNG je zatim nejlepsi format pro bezstratovou kompresi, co jsem kdy objevil. Pro fotky se moc treba nehodi, hodi se pro mapy, grafy, schemata a nebo i velmi kvalitni fotky. Dulezite jsou ostre hrany. PNG byl vyvinut jiz pred 25 lety a proto je dost dobre mozne, ze existuje lepsi bezstratova komprese, nez PNG, jen neni moc rozsirena. S mymi zacatky na kompu vladl hlavne GIF, horsi parametry i kompese nez PNG, navic nesvobodny. Ted uz je PNG dost rozsirene. Ale muze byt uz neco o dost lepsiho. Stejne tak jako se vyviji v prubehu casu komprese dat zip - rar - bz2 - 7zip - paq.

10
P_V

JPG urcite ne, to uz mam vyzkouseny. To se hodi spis na fotky a pod. Na grafy-schemata moc ne, je to pri vetsi kompresi ztratova komprese a tak tam jsou rozdily u tohoto typu obrazku pomerne videt. A kdyz dam ztraty pri kompresi minimalni, zase je to podstatne vetsi nez PNG.

tecka

Vektorovy format je vyhodny, kdyz uz se udela pri samotnem vytvareni mapy-grafu. To pak soubor byva jeste mensi. Ale prevadet PNG-GIF nebo i JPG na vektorovy format, to nevim, jestli pujde dobre.

Jiří Helebrant, Petr Krčmář
PngCunch spousti pngquant a pak zopfli ? Png crunch vypada velmi dobre , hlavne co se tyce vysledne velikosti. pngquant vypada ze velmi dobre funguje na zmenseni png obrazku. Snizeni barevne hloubky na 8 bit (256 barev) ,bez dirhetace, podle testu dava asi nejlepsi vysledek. I samotny klasicky imagemagick s vypnutim dirhetace:

convert vstup.png  +dither -colors 256 vystup.png

Dava lepsi vysledky. Puvodni 24 bit PNG melo 811 kB, klasicky prechod prez GIF a pak PNG quality 95 pak 251 kB a rovnou do PNG s vypnutim dirhetace a  quality 95 dosahlo 227 kB, bez parametru  quality 95 pak 231 kB.

pngquant a pngcrunch pak vypada s jeste lepsimi vysledky.

luvar

Ano, GIF je mezistupen kvuli indexove palete - snizeni na 8 bit. Ale podle vseho mezistupen GIF ani nebude nutny. Photoshop-Gimp jsou spis klikaci programy, ty na davkovou knoverzi nepujdo, tam jde spis o kresleni. Velmi dobre vypada ten pngcrunch, ktery tu byl nekolikrat zminen (s pouzitim pngquant a zopfli). Dulezite je, aby sla ta davkova konverze, i ve vnorenych slozkach, nejlepe v bashi find.

Diky moc vsem, zkusim co a jak bude vychazet.

11
Software / Nejlepší možná komprese PNG s 8bitovou hloubkou
« kdy: 02. 03. 2020, 20:16:54 »
Zdravim

Jiz delsi dobu se snazim prijit na to, jak co nejlepe zkonvertovat na maximalni moznou kompresi velke mnozstvi PNG-GIF obrazku. Jedna se o grafy, a mapy s jasnym rozhrannim barev (ne pozvolny prechod vice barev). Pocet souboru je desetitisice az statisice.

Ta nejvetsi otazka je, jak nejlepe prevest PNG obrazky s 24 bit na 8 bit. Driv pred lety se jednoznacne osvedsila stara verze XnView, vysledne soubory meli nejmensi velikost, kvalitu prakticky stejnou. Vsechny PNG obrazky jsem zkonvertoval na GIF. U obrazku s hloubkou 24 bit se me to zeptalo, jaky typ barevne skaly chci a jestli se ma pouzit dirhetace. Pri dirhetaci se barvy ruzne misi s prechodem na mensi pocet barev, vysledny soubor je pak vetsi a navic vypada hur. Takze jsem vzdy zvolil barevnou skalu 256 barev bez dirhetace. Moznosti byly i jine (256 odstinu sedi, 64 barev ci odstinu sedi, cerna a bila).

Jenze zminenou volbu mel nekolik let stary XnView, navic pod Windows. Novejsi verze XnView jak Win tak Linux pri konverzi z PNG (ci jineho formatu) na GIF vubec moznost zvolit typ palety a dirhetace nemaji, vzdy dirhetaci pouziji. Navic se list souboru nacita jako miniatury, coz puvodni nacitani zdrzuje a nekdy i dojde pamet.

Otazkou tedy je co a jak pouzit pro davkovou konverzi obrazku na format PNG, tak aby byla velikost co nejmensi (tedy vc. snizeni barevne houbky na 8 bit) ?

Aktualni XnView - tam nejde vypnout dirhetace a navic se tam nacitaji miniatury (nenasel jsem, jak to vypnout), az to zahlti pamet a system.

Druhou moznosti je v terminale convert. Na samotne ulozeni do png se mi osvedsilo convert -quality 95 OldFile NewFile. Tady -quality neznamena kvalita (komprese bezstratova), ale uroven komprese a typ filtru. Ale zase je tu spis ta puvodni otazka, pred ulozenim do PNG jak snizit barevnou hloubku na 8 bit. Pouzivam konverzi do GIF. Vysledne soubory jsou ale stale vetsi, nez jak to delal stary XnView. Nejspis convert take pouzivat nejaky typ dirhetace, neprisel jsem na to, jak vypnout dirhetaci pri prevodu na 8 bit.

Neco jineho ? S necim jinym zkusenosti nemam, ale mozna uz nekdo neco pouzil driv.

12
Server / Re:Přenos velkého množství dat po síti
« kdy: 30. 01. 2020, 17:54:04 »
Dotaz k rsync parametru

Kdyz pouzivam prenos dat prez rsync, ktery sice neni tak objemny, jen desiky GB, ale po pomale nestabilni siti, mam pouzivat volbu -ahv nebo -ahvc ?

-ahvc znamena ze se prepocitaji ve zdroji a cili kontrolni soucty a nejsou soubory aktualizovany v cili podle datumu modifikace, nybrz podle kontrolnich souctu. To ale pri kazdem spusteni rsync zatezuje disk ve zdroji-cili a chvilku trva, nez se soucty spocitaji (cca 20 minut pro neco prez 100 GB).

Jestli -ahvc zvysi spolehlivost prenosu samotneho (eliminace chyb pri prenosu) oproti -ahv, to si nejsem jisty a na to se ptam. Pravdepodobne volba -ahv  vs. -ahvc je pouze rozdil zpusobu rozpoznavani, u kterych souboru je potreba aktualizace. Muzu dat -ahvc jen jednou za cas, jinak -ahv a omezit zatizeni disku i potrebny cas.

13
Server / Re:Přenos velkého množství dat po síti
« kdy: 24. 01. 2020, 20:41:27 »
Ondrej Nemecek

Prave ze jsem o teto moznosti driv nevedel, tak nevim. Nekdy mam rsync na notasu v miste s pomalym pripojenim radove Mbit/s, i jen 1 Mbit/s muze byt. Obcas spadne sit a nasve to. To se pak moznost nemuset po padu site zacinat u souboru par GB velkych od znova hodi velmi. I pri velikosti stovem MB.

Pri pripojeni serveru 100 Mbit je 1 GB soubor prenesen velmi rychle, rekneme 2 minuty. Resil bych to az u souboru o velikosti rekneme nad 30-50 GB  (prenasejicich se radove hodinu), pokud vubec. Pripojeni byva docela stabilni u serveru navic. U rychlosti 1 GBit je limitem slapsi CPU na dvojici stroju (u velkych souboru). Rychlost byva 20-50 MB/s, spojeni byva stabilni, resil bych to az u souboru velkych nad 100 GB (prenasejicich se radove hodinu), pokud vubec.

Taky k tazatelovu dotazu obecne rsync nejde prez nohup a pokud z duvodu blbe site onnekud ssh spojeni spadne, musis poustet od znova. Doporucuji rsync spoustet prez screen.

14
Odkladiště / Re:Jak bezpečně skladujete data doma?
« kdy: 24. 01. 2020, 18:01:43 »
Vykolej Rozkašil

Ano, je tomu tak. Co neni ve zdroji, v zaloze ano, to --delete smaze. Tak zaloha nebude expandovat na velikosti pri kazdem presunuti prejmenovani souboru-slozek ve zdroji.
To lze resit pomoci prepinace --backup --backup-dir="backup_$(date +%Y-%m-%d)". Smazane soubory se presunou pak do backup-dir slozky, kterou pak muzes cas od casu smazat.

Kdyz budu pravidelne zalohovat, tak budu cilovou slozku udrzovat stejnou jako zdroj, takze prenesu nove soubory, soubory co ve zdroji nejsou, se v cili smazou. To tak musi byt, jinak by zustavaly soubory a slozky v cili po kazdem prejmenovavi, presunuti, vymazani nepotrebnych dat ve zdroji. Stejne tak se pochopitelne aktualizuje cil pri jakekoliv zmene souboru-slozky ve zdroji, zmenene soubory ve zdroji se aktualizuji. Jinak by obem zaloh nekontrolovane rostl. Tento typ zalohy zdroj-cil me chrani proti padu systemu-ci hdd ve zdroji. Pokud je cil v jinem geografickem miste, co nejdal nejlepe, tak me to chrani pred vykradenim (zlodej by vzal zkancelare zdroj i cil), pozarem, povodni, podobne.

Pokud zroj odejde v dobe prenosu-zalohy, odpali to prave prenaseny soubor nejmene, a take vse nove od posledni zalohy, co se nestacilo zalohovat.  A navic pokud odejde cil, tak jsem zcela nechranen, nez si zaridim cil novy. V takovem pripade by snad pomohly dve zalozni mista (zdroj a dva ruzne cile nejlepe geograficky daleko, kazdy zazalohovat v jinou dobu).

Prvni dva odstavce me neochrani pred moji blbosti v pripade jednoho cile (spatne si neco smazu-zmenim), pred ramsomware, nejakym blbym behem skriptu, zaskodnictvim kolegu, preklopenim bitu a podobnych veci. V pripade dvou cilu musim vcas reagovat. Take pomuze, ze zaloha neni prez CRON, pouspim manualne, kdyz se nic nedeja a po vetsi praci vim, ze je potreba zalohovat. Ale nesmim na zalohovani zapominat. Pak se mi zaloha nespusti hned po tom, co chybou neco na disku podelam. Tam kde jsou treba zalohy casto, tam automatizace ale byt musi.

Pokud dojde softwarove (moje blblost, zaskodnik, ramsomware) ke zniceni dat ve zdroji, nepoznam to vcas, pak me ani dva ruzne zalozni cile nezachrani a pomuze jen delat si pravidelne zalohy nezavisle s ruznymi verzemi (k ruznym datum). To jde u maleho obemu dulezitych dat (diplomka, skript, clanek, kniha). Mimo jine, mam i ak nejaky, byt neprimy dukaz, kdyz me oponent krive obvini s opisovani a pod. Zaloha typu, ze si vse zazalohuju jednou za mesic, to jde u malych dat, nebot prave o obem dat vzroste velikost zaloh z kazdym behem. Kdyz zalohuju par MB kazdy den, za rok to da GB. A pak stare verze ruzne promazavat. Budu-li chtit zazalohovat 1 TB jednou za tyden, je to uz draha sranda (na pasky nejspis). Existuji ale reseni lepsi, nez vse s kazdou zalohou zapisovat, jak uz bylo zmineno. V tom se moc uz nevyznam. A u velkych objemu a castych zmen stale drahe. Velmi dobre vypada moznost, jak navrhl xhonzik.

Kdyz zalohuju s ruznymi verzemi (jednou za tyden treba) na jedno velke medium, i to se muze podelat. Pak verzovani nepomuze a pomuze jen stridat vic ruznych medii (vypalovat na opticka media). A pak bych ty media musel ruzne rozvazet, pro zabraneni zkazy v pripade pozaru. To uz je narocna zaloha.

Jak tedy jsou reseny zalohy firemni, kde je velky objem dat, musi se to zalohovat casto, ochrana proti zivelne katastrofe, a dalsi. A jeste navic to musi byt sifrovane a nesmi se nikde vyskytnout chyba. Takovy je treba SIS na Karlovce vc. ulozenych diplomovych a dalsich praci, nebo Studentske uloziste. Tam uz me nenapada, jak do bezpecne vyresit.

Jinak se najdou experti, co si nezalohuji ani tech par MB rozepsane knizky, nebo diplomky. A pak se divi cenam za zachranu dat. U maleho mnozstvi je to tak jednoduche.

15
Odkladiště / Re:Jak bezpečně skladujete data doma?
« kdy: 24. 01. 2020, 02:08:32 »
Vykolej Rozkašil

Ano, je tomu tak. Co neni ve zdroji, v zaloze ano, to --delete smaze. Tak zaloha nebude expandovat na velikosti pri kazdem presunuti prejmenovani souboru-slozek ve zdroji.

Pokud je rsync sousteno pravidelne cronem, tak pokud si neco omylem smazes ve zdroji a nezareagujes vces, tak ... No vis. Proto rsync poustim jen rucne, kdy chci, vim ze uz je potreba zalohovat (dost novych veci ve zdroji) a aktualne naopak nedoluji nic ze zalohy. Pri rsync na vzdaleny serven navic musim zadat heslo.

zalohu mam spis kvuli havarii HDD, kradezi, ci treba pozaru. Na smazani dat vlastni blbosti taky, i kdyz ne primarne.

U malych a dulezitych dat (skripty, clanky, diplomka) mam i zaloh vic do minulosti, obcas ty archivy otestuji. Samozrejmosti je vic geografickych mist. Dale teoreticky - Pro posileni zaloh muzes jeste pouzit vic komprimacnich programu (dva), kdyzby jeden udelal chybu a kontrola nenasla, samozrejme kazdy z tech dvou programu jiny kompresni algoritmus. A dalsi posileni je spocitat v cili a zdroji vic kontrolnich souctu. A jeste jedna moznost - udelat si verzi se samo-opravnym kodem a bez. Pru dulezita data se navic hodi keramicke opticke DVD s ochranou vrstvou - data vydrzi dlouho a nesmaze je elektromagneticka udalost.

Stran: [1] 2 3 ... 13