čtvrtek 18. července 2013

Obnovení bitové kopie Windows 7 z disku zašifrovaného Bitlocker To Go



Bitlocker není asi nutné představovat, tuto docela pěkně implementovanou technologii šifrování, zde máme již od Windows Vista a s každou novou verzí Windows se dostává níže do běžnějších edic. Navíc pokud máme procesor s funkcí AES-NI, můžeme si šifrování dovolit bez ztráty výkonu a výdrže na baterii.

U notebooků má šifrování asi největší význam, v případě odcizení zařízení hrozí i odcizení identity, viz XKCD :-)

Pokud disk šifrujeme, pak se logicky zmnohonásobuje nutnost pravidelně zálohovat. Pokud jdou data z poškozeného pevného disku z pravidla vydolovat, ta dostat data z poškozeného šifrovaného disku je nemožné.


Jenže, má smysl zálohovat data ze šifrovaného disku například na nešifrovaný externí USB HDD? V případě odcizení jsme na tom stejně - data jsou zálohována nezašifrovaně. A obnovit bitovou kopii na jiný hardware je díky Windows Backup práce na deset minut.

Naštěstí Windows 7 umí zálohovat na oddíly šifrované Bitlockerem (nevýměnné disky) a Bitockerem To Go (výměnné disky) Obnovovat soubory ze zálohy pak také logicky jde.

Problém nastává při potřebě obnovit celou bitovou kopii diskového oddílu. Nástroj pro obnovení umí odemknout zašifrovaný systémový disk s Windows, ale zašifrovaný disk se zálohou už nevidí.
V tomto případě nás dokumentace Microsoftu nechává na holičkách a radí nám dešifrovat si disk se zálohou v jiném počítači. Ale ukážeme si, že to není nutné.


Berme v úvahu modelovou situaci:
Máme Windows 7 Enterprise/Ultimate se zapnutým Bitlockerem pro disk C. Pomocí Windows Backup provádíme zálohu obsahující bitovou kopii disku na externí USB HDD. Externí disk je zašifrován pomocí Bitlocker To Go.

Připravíme si:
Obnovovací klíč na jednotku flash nebo do souboru. POZOR, tyto možnosti se liší.
Obnovovací klíč pro oddíl se zálohou, ideálně také na flashku.


Po nabootování z WIN 7 DVD zvolíme opravu a obnovu ze zálohy. Windows vyhledají instalaci Windows a nabídnou nám odemknutí cílové jednotky.


Použijeme dlouhý restore key nebo připravený obnovovací klíč na flashce.

Pokud budeme chtít pokračovat v obnově dál, Wbackup nám sdělí, že nenalezl žádné zálohy:












My se ovšem ošálit nedáme, pomocí  kombinace SHIFT + F10 si spustíme příkazovou řádku ( tato kombinace funguje již od Windows XP)

Spustíme si diskpart abych mohli odhalit pod jakým číslem se skrývá náš svazky se zálohou:

DISKPART

Vypíšeme si svazky

LIST VOLUME

Ze seznamu pravděpodobně podle velikosti budeme muset vybrat náš zálohovací disk, nápovědou nám může být, že nebude mít písmeno.

Zvolíme tedy zálohovací svazek (místo x zadejte číslo svazku)

SELECT VOLUME x

A přiřadíme mu písmeno, vyhnete se již obsazeným jako například C nebo X

ASSIGN LETTER=L

Klávesovou zkratkou CTRL +C zavřeme diskpart a pokračujeme k připojení BITLOCKER jednotky. Pro informaci o jednotkách si můžeme vypsat připojené Bitlocker svazky - jeden z nich by měl být váš systémový disk, druhý zálohovací disk, již s písmenem.

MANAGE-BDE.EXE -STATUS

A nyní samotné obnovení. Pustíme si notepad a otevřeme si txt s obnovovacím klíčem pro zálohovací jednotku:

NOTEPAD

Notepad si necháme otevřený a zkopírujeme si dlouhý recovery key. A do CMD opět zadáváme:


manage-bde.exe -unlock L: -rp ----douhý recovery klíč------

Místo L dejte své nastavené písmeno jednotky, za rp je mezera a pak vložte dlouhý reovery key. Dostane se nám hlášení, že jednotka byla úspěšně odemčena.


Když znovu zkusíme spustit System Image Recovery, záloha je nyní nalezena a můžeme postoupit k obnovení. Po obnovení budou data na disku opět v nezašifrovaném stavu.






