Automat na výměnu kazet ve streameru
Jsou dva druhy lidí: Jedni backupují a ti druzí zatím ještě nepřišli o data. Naše firma se řadí do té první kategorie. Do té druhé už bohužel pár let nepatříme. O data jsme již přišli. Naštěstí ne o moc.
S backupováním je ovšem jeden velký problém. Kapacita harddisků roste nade všechny rozumné meze a s ní i spousta mnohdy zbytečných dat na nich. Jenomže není v lidských silách rozhodnout co už smazat, co sice nechat, ale nebackupovat a co je ještě důležité. Takže je potřeba backupovat stále více a více dat. Naštěstí existují kazety, na které se vejde neuvěřitelných 72GB dat. Alespoň je to na nich napsáno. Ovšem pravda je taková, že se na takovou kazetu vejde jenom polovina = 36GB. Těch 72 by bylo, kdyby se data podařila zkompresovat na polovinu. Hmm, kdo z vás to viděl? Já tento způsob značení považuji za podvod, ale to je vedlejší. Ovšem v každém případě je to stále málo, v našem případě potřebujeme 16 kazet na regulární backupy a pár dalších pro extra backupy. Takže víceméně každý den začíná tím, že je potřeba vyměnit pásku ve streameru. Někdy i několikrát za den. Prostě backupovací program pošle mail a člověk aby se přetrhl. Už tady přestává být jasné kdo je tady pán a kdo je krám.
Nedávno jsem zprovoznil Reprap (kdo neví co to je, tak viz článek tady na rootu) a nastala otázka co zajímavého by se s jeho pomocí dalo vyrobit. Na vhodný nápad nebylo třeba dlouho čekat – automat na výměnu kazet ve streameru. Od nápadu k prvním náčrtkům vozíku, který dokáže vytáhout kazetu ze streameru a vložit ji do poličky, nebyla dlouhá cesta. Asi 10 minut :-). Člověk musí čas od času dělat něco jiného, aby přišel na jiné myšlenky. Takové nadšení do práce jsem už dlouho neměl. Doma sice tak nadšení nebyli, když jsem chodil z práce v devět večer a s nadšením jsem jim ukazoval nové ozubené kolečko do automatu. Ale pochopili mě :-). V sobotu večer, přesně 4 týdny od tohoto nápadu, byla premiéra http://www.youtube.com/watch?v=berFUos0MCM .
[caption id=„attachment42“ align=„aligncenter“ width=„300“ caption=„DATchanger, zatím ještě nezakrytovaný“]
[/caption]
Jak to celé funguje:
Základem celého zařízení je vozík, který se pohybuje vertikálně. Tento vozík dokáže vzít kazetu ze streameru a vložit ji do poličky a samozřejmě naopak. Vlastní streamer je umístěn ve spodní části. V horní části je otočná skříňka na kazety. Vejde se do ní 4×12 kazet. Vozík je zvedán závitovou tyčí připojenou přímo na osu jednoho z motorů. Druhý motor otáčí přes 2 ozubená kola skříňkou s kazetami. Poslední motor je přímo na vozíku a ovládá jazyk, který dokáže vtáhnout kazetu dovnitř nebo ji naopak vystrčit z vozíku ven. V nejvyšším patře je umístěna elektronika. Celé zařízení je díky vnitřnímu USB hubu připojeno po jediném USB kabelu. Samozřejmě plus napájení. Všechno je zavřeno ve skříni z plexiskla, zepředu jsou dvířka.
Při požadavku na výměnu kazety vozík najede před streamer, vyplázne jazyk, popojede kousek výš aby háčkem na konci jazyka zachytil kazetu a vtáhne ji do sebe. Poté popojede dolů, aby se zavřela dvířka streameru. Poté otočí skříňku s kazetami příslušnou stranou dopředu a vyjede před příslušnou poličku. Vyjede s jazykem ven a tím částečně zasune kazetu do skříňky. Popojede dolů a vtáhne jazyk dovnitř. Háček, který je na konci jazyka teď kazetu nevytáhne, protože vozík popojel o pár milimetrů dolů. Nyní vozík popojede znovu nahoru, trochu výš než předtím a čelem háčku zasune kazetu až na doraz. Teď konečně vtáhne celý jazyk zpátky dovnitř, zkontroluje jeho pozici a pro jistotu znovu zasune kazetu až na doraz a zase se vrátí. To proto, aby byla jistota, že se kazeta kompletně zasunula. Nyní vozík sjede kompletně dolů a polovina operace – vytažení a uschování kazety – je za námi.
- detail vozíku
Pro vložení nové kazety je operace podobná. Skříňka se otočí čelem k Ivanovi :-), vozík najede před příslušnou kazetu, ale trošku níž. Vyplázne jazyk co to jde, popojede o pár milimetrů výš, aby se kazeta podzvedla a zatáhne jazyk kompletně dovnitř. Háček přitom zachytí kazetu a ta se vytáhne a schová ve vozíku. Vozík sjede dolů. Teď je ovšem potřeba otevřít dvířka streameru. Vozík tedy částečně vyplázne jazyk a vytlačí kazetu tak, že se přední částí opírá o streamer. Nyní pomalu vyjede nahoru až před jeho slot. Kazeta, jak tře o přední stěnu streameru, zachytí jeho dvířka a pohybem vzhůru je otevře. Teď už můžeme vypláznout jazyk trochu víc, aby se kazeta částečně vsunula dovnitř. Nemůžeme ji vsunout dovnitř úplně, protože háček, kterým jazyk končí, je pod kazetou. Takže se zajede jenom do pozice, kdy se háček skoro dotkne streameru. Teď vozík sjede o pár milimetrů a vtáhne jazyk dovnitř. Popojede o dvakrát pár milimetrů nahoru a začne velmi pomalu vyplazovat jazyk. Háček se teď opře o čelo kazety a pomalu ji zasunuje. Proč velmi pomalu? Protože kazeta jde dovnitř dost ztuha a na vyšší rychlosti by motor neměl dost síly ji utlačit a začal by ztrácet kroky. Dokud jede hodně pomalu, je silnější. V jistém okamžiku je již kazeta dostatečně hluboko a streamer si ji vezme. Jazyk se vtáhne znovu zpátky do vozíku a vozík sjede dolů. Tím se zavřou dvířka streameru a operace je hotova. Uff.
[caption id=„attachment63“ align=„aligncenter“ width=„300“ caption=„vozík zepředu“]
[/caption]
Realizace:
Projekt jsem se snažil udělat tak, aby se co největší počet součástek dal vytisknout na Reprapu. Mám v úmyslu dát k dispozici modely všech součástek, ale musím je nejdřív dát do publikovatelné podoby. Stejně jako schéma a firmware. Ze stejného důvodu jsem pro vývoj použil pouze open source nebo free programy.
Plastové díly:
Na modelování součástek jsem použil program OpenSCAD. Oproti jiným 3d modelovacím programům má jednu nespornou výhodu. Je jako stvořen pro programátory. Modely se skládají ze základních objektů jako krychle nebo válec a popisují programem. V programu je možno používat funkce, podmínky, cykly. Prostě kdo zná programovací jazyk C a má představu o geometrii, by neměl mít s tímto programem problémy. Jediný problém, na který jsem narazil byla instalace. Nakonec – je to ostuda – jsem musel nainstalovat woknousovou verzi a provozovat ji přes wine. Jinak nebyla šance. Knihovny neměly správnou verzi, nové verze knihoven byly v konfliktu se systémem. Prostě děs. Ale přes wine to jelo v pohodě.
Pro generování gcode pro tiskárnu – v podstatě renderování 3d objektu pro tisk, používám Replicatorg. Má sice strašnou spoustu konfigurovatelných parametrů, v nichž se skoro nedá vyznat, ale když se jednou podaří zkonfigurovat, tiskne dobře.
Nejsložitější je skříňka s poličkami. Ta je složena celkem ze 12ti částí, z nichž 8 je velmi dlouhých. Pár milimetrů chybělo, musel jsem upravit Reprap, aby to zvládnul. Těch 12 částí se tisklo přibližně 40 hodin. Naštěstí se u toho nemusí sedět, většinou se tisklo přes noc. Všechny části skříňky jsou pak slepeny a sešroubeny, dohromady tvoří otočnou skříňku pro 4 × 12, celkem 48 kazet.
[caption id=„attachment58“ align=„aligncenter“ width=„300“ caption=„lepeni skříňky na kazety“]
[/caption]
Všechny plastové díly jsou z ABS (černá barva samozřejmě není podmínkou). Kolik materiálu nakonec bylo potřeba nevím, odhaduji to tak na půl kila. Celková doba tisku kolem 70ti hodin. Tady samozřejmě záleží na rychlosti tiskárny.
Ostatní materiál:
Kromě dílů, které se dají vytisknout, je potřeba pár závitových tyčí M8, hrst matic a podložek, přibližně metr hladké tyče průměr 8mm, pár odřezků dřevotřísky nebo tlusté překližky a přibližně 1m čtverečný plexiskla. Skříň by se samozřejmě dala udělat i z překližky, stálo by to polovinu, ale nebylo by to celé tak krásné :-).
Elektronika:
Elektronika je postavena na univerzální desce. Tvoří ji jeden PIC18F2553 nebo podobný. Tento PIC má i USB interface, ale jak už jsem psal výše, na desce je i MAX232 a zatím je všechno připojeno přes RS232 a interface USB to RS232. Motory jsou řízeny drivery L6218. Drivery jsou pak chlazeny malým vetráčkem, protože se přehřívaly. Sice by to neměly dělat, v jiném zařízení fungují i bez větráku, ale asi jim neudělalo dobře, jak jsem je připojil na 12V místo na 5, protože jsem si spletl dráty :-). Ale ještě fungují. Krokové motory jsou všechny typu 17PM se zubatou hřídelí, plastové součástky jsou pak na hřídele motorů nalisovány. Součástí elektroniky je i tranzistor, který vypne napájení driverů, takže ve stavu power off je napájený pouze PIC a MAX232, protože zařízení je stále zapnuto a elektrika je čím dál dražší.
Schema jsem nakreslil v Eagle, který je pro neprofesionální použití free. Plošný spoj jsem zatím nenavrhoval, ovšem Eagle, i ve free verzi, umožňuje i to.
[caption id=„attachment56“ align=„aligncenter“ width=„300“ caption=„pohled shora – elektronika a motory“]
[/caption]
Ostatní zařízení:
Samozřejmě streamer, pak USB hub a zdroj 12V4A (switching). Nic víc.
Firmware:
Firmware jsem chtěl napsat v C. Jaksi jsem zlenivěl, už se mi nechce psát v assembleru. Jelikož jsem chtěl udělat celý projekt kompletně s použitím open source, nemohl jsem použít kvalitní kompilátor MikroC, který jsem používal již dříve na jiné projekty. Po krátkém hledání jsem našel Cpik. Je součástí packetu PIKDEV – obsahuje IDE, kompilátor i programátor. Má sice několik omezení, například nemá konstrukce switch-case, ale jinak funguje celkem dobře.
Při psaní firmware jsem se setkal se zajímavým problémem – zrychlením. Doposud jsem všechny krokové motory ve všech zařízeních, které jsem dělal, pouštěl hned na plnou rychlost. Případně jsem prvních N kroků udělal na poloviční rychlosti a pak jsem přepnul přímo na plnou. Ale v tomto projektu jsem to už nechtěl udělat takhle prasácky. Inspiroval jsem se firmwarem reprapu a článkem http://www.embedded.com/columns/technicalinsights/56800129?printable=true. V zásadě jde o to, že pro korektní výpočet času za který se má provést další krok motoru, je potřeba vypočítat 2 druhé odmocniny. Vzhledem k tomu, že nejvyšší rychlost motoru v tomto zařízení je 1800 kroků za sekundu, processor by musel spočítat druhou odmocninu za 270 mikrosekund, což absolutně nedokáže. Algoritmus inspirovaný výše uvedeným článkem vyžaduje pouze jedno 32bitové dělení a pak už jenom rotace a pár sčítání a odčítání. I tak jsem ovšem musel zvýšit rychlost processoru na 24MHz. Na 12MHz nestíhal.
Firmware přijímá commandy po seriálce (v budoucnu možná přímo po USB) a postupně je provádí. Commandů není moc, pouze pohyb jednoho z motorů jedním nebo druhým směrem, synchronizace pozice podle home sensoru, zjištění stavu (kazeta ve vozíku, dvířka streameru otevřena) a power on a off. Commandy pro motory mají celkem 3 parametry. Počet kroků, počáteční rychlost a konečnou rychlost. Čím menší je počáteční rychlost, tím je menší zrychlení a zpomalení.
[caption id=„attachment61“ align=„aligncenter“ width=„300“ caption=„hotový DATchanger“]
[/caption]
Driver na PC:
Driver na straně PC je celý napsán jako bash script. Původně to byl jednoduchý testovací prográmek, ale nakonec jsem ho rozšířil na všechny funkce, které byly potřeba. Má dvě úrovně. Nižší úroveň je určena pro testování. Vyšší úroveň se volá přímo z backupovacího programu BACULA a využívá samozřejmě funkce první úrovně. Na nižší úrovni akceptuje commandy jako extract, put, get, insert. Tyto commandy dělají přesně to, co vystihuje jejich jméno. Kromě toho dělají i základní kontroly, takže pokud například po commandu get není kazeta ve vozíku, command se automaticky zopakuje. Na vyšší úrovni jsou commandy loaded, load, unload, list a slots – přesně ty, které potřebuje Bacula. V této úrovni si pamatuje která kazeta je ve streameru a dokáže ji vrátit zpět na správné místo.
Bezpečnost:
Ještě bych se chtěl zmínit o jedné perličce. Vzhledem k tomu, že čas o času je potřeba otevřít dvířka skříně a vložit novou kazetu, případně vyměnit některou poškozenou, je potřeba myslet i na bezpečnost. Backupovací program se může v kterémkoliv okamžiku rozhodnout, že chce novou pásku a datchanger by se mohl rozjet v okamžiku, kdy v něm má někdo ruce. Ono by se samozřejmě nic nestalo, protože motory jsou slabé a jsou krokové – při přetížení se jednoduše zastaví a bzučí. Ale přesto jsem do driveru udělal následující drobnost: Před commandem load a unload (jediné 2 commandy z vyšší úrovně, které hýbou mechanikou) se udělá 6000 kroků na ose Z s rychlostí 3000 kroků za sekundu. Bez jakéhokoliv zrychlení. Na této rychlosti se motor nestačí roztočit, je příliš slabý, takže zůstane stát a bzučí. 2 sekundy bzučí, pak se zase všechno vypne a počká se 5 sekund. Teprve poté se provede požadovaný command. Člověk má mezitím dost času, aby dodělal co dělal a vytáhl ruce. Když už kvůli ničemu jinému, tak kvůli tomu, aby nezablokoval některý pohyb zařízení.
-
Související články na ostatních blozích
-
Recenze: Chromebook Education 11 3189 2-in-1 (2017) 30. 12. 2018 1:37
-
Samsung Galaxy A5 2017 (zkušenosti uživatele) 27. 2. 2017 23:03
-
Jak vypálit Blu-Ray video v Linuxu 19. 8. 2016 20:23
-
Já a elektronické knihy aneb přelomový rok 2016 : Výběr 30. 12. 2015 18:03
-
Prodeje čteček raketově nerostou, žádné překvapení 22. 9. 2014 11:41
-
Geek s rodinou v zádech - uživatelská recenze 18. 7. 2014 8:16
-
-
Jet (neregistrovaný)
[7] je to pravda, mezi put a get se sjede dolu. Je to ze trech duvodu:
1. mohlo by byt potreba otocit skrinku
2. kontrola home, aby byla jistota, ze jsme ve spravne pozici.
3. kazdy command je udelany tak, aby mohl byt poslan samostatne, konci v home pozici a vypne napajeni.
Ono je to stejne vicemene jedno, protoze bacula (backupovaci program) stejne napred posle unload, ktery konci s put a pak teprve load, ktery zacina s get. Mezitim muze teoreticky ubehnout i delsi cas. Prakticky je ale stejne posila jeden za druhym.p.s. zavitova tyc je mosazna, matice je zelezna, takze by to teoreticky nemelo potrebovat mazani. Ale je pravda, ze to trochu zpiva :-)
-
Jet (neregistrovaný)
[8] Abych pravdu rekl, tohle me hned nenapadlo. Ale stejne by to uz nebylo tak pohodlne, protoze pro kazdou zmenu zrychleni bych musel prelozit program a uploadnout ho tam. Takhle jsem si mohl pohrat s rychlostmi i se zrychlenim v realnem case v seriovem terminalu a hned videt jak se to chova. Napriklad otocna skrinka se s prilis malym zrychlenim neroztoci. Je to pravdepodobne tim, ze se dostane do rezonance. S vyssim zrychlenim funguje spolehlive. S prilis vysokym by se zase nerozjela z duvodu velke zateze motoru.
-
JardaP (neregistrovaný)
9.: Na teorii o nepotrebnosti mazani zapomente, nevim, kde jste ji slysel. To plati tak akorat treba tehdy, kdyz mate darling prisroubovany mosaznymi matkami na zeleznych sroubech. Nesrezne vam to dohromady a za 10 let to pujde odsroubovat, i kdyz i tady plati, ze trochou vazeliny dnes si za 10 let usetrite praci.
Styk mosazi s oceli urcite neni zcela odolny proti oderu, da se o tom akorat rici, ze se vam to asi nezadre. Osobne bych tam dal nejakou hodne lepkavou lithiovou vazelinu nebo mozna neco s grafitem, pokud se sezene ridsi, nez vazelina do tezkeho strojirenstvi, ktera je jak asfalt. Pokud nekde vystrachate stary dobry Lithol, bude vas sroub urcite naramne spokojen. Pokud to nenamazete, mohl byste za cas zacit pozorovat, jak se vam dole hromadi mosazny prach.
-
Jet (neregistrovaný)
[16] no nic, dam tam listecek: "V roce 2111 vymenit tyc" a radsi k tomu jednu pridam, protoze neni jisty, jestli je jeste budou vyrabet :-) Podobne jsem daval poznamku k jednomu zarizeni, co jsem projektoval - "1.3.2100 posunout datum o den dopredu", protoze RTC, ktery jsem tam dal nebylo kompatibilni s rokem 2100 - delalo ho prestupny i kdyz nema byt. Doufam, ze si tu poznamku nekdo precte :-)
-
kol.jdouci (neregistrovaný)
No zálohování na pásky jsem v dnešní době ještě neviděl fyzicky někde používat, protože je to zastaralé, pomalé a drahé. Veliké HDD jsou sice hodně nespolehlivé, ale pokud budete mít dva HA backup servery, na každém disky v raidu, tak by byla sakra smůla, kdyby to celé spadlo.
-
Rado1 (neregistrovaný)
-> autor: Kompresia silne zavisi na type dat. 2x je marketingove cislo. Filesystemy mame bezne 1.5, ale databazy aj 5.
-> [18]: Chod na exkurziu do akejkolvek firmy, kde tych dat je viac. Zalohovacie riesenie ma cenu fixnu a cenu za GB. Vznikne z toho nejaka ciara nakladov. Maly NAS zacina nakladmi urcite nizsie ako paskova kniznica, ale cena pasky za GB je radovo nizsia ako u HDD. Takze v urcitom bode sa tie dve ciary pretnu za za danou hranicou mnozstva dat je uz vyhodnejsia paska.
Ver tomu, ze mat ulozenych niekolko PB [ano, petabajtov] na diskoch je overkill -
Jet (neregistrovaný)
[18] a ostatni co si mysli, ze se dnes uz pasky nepouzivaji: http://www.youtube.com/watch?v=d-eWDuEo-3Q&NR=1 nebo http://www.youtube.com/watch?v=Bde8wJtzRx8&feature=related Pripomina to Matrix :-)
-
aaa (neregistrovaný)
[18] no pouziva sa. http://en.wikipedia.org/wiki/Linear_Tape-Open
Videl som datacenter s Ultrium tape library + robot ktory robil tu istu pracu ako tento super hack (akurat boli 2 redundantne tape library, kazda s velkostou asi na 2 racky), nechcem ani odhadovat kolko $$$ to stalo... -
Jet (neregistrovaný)
[25] lepsi urcite, puvodne jsem to chtel udelat presne takhle, ale nakonec jsem byl linej, uz se mi ho tam nechtelo montovat. Dva radky ve scriptu
send Zr-6000,3000
sleep 5
byly podstatne jednodussi :-) Navic, kdyz takhle sedime v kancelari a slysime zabzuceni, se jdeme honem podivat, jak to krasne vymenuje kazetu :-)Navic mi dosly sroubky 2.2mm x 15, ktere potrebuju na mikroswitche. V zelezarstvi mi rekli, ze by museli objednat celou krabicku - 2000 kusu a stalo by me to 45 euro, coz je srovnatelny s cenou celyho zbytku (samozrejme krome streameru). Tak jsem se uz na to vykaslal.
-
Jet (neregistrovaný)
[18] jeste jedna poznamka k harddiskum v Raidu - V jedne firme meli krasny server se tremi harddisky v raidu, z nichz kterykoliv mohl kdykoliv shoret a nic by se nestalo. Na serveru bezely woknousy. Ty se ani nenamahaly oznamit, ze je jeden harddisk mrtvy a zjistilo se to, az kdyz odesel dalsi. Pak to teprve woknous milostive oznamil. Tim, ze se resetnul a uz nebootnul :-). To byla teprve zabava.
-
HDD (neregistrovaný)
[27] jestli to neni spis tim, ze o stav disku se stara spis dodatecny software (treba k RAIDu) a ne OS (ten ty disky fyzicky ani nevidi, takze nema co zkoumat). Zalezi co to bylo za "servery", pokud neco lepsiho tak je k tomu vzdy software ktery informuje o stavu RAIDu (a ne jen RAIDu).
-
mivi (neregistrovaný)
[18]: Ses trosku vedle. Pro velky kontinualni data jsou pasky pomerne idealni a jak uz tady nekdo rekl, pri vetsim mnozstvi dat se Ti naklady "obrati" a zacne to byt vyhodny. BTW: Jak budes resit dlouhodobou archivaci v jine lokalite? Budes prevazet server i s RAIDem? Nebo jen demontujes disky a pak je budes skladat v pripade problemu zpet do RAIDu? Nebo si budes platit dark fibre za obrovsky prachy, abys mel dobrou a spolehlivou konektivitu pro geograficky oddelenou lokalitu, kam budes zalohovat jednou za cas?
Jinak obecne, pokud si nekdo svych dat ceni (= je na nich skutecne obchodne a pracovne zavisly), urcite nema problem investovat do LTO 4 nebo LTO 5 paskovych ulozist. Jedna LTO 4 paska (800 GB / 1.6 TB) pak vyjde na cca 800 bez dane, do paskove knihovny jich naperete treba 20 a neresite takovyhle stavebnice.
Jinak vsechna cest autorove schopnosti vyporadat se s technikou. :o) Jen mi to na dnesni dobu pripada tak trochu jako za minulyho rezimu, kdy si kdekdo neco smrdlal na kolene, pac nebylo nic jinyho :o)
-
Jet (neregistrovaný)
[30] dik za uznani. Samozrejme mas pravdu, ze bych si to mohl koupit uz hotove, za radove 4500$ plus dane a clo a postovne, ale to neni ono. Tuhle zalezitost jsem delal predevsim proto, abych si pohral a dokazal sam sobe, ze to dokazu. Krome toho jsem se pritom naucil spoustu veci, napsal spoustu kodu, ktery jsem uz psal s ideou aby byl pouzitelny i podruhe a i pro dalsi lidi. I proto mi to trvalo dele nez jsem ocekaval. Dalo mi to dobry pocit zadostiucineni, nasel jsem kompilator C pro PIC, v nem jsem nasel i nekolik drobnych bugu, ktere se chystam zdokumentovat a poslat autorovi, pokud se mi nepodari je odstranit. Takze vysledek celeho meho radove 100 hodinoveho snazeni je (alespon pro me) uspokojujici.
Jak zminujes minuly rezim - byla to tvrda, ale celkem dobra skola improvizace a neobvyklych postupu. To dnesni mladezi chybi. Ne ze bych jim pral komunisty, to ne, ale clovek se pritom naucil. -
Inkvizitor (neregistrovaný)
Pokud si, autore, budeš chtít ještě více ušetřit práci, používej namísto slova "backup" český ekvivalent "záloha". V prvním pádě to vyjde nastejno, ale v jiných ušetříš písmeno za každý výskyt. ;-) Článek je každopádně hezký a souvisí se zaměřením serveru, což bohužel není na zdejších blozích vždycky pravidlem.
-
mivi (neregistrovaný)
[31] Jo ja to z druhe strany chapu, patri to k dusi kazdeho spravneho ajtika, obcas se takhle vyblbnout :-) A kdyz to cloveku da neco dalsiho, tak je to samozrejme prijemny plus.
K tem penezum za backup zarizeni. Samozrejme, samotny zarizeni levny neni. Je to dano jednak tim co umi, druhak i tim, ze backup reseni je kritickou soucasti kazdyho seriozniho IT - do ceny se vtahne i patricna cast marketingu. Ikdyz - srovnal bych to s necim jako je treba auto. Kdyz si jednatel, enbo nejaky manager poridi novou Audi za 2 miliony, prakticky nepremysli a okamzite si zacne platit ranec za havarijni pojisteni pro pripad, ze dojde k nejake katastrofe. V pripade, ze se mu toci penize ve firme a mel by zaplatit jednorazove 100 tisic za paskovou knihovnu, u niz si tu katastrofu az tak predstavit neumi, tak na to uz se kazdej diva jinak. Mam pocit, ze lidi u nas se jeste moc nenaucili premyslet timhle smerem, coz je skoda. Teda pro ne... :-) Ale to uz odbocuju, to je spis tema na nejakej jinej blog... -
Ed (neregistrovaný)
[18] Pasky se pouzivaji porad, soucasne LTO maji velkou kapacitu a jsou HODNE rychle. A na rozdil od disku maji pri archivaci podstatne vetsi trvanlivost. Moznost ji zamknout proti zapisu take neni k zahozeni. No a potom samozrejme to, ze v knihovne vam je robot take sam prehazuje. Kdyz do provozu vratite pasku, ktera vam treba pul roku lezela v trezoru, knihovne staci z ni precist carovy kod nebo cip aby vedela, co na te pasce je (pokud ji ma v databazi, samozrejme), vubec ji nemusi davat do cteci mechaniky.
-
Lego (neregistrovaný)
Skvela praca, zavidim :). na toto sa nechytam ani nahodou. jedina vec, kt. mi udrela do oci su tie drevotrieskove dosky, kt. tomu (z mojho pohladu) dodavaju vyzor z minuleho rezimu :). ale to je jedina vec. inak super!
zaujala ma aj info ohladom kompresie dat. tiez pouzivat DATku - HP Storageworks 160. mam problem prave s kompresiou, lebo SWtools, kt. boli k jednotke uspesne otestovali, ze mam zapnutu kompresiu a ze aj spravne funguje. ale pri backupe 140GB mi vypyta novu kazetu uz pri 72GB. pouzivam kazety 80GB/160GB* :). vies mi prosim ta povedat, ze ako je to s tou kompresiou? Je to realne dosiahnut, alebo mam na to rovno zabudnut? Data ktore zalohujem su AVI(nekomprimovane), PSD, INDD, EPS, ... robim v grafickom studiu. Velmi by mi tato info pomohla.
PS> Pri kupe DATky som zvazoval aj disky, ale pri prepocte to nakoniec vyslo lepsie pre DATku, takze +1 za DAT.
-
next_ghost (neregistrovaný)
[9] Já osobně bych nechával vozík sjet úplně dolů jen při otáčení skříňky a na úplném konci řetězu příkazů. Když by program byl uprostřed řetězu příkazů, tak by pokračoval dalším příkazem z pozice, ve které vozík dokončil předchozí příkaz. Pozice vozíku by se dala průběžně kalibrovat pomocí pár LED a fototranzistoru. Dál bych ještě do vozíku zabudoval optozávoru a kontroloval, jestli má smysl dělat put a insert.
[10] Sice nemám představu kolik paměti má ten procesor, který to celé řídí, ale nešlo by tu tabulku konstant přepočítat jednorázově při změně konfigurace a během práce prostě číst z RAM? Vyřeší se tím jak časování pohybu, tak potřeba rekompilace kvůli změně rychlosti.
-
Jet (neregistrovaný)
[39] ta drevotriska, to je kvuli tomu, ze jsem stavel z toho, co jsem uz mel. Prijde to levneji a je to rychlejsi nez jezdit do obchodu.
Co se tyce komprese, hodne zalezi na datech. Sice rikas, ze AVI neni komprimovane, ale ono je vicemene nekomprimovatelne. Takze zazipovat avi nebo mpeg nebo jpeg nema absolutne zadny smysl. Stejne jako dokumenty. ODT, ODS a podobne nejsou nic jineho nez zipnuty archiv nekolika (textovych) xml files. Diky tomu, ze jsou vnitrne zipnute, uz se nedaji dale zkompresovat.PSD a INDD nevim co je, o EPS se neda rict skoro nic. Zalezi na jeho vnitrni strukture, resp. na programu, ktery ho generoval. V zasade je to program v postscriptu, plus spousta dat, jejich format zavisi na tom programu. Pokud je ten program chytry a data ma zkompresovane, zipnutim uz moc nevydelas. Maximalne par procent, jestli vubec. Streamer, ktery on-the-fly kompresuje nedela v zasade nic jineho, nez ze kazdy file zipne predtim, nez ho zapise. Takze vyzkousej si kolik vydelas zipem na tvych datech a budes mit predstavu, co s tim dokaze udelat streamer. -
Jet (neregistrovaný)
[41] Jak uz jsem psal nekde predtim, v praxi backupovaci program posle 2 nezavisle commandy - unload a potom load. Driver datchangeru je v podstate jednoduchy script, ktery se spusti pro kazdy command znovu. Po provedeni commandu script skonci, nemuze vedet co bude potom. Prvni vec co se po znovuspusteni scriptu udela je to, ze si osaha home sensory aby vedel kde je. Kdyz uz kvuli nicemu jinemu, tak kvuli tomu, ze nekdo mohl mezitim rucne otocit skrinku, kdyz tam vkladal nove kazety.
Processor ma sice dost ramky - 2k, ale na tuto tabulku by to nemuselo stacit. Zrychlovani muze trvat treba i 1000 kroku. Navic, program by byl zbytecne komplikovanejsi. Takhle, kdyz jsem zjistil, ze to processor nestiha, stacilo jenom zmenit jeden jeho konfiguracni bit, aby jel na 24MHz a ne na 12. On ma PLL, zmena rychlosti je jenom zmena konfigurace. Samozrejme ze ted zere zbytecne trochu vic, radove 1/2W misto 1/4W, ale to uz je to posledni.
-
Lego (neregistrovaný)
[42] Drevotrieska - ok :)
INDD je zdrojak Adobe Indesignu, PSD Adobe Photoshop. Ale to je jedno. Pre mna je matuci parameter HW compression. Ja som si pod tym predstavoval napr to, ze paska znizi rychlost zapisu a teda bude hustejsie zapisovat data a zmesti sa tam 2x take mnozstvo dat. Som naivny? Je to naozaj len HW Zip kompresia?
Velka vdaka za odpoved. -
JardaP (neregistrovaný)
47.: Pokud vim, na VHS pri long play se nahravalo ctyrmi hlavami, na rozdil od obvyklych dvou (dokonce existovaly systemy kompatibilni se sebou samymi, kde bylo hlav 6). Cili zadna komprese, akorat hustsi zaznam. Ke snizeni kvality dochazelo tak leda zvysenim preslechu mezi stopami, mozna demagnetizaci predchozi stopy pri nahravani nasledujici.
-
Mirek (neregistrovaný)
Přidávám se k obdivným komentářům, fakt hustá práce :)
Jenom drobnou připomínku: jakmile mám softwareově řiditelný changer, musím všechny dostupné pásky považovat za online backupy - jakmile se útočník dostane k ovládání changeru, jakoby zálohy nebyly...
Takže oproti vyměňování zálohovacích disků (online/offline) to má dost významnou nevýhodu...
-
KapitánRum (neregistrovaný)
Jestli vidím dobře, máte kapacitu 12 pozic *4 strany zásobník * 36GB tj. ~1.7 TB.
Tak si říkám, jestli by 5 disků za bratru 6 000,- a s kapacitou ~5 TB neodvedlo podstatně lepší práci.
No, jako musím ocenit Vaší řemeslnou zručnost, ale přijde mi to, jako kdyby si někdo na honění pindíka postavil spešl robota.
-
Clock (neregistrovaný)
Na to mazani tyci bych si dovolil podstrcit reklamu na muj open source mazaci produkt:
http://ronja.twibright.com/sexcream.php