sobota 4. května 2013

Pomalost Intel RAID 5 způsobená vyprazdňováním cache pro zápis - aneb proč flushovat

Tento článek by se také mohl jmenovat: Máte UPS? Zdvojnásobte si výkon svého diskového pole....


Anotace ve zkratce:
Tento článek pojednává o kombinaci Intel Rapid Storage Technology RAID 5 pole na chipsetu H77 s technologií Hyper-V. A konkrétním problému s pomalostí mysql databáze ve webové aplikaci Tiny Tiny RSS, běžící ve virtuálním počítači. Problém způsobuje bezpečností disková funkce Windows :  write-cache buffer flushing. Také se zabývá řešením. 




http://www.intel.com/content/www/us/en/chipsets/mainstream-chipsets/chipset-h77.html
Asi půl roku využívám Intel raid na chipsetu H77. Kombinace RAID 5 a tří spolehlivých disků Samsung HD154UI  je prozatím bezproblémová. Výkon pole nijak neoslní, mělo by jít o odolné řešení pro případ výpadku jednoho z disků. V případě závady základní desky stačí pole zapojit do jakékoliv jiné se stejnou nebo novější verzí RTS(Intel Rapid Storage Technology) option ROM.

Problém ovšem nastal když jsem v Hyper-V nasadil virtál obsahující mysql server pro Tiny Tiny RSS (viz předchozí článek http://blog.mj12.eu/2013/05/nasazeni-tiny-tiny-rss-v-ubuntu-serveru.html )

Kupodivu Tiny RSS bylo nezávisle na OS neuvěřitelně pomalé. Načtení složky trvalo až stránky trvalo cca 5 sec, načtení složky 10 sec). Běžná rychlost načítání je maximálně do 0,5sec. Po delší diagnostice a ladění SQL databází jsem našel původ problému. Je jím "Windows write-cache buffer flushing". Tato funkce je ve Windows ve výchozím stavu zapnutá (pokud vůbec cache používáte) a stará se o pravidelné vyprazdňování cache na disk - tím snižuje riziko ztráty dat v případě výpadku napájení nebo chyby STOP.


Návod jak vypnout vyprazdňování cache naleznete zde http://support.microsoft.com/kb/324805/en-us
Nevím zda to je problém čistně RTS a mysql či RTS a Hyper-V. Ale reálný rozdíl jak uvidíte na obrázcích níže je velice zajímavý.

Virtuální počítač (ať už win nebo linux) má tendenci provádět nonstop zápisy do svého vdh, jde asi jen o 9 - 400KB/s. Ale jak vidíte stačí to k vytížení disku na maximum. Latence se pak podle taskmanageru pohybuje kolem stovek ms až sekund. Délka diskové fronty je 1,5-3.

Stav se zapnutým virtuálním počítačem obsahujíc mysql databázi. Flushování ve vychozím stavu zapnuté.

A zde je stejná situace s vypnutou funkcí "Windows write-cache buffer flushing"

Další příklad propadu výkonu můžeme vidět na programu HD Tune. Jako první opět ve výchozím stavu se zapnutým flushováním.

A bez této bezpečností funkce:
Jak je vidět, rychlost je téměř dvojnásobná, v případě latence je to až pětinásobně lepší.
A ještě file benchmark test měřený přímo v Hyper-V hostu. 

Zde již je to zajímavější, ovšem stále to nevysvětluje proč s flushingem mysql pracuje desetinásobně pomaleji. 
Ještě dva údaje pro porovnání:
Access Time           : 0.568 ms
Burst Rate            : 197.9 MB/s

Access Time           : 0.377 ms
Burst Rate            : 518.2 MB/s

Ovšem stojí tento rozdíl za vypnutí vyprazdňování cache? Bez automatiky Windows cache vyprazdňují pouze při každém vypnutí.....A u RAID může neplánované vypnutí způsobit až kolaps pole, nemluvě o poškození otevřených dat.

Možná řešení problému:


  1. Jasným kandidátem na řešení je tedy UPS komunikující s PC která by informovala o výpadku a sepnula bezpečné vypnutí. Bohužel o není levná legrace. 
  2. Nic neměnit a používat bezpečné vyprazdňování. Bohužel tato alternativa by mi znemožnila používat TT-RSS na RAID 5. Musel bych použít nějaký jiný samostatný disk, iSCSI... či RAM disk? :-)
  3. Snížit riziko. Microsoft v rámci Sysnternals nabízí program Sync 2.0. Ten slouží k ručnímu vyprázdnění diskové cache. 

Program Sync 2.0 aneb snad to bude fungovat....

Microsoft dělá výborný software - tato věta není jen fráze. Prográmek Sync z roku 2006 bez problému funguje na Windows 8 x64. A dělá to co má:


Je až k nevíře že program z roku 2006 bude fungovat v roce 2013. Na obrázku níže je červeně označený moment kdy byl sync spuštěn, přenosová rychlost klesla a cache se vyprázdnila.


Nic tedy nebrání vytvoření naplánované úlohy která bude Sync spouštět. Jenže jak často? Jak často Windows ve výchozím stavu flushují cache? Jednou za hodinu? Každou minutu? Každých 5 vteřin? Vteřinu? 0.1 vteřiny? 0.001 vteřiny? Po každém zápisu či při iddle? Bohužel se mi tuto informaci nepodařilo získat pro Windows, ale ani pro Linux. 

Pravděpodobně každých 15-30 minut bude rozumné rozmezí pro iddle běh. 


PS: Pokud prodáváte nějakou starší UPS, mám zájem :-) 

Nasazení Tiny Tiny RSS v Ubuntu serveru (v Hyper-V)

Vzhledem k ukončení Google Readeru je na čase hledat vhodné alternativy. Pokud vás láká myšlenka hostovat si vlastní RSS čtečku, či jste dokonale zvyklí na Android čtečku gReader, (podpora je v beta verzi zde) nabízí se Tiny RSS.

Na živo si TT-RSS můžete vyzkoušet na veřejné instalaci jednoho dobrodince na http://rss.cicolina.org/

Pokud zvažujete vlastní nasazení, je to docela snadné. Pro linux existují desítky návodů. Kupodivu ale pro Windows jich moc není. Pokud máte k dispozici Windows server, asi ideální řešení je vytvoření dedikovaného VM v Hyper-V. Výhodou je přenositelnost a snadná zálohovatelnost. V případě reinstalace hostitele si stačí zálohovat několika gigabajtový vhd a později opět připojit. Již žádné reinstalace a rekonfigurace.....Hyper-V se také na rozdíl od virtualboxu postará o uložení stavu při restartu hostitele a opětovné obnovení po nastartování.

Pro TT-RSS v Hyper-V se vybízejí dvě varianty:


  1. Windows host s nějakým druhem LAMP serveru, například XAMPP. Výhodou je velice snadná instalace a konfigurace. Také můžete využít dynamickou paměť - VM pak neujídá paměť kterou nevyužívá. Licencovat můžete například z MSDN (AA ), Windows 8 za pár stovek... Takový server 2003 se vejde do 3GB a vystačí s 200-300MB RAM. Aktualizaci feedů je pak možné provádět pomocí naplánovaných úloh, což je zábavná alternativa vůči linux daemonům.  
  2. Hyper-V oficiálně podporuje pouze CentOS a RedHAT. Naštěstí Nové verze Ubuntu mají již integrované integrační služby pro Hyper-V. Není tedy problém s ovladači ani s vypínáním. Bohužel není reálném používat GUI verzi Ubuntu - rozhraní je nepoužitelně pomalé, a to i po zakázání framebufferu. Další varianta je Debian. Pro něj můžete doinstalovat integrační služby velice snadno v podobě deb balíčku (zde). S GUI rozhraním problém není, pouze je někdy nutné ručně provést ifup eth0

Dnes se ovšem podíváme na instalaci Tiny Tiny RSS v ubuntu serveru.


Instalaci Ubuntu server 13.04 v Hyper-V nebudu nijak zvláště popisovat, pouze nezapomeňte nainstalovat SSH. Pro VM stačí bohatě 512 MB paměti - mysql bude moci hodně cachovat. 

Jakmile jsme na SSH začneme instalací mysq:
sudo apt-get install mysql-server mysql-client

Vytvoříme silné heslo a pokračujeme:
sudo aptitude install apache2 mysql-server libapache2-mod-php5 php5-mysql

A nakonec prerekvizity:

sudo aptitude install php5-cli php5-xmlrpc php5-curl

Nyní máme funkční webový server, pokračujeme Nasazením TT-RSS:

wget https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.7.8.tar.gz
tar -xf 1.7.8.tar.gz -C /var/www/
chown -R root.www-data /var/www/
chmod -R g+w,o+ /var/www/



Nyní si ještě nainstalujeme phpMyAdmin pro snadnější práci a budoucí sledování DB. Zadejte silné heslo.
sudo apt-get install phpmyadmin

Na adrese http://VÁŠserver/phpmyadmin vytvořte nového lokálního uživatele (třeba tinyrss) a rovnou i stejnojmennou databázi. Opět použijte silné heslo.

Na adrese http://VÁŠserver/ by měla být k dispozici úvodní konfigurace. Vyplňte údaje, inicializujte databázi a hotovo. Nyní můžete přidat vaše feedy. Také změňte výchozí heslo!

Zbývá ovšem ještě dořešit aktualizaci. TT-RRS ve výchozím stavu feedy automaticky neaktualizuje (chytré?) Stačí ovšem udělat následující - otevřít nanem rc.local a dopsat řádek...
nano /etc/rc.local 

a přidal řádek:
sudo -u www-data php /var/www/update_daemon2.php > /dev/null&
pak znovunačíst konfiguraci:
rc  /etc/init.d/rc.local start



Nyní se rozběhne aktualizace feedů...a jsme hotovi. Může náš potěšit že na rozdíl od Windows, je na Linuxu aktualizace vícevláknová, stejně se ale připravte na hodiny čekání a naplnění čtečky tisíci příspěvků. 
Nakonec zbývá přizpůsobit si TT-RSS. Na fóru projektu lze nalézt spoustu pluginů imitující vzhled greaderu. Plugin pro identické klávesové zkratky je také již integrován. Po aktualizaci feedů vám také TT-RSS zobrazí seznam již nefunkčních adres spolu se seznamem dlouhodobě neaktivních. Můžete tedy pohodlně opravit sledované adresy - například po přesunu blogů..
Pro přiblížení Goodle Readeru doporučuji ještě toto nastavení:


Automatically mark articles as read – No
Combined feed display – Yes
Confirm marking feed as read – No


A pokud budete mít problém, okamžitě zapomeňte že by jste ho zmínili na fóru projektu. Administrátor s tímto příjemným avatarem....
...se okamžitě postará o vaše zesměšnění a pohřbení dobrých nápadů. (A ne, na fórum jsem nic nepsal, stačí s pročíst několik témat).

A několik článků k tématu TT-RSS:
http://the.geekorium.com.au/make-tiny-tiny-rss-look-and-behave-like-google-reader/

http://tt-rss.org/forum/viewtopic.php?f=22&t=1287

http://nathan.chantrell.net/20130317/tiny-tiny-rss-a-replacement-for-google-reader/


pondělí 24. prosince 2012

Doplnění: Crashplan po skončení trial verze


Cca týden před skončením trial verze jste každý den zasypání varovnými zprávami o vypršení zkušební verze. Následuje seznam souborů v cloudu který bude smazán


V rozhraní se objeví reklama, nijak zvlášť neruší.

A nakonec největší omezení, backup sets jsou nyní vypnuté. Je možné se dostat do jejich nastavení přes Windows enabler, jejich nastavení se pak bude zobrazovat. Bohužel není možné vybrat soubory k záloze a umístění zálohy.

Důležité je, že v bezplatné verzi je možné nastavit, jak dlouho se budou udržovat smazané soubory.
Ovšem není možné nastavit, jak dlouho se budou udržovat revize souborů, v případně TC kontejnerů to může být smrtící pro místo na disku.
A nakonec ukázka kolik dat jde do cloudu přenést:




Upload: 9 916,96 kbit/s (1 239,62 kB/s)
Teoreticky lze:za hodinuza denza týdenza měsíc  




 
nahrát 4 462,63 MB 107,10 GB 749,72 GB 2 998,89 GB


neděle 11. listopadu 2012

Poznámky k programu CrashPlan



Poznámky k programu CrashPlan - zvolená forma je pravděpodobně vhodnější než blogový příspěvěk 

Nebudu se zde rozepisovat o tom co program CrashPlan je či co umí, od toho jsou stovky jiných povrchních recenzí, naopak přikládám soupis poznatků z reálného provozu. Prosím omluvte sloh a styl, jde o upravené záznamy pro osobní potřebu. 
 
Sledování změn souborů:
Program stále ve výchozím nastavení sleduje data jako genius backup....každou změnu. Záloha není možno pustit bez nějaké změny.
Je možné vypnout sledování filesystemu realtime - asi se před zálohou bude kontrolovat změna všech souborů (dle data poslední změny)
 
Bezpečnost:
Šifrování zálohy vlastním přídavným klíčem (místo heslem k CrashPlan účtu)
Nejde downgradovat zabezpečení na režim bez hesla
Lze jako heslo použít 448 bitů dlouhý klíč 
 
 
Zálohování:
CPU time je velice nízký, zatížení také, na druhou stran je zálohování na sítové umístění ve stejné Gbit síti velice pomalé. 28K souborů, 8GB jede průměrně pod 1MB/s. Acronish jde na t
o jinak, nemá problém s o řády vyšími rychlostmi. 
 
Data se opravdu zálohují jen na vzdálený server(cílové umístěné), rozhodně ne na třetí umístění(nejde to přes crashplan servery). V LAN jdou data přes LAN, při komunikaci přes internet jsou přímo mezi sebou, není třeba port forwarding, pracuje podobně jako teamviewer, asi. Ověřeno přes sledován sítové komunikace.
 
Zálohy jde pozastavit na obou stranách
 
Deduplikace tam je, má tři režimy, spíše prodlužuje přenosové doby a zvyšuje zatížení cpu, jak šetří místo netestováno
 
Obnova dat:
Obnova: na každém PC vám to nabízí obnovu ze všech PC které zálohujete, je jedno že je zálohujete třeba do jiného PC - to znamená že seznam souboru je někde v cloudu???
Je možné do jakéhokoliv PC obnovit cokoliv, i když je to zálohováno jinam..prostě se udělá přímo spojení a obnoví se to.
 
 
Je možné obnovit jakákoliv data, pokud jejich zálohovací uložiště je online, pokud online není, není možné zobrazit ani seznam dat. Je možné službu pozastavit a tím aktivně odmítat žádosti o obnovení, nebo rovnou zastavit a záloha se pak stane offline. Lze časově omezit kdy stroj přijímá zálohy od klientů-
  • "unable to restore until we have synchronized with the destination" tato hláška se zobrazí, pokud klient u zálohy běží jen chviličku, zanedlouho se pravděpodobně vše propojí přes servery CrashPlanu.
  • Po přidání přídavného hesla jsou všechny zálohy šifrovány samostatným heslem a bez hesla je není možno obnovit (vlastně dvou hesel)
  • Pokud zálohujete do účtu cizí osoby, vaše data jsou v bezpečí, jsou šifrována a cizí osoba nemá ani možnost tato data obnovovat, naopak vy můžete oc cizí osoby vzdáleně obnovit 
 
Nastavení:
Naprosto senzační je možnost, nastavit prioritu traficku pomocí TCP Packet TOS - třeba acronish způsoboval zácpu a některé slabé routery při jeho zálohování vypadávali a ping padal...také asi uvolní upload, tj bude možné mít nízký ping a přitom uploadovat. Netestováno, přenosové rychlosti jsou tak nízké, že se tato volba hodí jen pro pomalá připojení či slabé routery.
 
Možnost nastavit LAN a WAN limity rychlosti pro upload a download 
 
Program neobsahuje češtinu
 
Opravdu šikovné jsou emailové notifikace, můžete si nechat zasílat denní, týdenní atd přehledy zálohování kde jsou informace o velikosti záloh a poslední záloze. Nebo varovné emaily že například již dva dny záloha neproběhla.
 
Test jak se vypořádá s diferencionálním zálohováním v LAN: 
 
1GB TC kontejner nedokáže zálohovat pokud je v TC připojen, zálohování probíhá opět pomalu kolem 3MB/s, ale prý za to může deduplikace - (na druhou stranu úspora místa), také komprese( u TC kontejneru asi zbytečná) a šifrování po cestě asi také není nutné. Také jsem měl nastaveno využít maximálně 20% cpu
1GB TC soubor uloží komprimovaně jako 681MB (což je divné, že by slabá výchozí šifra pro volné místo?)
 
Při změně soboru je zálohování bleskové, přenáší se jen změněná data!! ta lemra nezálohuje změněný TC- vůbec nezálohuje změny..i když ví že se soubor změnil tak nezálohuje-
Přitom u RAR souboru se změnil a crashplan ho zálohoval a revizoval, ŽE BY KONTROLOVAL ZMĚNY PODLE VELIKOSTI? Odpovědí je There is an option in Truecrypt enabled by default called preserve timestamps of file containers. ---pokud je v TC toto zapnuto nemá šanci CrashPlan zjisti že došlo ke změně (nemění se velikost ani čas změny) Zajímavé je že Dropbox s tímto problém nemá. Dropbox pracuje s delta kompresím, musí si tedy neustále hlídat hashe souborů (u každého souborů hashe velkého množství bloků, a synchronizovat jen změnu)
 
  • Zálohy jsou diferenciální a automaticky do je jednoho souboru, odpadá problém se ztrátou částí jako u Acronishu a znehodnocením zálohy. Program rozkládá zálohy do většího množství cca 4GB souborů
 Takto vypadá zatížení zálohovaného procesoru i3 při uploadu 1MB/s

 
 
Komprese:
Perfektní úspora místa, Mix 7,8GB dat ( profilová data více uživatelů, dokumenty savy her cache prohlížeče atd....uložená velikost je 3,4GB 
 
Je možné na cílovém počítači nastavit maximální množství místa která má APP využít, pokud je množství menší než zabraná data, muže dojít ke smazání dat - toto platí jen pro zálohování na jiné účty.
 
 
Nastavení je možné v textové formě čitelné na webu, příklad: 
D:/Dulezite_Programy/
D:/Instalačky/
D:/Osobni data/
+ seznam vyloučených souborů a složek
 
Takže po reinstalu klienta asi není nutné nastavovat znovu( po čisté instalaci klienta je možné "zdědit" nastavení některého z počítačů, při tom se stáhnou data z online. Pro pozdější dědění je nutný reinstal klienta.
 
 
 
Omezení verze zdarma:
 
Vypadá to, že během bezplatného měsíce je možné vytvářet backup sety a po uplynutí je jen mazat. Podle mnoha zdrojů vytvořené sety zůstanou....podle oficiálního varování CrashPlan se smažou, rozhodně nepůjdou přidávat)
Ve free jen jedna zálohovací úloha (seznam souborů a složek), je ovšem možné zálohovat na více umístění.
 
 
 
Problém s nedostatkem místa, ve free verzi se mažou či nemažou smazané soubory ze záloh? Nejde ostranit jednotlivé revize. Když dojte místo tak co? Automatická mazací politika pro smazané soubory je ve free verzi neměnitelná, jaké je ovšem výchozí nastavení zatím nevím. 
  • Ve Free je možná jen jedna záloha denně bez přesného časování' - prostě jednou za den
  • Dle varovného emailu: Při přechodu do free dojde ke smazání backup setů, a smazání záloh na CrashPlan Central
 
Zkušenosti z provozu:
Rozhraní je opravdu pomalé, naštěstí není nutné s ním moc pracovat
Rozhraní je možné chránit heslem.
  • Trochu matoucí je oddělení zálohovací služby, aplikace obstarávají tray ikonu a samotného programu.
  • Během měsíce se asi jednou stalo že nastal stav "waiting for backup" a bylo nutné ve službách restartovat CrashPlan
  • CrashPlanService si bere 149MB v ram a klient dalších 92MB. Během zálohování komprimovaných deduplikovaných šifrovaných stovek GB si Service bere kolem 400MB a klient  70MB, ikona u hodin 1MB (zobrazuje status a animací signalizuje úlohu)
  • Při zálohování výše zmínění úlohy je zatížení CPU cca 20% (i3 3.30Ghz) Jde hlavně o jedno jádro.
  • Trochu problém je automatický 30 denní trial, do jeho skončení není možné plnohodnotně ohodnotit program ve režimu zdarma. 
  • Kdyby bylo možné vytvářet image disků, šlo by o ultimátní nástroj
  • Není možné nastavit maximální povolenou velikost zálohy kterou by se měl snažit program snažit zajistit. u CrashPlan jsou data na prvním místě, narozdíl od acronishu nelze automaticky odstranovat smazané soubory pokud dochází místo. Jak se chová v praxi, zatím neozkoušeno.
 

  • Bezpečností problém: dají se data obnovit na pc offline ? Kdyby služba přestala fungovat.... Třeba existuje možnost, ale vzhledem k tomu že program umožnuje jen adaptovat zálohy z online seznamu, není jasné co by se stalo kdyby se změnilo např uložiště zálohy. Při běžném provozu(ne po reinstalu) by problém nastat neměl. 

Je možné že uplynutí trial verze napíšu doplnění
Ve zkratce, je to pěkný smysluplný program který má cenu využívat pokud si dokážete představit a naplánovat jednodenní zálohování do jiné lokality.
 
...,

sobota 4. srpna 2012

[povzdech ]Únik paměti Chkdsku


Možná jste si toho všimli, chcete jedou za čas provést hlubší kontrolu (nesystémového) pevného disku na vadné sektory a pustíte si chkdsk x: /f /r /x . Pokud to ovšem zkusíte na x64 bitovém systému pravděpodobně se vám stane to, co vidíte na obrázku viz níže. Chkdsk trpí memory leakem který je prý by design. Sice vám neshodí systém, ale náročnější aplikace padají a systém vám navrhuje uzavření programů které čerpají prostředky systému. Aero je také vypnuto
 
 
Na obrázku je vidět ukončení testování jednoho disku a start testu druhého, během cca pul minuty je RAM zaplněna.

 
Závěr:
 
Vzhledem k tomu že problém prý trvá od RTM verze Windows 7, není pravděpodobné že by došlo někdy k opravě... 
ZDE se dokonce píše, že tento problém mohl oddálit vydání WIN7 a projevuje se pouze při konfiguraci v více HDD
 
Brzy se těšte na test chkdsku z Windows 8, ovšem dle nepotvrzených informací se chkdsk chová stejně - i přes fakt že musel být programově aktualizován aby dokázal pracovat s Windows Storage Spaces.

 
 

úterý 13. prosince 2011

Zálohování s pomocí Windows Backup na Truecrypt volume



"Mnozí" čtenáři by se určitě rádi zeptali, jak se dá zálohovat na Truecrypt disk/oddíl/kontejner pomocí Windows zálohování (Windows Backup) ve Win. 7 či Vista. Rozhodl jsem se tedy nečekat na to, až tento dotaz padne, a vnutit toto moudro světu.

PS: proč se proboha nikdo nezeptá?

Jádro pudla:

Windows se při zálohování chovají chytře a spoléhají na službu "Windows Volume Shadow Copy Service", bohužel to je problém, protože Truecrypt nemá pro tuto funkci podporu, dle své dokumentace. A pokud nechcete zálohovat na ten samý disk, který chcete zálohovat, máte s plnohodnotným zálohování utrum. Existují však cesty jak to rozchodit či obejít.
 
Cesta 1: Lhaní a podvod

Jak jste si asi už ze života ráčili všimnout, pravda a čest Vás nikam nedostane, stejný přístup můžete čekat u zálohování ve Windows. Protože je Vám zapovězeno vybrat jako zálohovací disk TC disk/jednotku, musíte improvizovat. Jediná volba která se nabízí je umístění v sítí. O tom jak to udělat se nebudu rozepisovat. Jednoduše složku na TC oddílu nadílíte a zvolíte ji pro zálohování. Návod naleznete například zde nebo zde. Vypadá to sice pěkně a jednoduše, bohužel jen vypadá. Zálohování do sítové složky je docela funkčně okleštěno. Musíte počítat s tímto:
 
Není možné spravovat a nastavovat použité místo zálohou ( záloha bobtná do nekonečna)
Záloha je na TC disku a tudíž šifrovaná, samotné zálohování může být trošku pomalejší.
Na sítové uložiště není možné uložit více než jednu verzi bitové kopie.

Jak vidíte (čtete), je toto zálohování prakticky nepoužitelné až na nějaké specifické užití.
 
 

Cesta 2: Leave No Man Behind
Pokud tedy chceme použít Windows Backup a Truecrypt, musíme se smířit s tím, že můžeme použít pouze jednu aplikaci s této dvojice. Aneb bez ústupků to nepůjde.
 
Můžete použít jakýkoliv jiný zálohovací program a zálohovat na TC disk
Můžete použít Windows Backup a zálohovat na obyčejný interní pevný disk
Můžete okleštěně použít Windows backup a přes sítovou berličku zálohovat na sítový TC disk či lokálně. 
 
Další varianty zahrnují použití symlinků pro složky, ale opět není jiná možnost jen použití sítové berličky. 
 
Spekulace:
Teoreticky může být možné obejít toto omezení pomocí zálohování mimo GUI, viz wbadmin dokumentace 
 
Autor článku neručí a nenese zodpovědnost za škody způsobené nepochopením dokumentace, zbytečně ztraceným čase, a ani za zbytečnost tohoto článku.