Time Machine - zálohovanie na sieťové disky (2)
28. november 2007, Martin Vrábel, Mac OS X & Darwin,
Keď Steve Jobs prvýkrát predstavil integrované zálohovanie v Mac OS X Leopard pomocou Time Machine, v kútiku duše som očakával podporu ZFS a zálohovania po sieti. Kým v prípade podpory ZFS je to logicky hudba budúcnosti, tak v prípade podpory sieťového zálohovania som nevedel pochopiť ako je dnes možné fixovať zálohovacie riešenie len na lokálne pripojené disky. V článku si ukážeme spôsob ako presvedčiť Time Machine aby zálohoval na sieťové disky a zhodnotíme reálne možnosti sieťového zálohovania.
Stretol som sa s názormi, že Time Machine (ďalej TM) je určený pre nenáročného domáceho používateľa, pre ktorého sú sieťové zálohy zbytočné. Time Machine je skutočne veľmi jednoduché zálohovacie riešenie s minimálnou možnosťou konfigurácie (3 konfiguráky) a je naozaj cielené pre nenáročného domáceho používateľa. Ale vôbec nejestvuje racionálny dôvod, prečo by nemohol domáci používateľ využiť možnosti sieťového zálohovania.
Áno, najjednoduchšie je kúpiť si nejaký USB alebo Firewire box s diskom, pripojiť ho lokálne k Macu a ďalej nešpekulovať. Dnes je však len o málo zložitejšie zadovážiť si podobný box s LAN konektivitou a vyrobiť na ňom sieťové disky. Navyše ešte, s prechodom na Intel architektúru používa Mac stále viac ľudí pohybujúcich sa v heterogénnych sieťových infraštruktúrach, kde je takéto zálohovanie samozrejmá vec.
Prečo teda nevie Time Machine v Mac OS X štandardne zálohovať na sieťové disky? Dôvodov je niekoľko:
Z posledného bodu je zrejmé, že Time Machine bude vedieť zálohovať na sieťové disky aj v neserverovej verzii Mac OS X. Štandardne však nie je táto funkcionalita povolená. Naštastie pre nás, inžineri z Apple nám nechali možnosť ako si túto podporu zapnúť. Stačí prepísať pomocou príkazu defaults hodnotu premennej TMShowUnsupportedNetworkVolumes a od tohoto momentu už Time Machine rozpozná akékoľvek CIFS, AFP alebo NFS sieťové disky.
[DM@MB:~]$ defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
Time Machine rozpoznal sieťový CIFS disk
Po predchádzajúcich riadkoch si možno poviete, že už nemá zmysel ďalej písať. Veď už bolo povedané všetko podstatné, nie? Nie. Zapnutím podpory zálohovania na sieťové disky sa celý proces iba začína.
Podpora súborových systémov
Time Machine striktne vyžaduje aby boli lokálne pripojené disky naformátované na filesystém HFS+. Keďže ide o natívny súborový systém používaný v Mac OS X, niet sa čo diviť. Je to najrozumnejší spôsob ako sa vyhnúť komplikáciam pri prenose dát na iný súborový systém. Najčastejšie ide o problémy pri prenose rozšírených atribútov súborov alebo ide o problémy s komplikovanými názvami adresárov či súborov. Napríklad adresár pomenovaný ako "2007-08-17 @ 02/30/11 PM - 2.apimportgroup" nachádzajúci sa v knižnici programu Aperture, nevyzerá z pohľadu prenositelnosti ani štandardne ani sympaticky. Pri kopírovaní na CIFS disk spôsobuje problémy.
Tu sa vynára netriviálna otázka, ako dostať súbory a ich metadáta zo zálohovaného HFS+ disku na sieťový disk, ktorý je nad iným súborovým systémom, napr. nad EXT3. V Darwine sa to niekedy riešilo tak, že sa modifikovali zdrojáky binárky (napr. rsync) aby dokázala prekopírovať rozšírené atribúty súboru. Time Machine používa ďaleko jednoduchší princíp. TM i jednoducho na sieťovom disku vytvorí .dmg imidž, ktorý je naformátovaný na HFS+ filesystém a je mu jedno či sa nachádza na NTFS, EXT3 alebo inde pokiaľ tam môže existovať dostatočne veľký súbor. Jednoduchšia možnosť pri sieťových diskoch nie je. Veľmi elegantne pri tom pôsobí automatické namontovanie a odmontovanie .dmg súboru po skončení zálohovanieho procesu. Ak plánujete zálohovať na vzdialený disk cez AFP (AppleTalk) protokol a chcete využiť Linux prípadne *BSD, pozrite OpenSource daemon netatalk (pripravte sa na problémy). Ak náhodou plánujete použiť NFS disky, rýchlo na to zabudnite a použite najlepšie CIFS protokol.
Limitujúce faktory
Narozdiel od USB alebo Firewire zariadení sú LAN siete (v domácich podmienkach) rádovo pomalšie. Toto je výrazne limitujúci parameter, od ktorého sa odvíja:
V súčasnej verzii disponuje Time Machine veľmi primitívnymi nastaveniami. Nie je možné granulárne riadiť čo sa zálohovať má a čo nie. Rovnako nie je možné plánovať inkrementálne a plnohodnotné zálohy. Do istej miery si vieme pomôcť zmenou zálohovacieho intervalu StartInterval v globálnom konfiguračnom súbore pre zálohovací daemon Time Machine - backupd:
/System/Library/LaunchDaemons/com.apple.backupd-auto.plist
Interval zálohovania je štandardne nastavený na 3600 sekúnd. Podľa objemu zálohovaných dát a času trvania celého procesu si nastavte pre vás vyhovujúcu hodnotu.
Modelový príklad z firemného prostredia
Povedzme, že chceme cez Time Machine zálohovať dva adresáre, ktorých celkový objem predstavuje 10 GB.
Musíme si najskôr uvedomiť, že ak chceme zálohovať na sieťový disk cez LAN (100 Mbit/s ethernet), tak zrejme nebudeme vo firme jediný pristupujúci na fileserver. Uvážením tohoto faktu, nech máme priemernú rýchlosť zápisu 6 MB/s. Odhadom nám bude trvať prvá, t.j. plnohodnotná záloha cca. 1700 sekúnd = (1666 sekúnd kopírovanie + 64 sekúnd analýza súborov, závisí od ich počtu), t.j. celkovo cca. 28 minút. To nie je vôbec málo, najmä ak sa reálna rýchlosť zápisu na CIFS disk dostane pod hodnotu 3 MB/s, tak sa už čas plnohodnotnej zálohy približuje k 1 hodine! Povedzme, že sa nám každú hodinú zmenia 2GB dát, t.j. pri 6 MB/s a inkrementálnej zálohe bude proces trvať cca. 6 minút a pri 3 MB/s cca. 12 minút. V takomto modeli nemáme s každohodinovým inkrementálnym zálohovaním žiaden problém. Treba si však uvedomiť, že tak malý objem dát akým je 10 GB, dnes už bežne nikto nezálohuje a celkový objem vie narásť aj 10 násobne. Ak si vynásobíte zálohovacie časy 10 krát, vzniká problém. Okamžite sa vynára myšlienka prečo Time Machine neobsahuje granulárny systém zálohovacích pravidiel, pretože sa v súčasnosti nedá pravidlami rozlíšiť čo sa zálohovať má a čo nie.
Zálohovacie časy možete aj nenávidieť
Záver
Time Machine je jednoduchý, ale veľmi užitočný zálohovací systém nielen pre bežného, t.j. domáceho používateľa. Skrytá podpora sieťových diskov poteší, no absencia jemných nastavení zálohovacích pravidiel celý systém pomerne degraduje. Nikto nie je veľmi šťastný ak zálohuje množstvo zbytočných dát. Tu však budúcnosť jasne predpovedá, že môžeme očakávať masívne zmeny. Rovnako by potešila priama podpora šifrovaných .dmg súborov, čo sa v súčasnosti dosahuje pomerne komplikovane. Ale o tom niekedy nabudúce v ďalšom článku o Time Machine.
Loading ...
Streda, 28. november 2007, 0:27
Mne sa TM pozdáva. Síce o nej len čítam,ale v prípade prechodu na LEA by som určite túto vec využíval. Článok len rozširuje základné možnosti tohto nástroja. Ďakujem autorovi, že som sa niečo nové dozvedel.
Streda, 28. november 2007, 8:41
Len by ma zaujimalo, ako to bude potom s full restore pri zlyhani disku a obnovovani z instalacneho DVD.
Streda, 28. november 2007, 9:12
S obnovou dat je vzdy problem, nie je zlozite robit zalohu a snapshoty ale obnovit systemovy disk s OS je o niecom inom ako obnova dielcych suborov … TM nieje nato urcena
Streda, 28. november 2007, 9:29
@zemiak: Za normalnych okolnosti sa da spravit full restore cez instalacne DVD->Utilities>Restore System From Backup. Sam som to netestoval, ale pouzivatelia reportuju, ze TM nevie spravit takyto restore zo sietoveho disku.
V serioznych zalohovacich rieseniach ako je napr. IBM Tivoli Storage Manager sa full recovery robi tak, ze sa nainstaluje cisty system, nahodi sa TSM agent a spravi sa restore. Procesne by som takto postupoval aj pri full restore cez TM.
Streda, 28. november 2007, 9:55
TM jsem spouštěl předevčírem na třech počítačích doma. Mám síťový disk (externí FW připojený k MiniMacu s 10.5 fungujícímu jako server) a složky na něm nasdílené jako síťové disky. Nebyl přitom žádný problém podstrčit TM tyto disky, aniž bych musel cokoli měnit nebo přenastavovat.
Složitější to bylo s omezením toho, co se má a nemá zálohovat. TM začal s tím, že chce na server sypat asi 120 GB dat. Zakázal jsem zálohu Aplikací a Systemu, ale příliš to nepomohlo - nakonec jsem skončil žím, že jsem si (v nastavení TM) dal zobrazit skryté soubory, označil vše, zakázal a povoli jen složku /Users, v ní jen můj účet a v něm jsem ještě zakázal složky Downloads, jednu pracovní složku a .Trash (!), který se podle všeho TM snažil zálohovat taky (!!). Teprve potom klesl datový objem zálohy na nějakých rozumných 11 GB.
Streda, 28. november 2007, 10:09
Problem pri Restore zo sietovych diskov je ten, ze Migration Assistant dokaze rozpoznat len lokalne disky a disky pripojene priamo na zbernicu USB alebo FireWire. Nepocita so sietovymi diskami.
Aj ked urcita moznost tu je, skusit to cez Mac OS X Server. Pomocou neho je mozne nabootovat ostatne pocitace po sieti z image, takze (bez bootovania po sieti) by mala ist aj obnova dat. To je asi dovod, preco to Apple vypol a ponechal sietove zalohy len pre verziu Server.
Pixy: vitame vas na nasom serveri a osobne si velmi vazim, ze nas navstivila taka osobnost ceskeho webdizajnu
Co sa tyka mnozstva zalohovanych dat – ano, presne toto je problem TM tak, ako pise Martin. Nemoznost granulovanych nastaveni pre zalohy. Aspon ciastocne to v Apple mohli poriesit pre bezneho pouzivatela tak, aby sa pri prvom spusteni TM opytal nielen na disk, ale zobrazil hlasku, ze bude zalohovat LEN /Users zlozku. Nasledne by umoznil selektivne vybrat vsetky alebo len niektore dalsie zlozky. Asi ale rataju s tym, ze ceny diskov su uz relativne prijatelne a lepsie zalohovat vsetko ako potom vysvetlovat na Tech. supporte, ze system sa obnovit neda, kedze nie je zalohovany.
Streda, 28. november 2007, 10:50
To, ze sa defaultne neda zalohovat na sietove disky povazujem za velky nedostatok TM. Argument o pomalosti zalohovania po sieti je smiesny: ak by som kupoval NAS, tak jednoznacne s gigabit ethernetom. Potom limitom rychlosti nie je siet ale rychlost diskov (pripadne procesora v NAS-e ak nieco pocita napriklad kvoli RAIDovaniu diskov).
Mohol by autor (ak vie) povedat nieco viac o moznosti/nemoznosti pouzivania NFS? Minimalne ak by bol filesystem na takom NFS oddieli HFS+, preco by mal byt nejaky principialny problem pouzivat ho s TM? Samba/CIFS je totiz zufalo pomala (v porovnani s NFS).
Tiez by ma zaujimala nasledujuca moznost. Pomocou MacFUSE a sshfs.app je mozne primountovat ako sietovy disk cely suborovy system servera, kde mate ssh pristup. Je mozne na takyto sietovy disk zalohovat z TM? Podla toho, co ste pisali v clanku by to zrejme principialny problem (ziadny problem) byt nemal (.dmg subor sa proste vytvori tam… alebo sa mylim? ) .
Streda, 28. november 2007, 10:55
Peter: cez MacFUSE by to v principe ist malo, avsak ta rychlost…
Pomalost zalohovania po sieti: ano, ak si na DOMA kupis NAS, tak 1 Gbit. Ale tu sa bavime o zalohovani na vacsich sietach v ramci firiem ci podnikov (nech to je aj mala kancelaria o 10 pocitacoch). A tam prevlada 100 Mbit.
Streda, 28. november 2007, 11:06
Jozef: Cez MacFUSE a sshfs kopirujem po sieti minimalne 2x rychlejsie ako cez sambu z nasho linuxoveho servera v praci.
Este otazka. Po spusteni sudo defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1 treba restartovat nejaku sluzbu (alebo cely system)? Lebo v TM stale ziadne cielove disky nevidim…
Streda, 28. november 2007, 12:03
@Peter: Takze poporiadku:
1. Ak v TM nevidite sietove disky, zrestartujte backupd.
2. MacFUSE nepouzivam, takze neviem 100%ne povedat. Principialne by to ist malo. Ked som testoval MacFUSE a rozne moduly, bolo to zufalo pomale, takze argument o 2x rychlejsom kopirovani z vlastnej skusenosti uznat nemozem. Je to vsak tema na samostatny clanok.
3. Je pravda, ze CIFS ma velky overhead na protokole. Je to ocividne, no NFS je hudba minulosti. Nepisem, ze je principialny problem pouzivat NFS disk, akurat to nerobi uz ziadna midsize firma, kt. poznam. Ak budete mat zapnute NFS shary na Macu, t.j. nad HFS+, je to najlepsia volba pri NFS. Inak je samozrejme problem s implementaciou HFS+ na ine OpenSource OS. Ak chcem zalohovat rychlo a seriozne, nepouzijem predsa NFS a LAN, vid. nasledujuca kapitola.
4. Pri akomkolvek zalohovani nie je NIKDY smiesny argument o rychlosti a casu trvania bekapu.
Ak som domaci pouzivatel a zalezi mi na rychlosti, nebudem si predsa kupovat domaci NAS. To vsak neznamena, ze TM by nemohol podporovat sietove disky. Cize, domov si radsej kupim disk pripadne pole s FW800 alebo eSataII konektivitou.
Ak som firma, tak pouzivam gigovy ethernet inde nez na to aby si pouzivatelia lokalizovani do jednotliych VLANiek kopirovali data (rozumej filmy) na NAS. To nehovorim o rychlosti takehoto routovania medzi VLANkami. Switch, kt. vie preroutovat 1Gbit VLANy nestoji par korun. Vacsinou sa pouziva klasika fastethernet.
Ak som firma a chcem seriozne zalohovat, tak to sa uz vobec nerobi cez LAN, ale cez SAN. Ide o klasicky LanFree backup, rozhoduje sila optiky a rychlost trunkov. Pouziva sa to na zalohovanie kritickych systemov.
Ak som firma, kt. chce setrit a zaroven mat aj zalohovanie s istym vykonom alebo som domaci nadsenec, pouzijem iSCSI a cez gigovy ethernet pripadne optiku. Neriesim, CIFS, NFS a podobne.
Trochu som sa rozpisal, jemne odbocil a opat sa vratil k teme, ale princip je jasny dufam.
Streda, 28. november 2007, 12:14
Pripojim se s dotazem - po uprave toho Launchdemona (interval zalohovani) je asi taky potreba neco killnout, ne?
Jeste k tomu mnozstvi zalohovanych dat. To pocatecni se da jeste relativne dobre ohlidat a nastavit zalohovani skutecne jen adresaru, ktere chci. Za daleko vetsi problem povazuju neschopnost TM se vyporadat s pracovnimi daty, ktera tupe zalohuje stejne jako vse ostatni. Zrovna vcera jsme se o tom bavili - kdyz si rekneme stahnu z videokamery 30 GB DV, behem odpoledne si z toho sestriham dvacetiminutovy sestrih, vypalim na DVD a puvodni DV smazu, tak TM, ktery mezitim co hodinu poctive zalohoval, vsechny ty pracovni soubory nahrne do zalohy, ktera tim padem vzroste minimalne o 30 GB - a uplne zbytecne…
A hned vcera jsem na to narazil. Ripoval jsem si cd MP3 kolekci 12 CD. Bylo to asi behem hodiny hotove, ale protoze mam MP3 na externim disku, tak ze slozky iTunes, kam se hotove MP3 ukladaji, zase vsechno mazu. Bohuzel mily TM stihl behem toho, nez jsem vsechno naripoval a otagoval, udelat hned dve zalohy a protoze mezi obema zalohami se vsechny soubory zmenily, je tam vsechno dvojmo. Tudiz mam na serveru v zaloze razem skoro o 3 GB uplne zbytecnych dat vic a neda se to rozumne smazat. Leda rucne projit tu strukturu zaloh a od prvni okamziku to postupne vsechno povyhazovat rucne…
Kdyz to neumi Apple, doufam, ze treba brzy nekdo napise nejakou utilitiku, ktera bude TM hlidat a v podobnem pripade napriklad vyskoci okynko a ohlasi: “od minule zalohy pribylo ve slozce X vic nez Y giga novych dat. Maji se zalohovat nyni? Ano, zalohovat hned | Pockat se zalohou slozky X […] hodin”. Nebo jeste nejak lepe a chytreji… Pri velkem “obratu” dat na disku muzu takhle zaflakat 250GB zalozni disk snadno i behem jednoho tydne… Pevne doufam, ze tohle brzy spousta lidi zjisti, bude jim to vadit a Apple se to dozvi - a pak snad zacne dodelavat do TM nejaky rozumny management/uklid apod.
Streda, 28. november 2007, 12:41
pixy: to je uplna pravda. asi najlepsie je vyclenit na taketo veci nejaky folder, ktory ma zakazane zalohovanie a docasne vsetko davat tam…
Mazanie zazalohovanych suborov sa da poriesit jednoducho (a uz som o tom pisal a je to aj na webe apple): staci oznacit folder/subor(y) vo Finderi po spusteni TM (teda vo vesmire) a cez menu Action (ozubene koliesko v toolbare) vybrat “Delete all backups of…”
Streda, 28. november 2007, 12:51
to Pixy: Já tedy nevím…, ale pokud je mi známo (a mám to odzkoušeno) stačí jen přímo v Time Machine označit daný soubor a z menu Finderu (akce) zvolit “smazat VŠECHNY zálohy tohoto souboru” nebo tak nějak…
Jinak mohu potvrdit naprostou JEDNODUCHOST a SPOLEHLIVOST při použití celkové obnovy systému (přes instalační DVD) ze záloh “stroje času”. Obnovoval jsem v rámci testování Leoparda celý systém už 5x a vše vždy proběhlo dokonale hladce.
Time Machine je jedna z věcí, která se na Leopardu skutečně povedla a je to od Applu dle mého názoru trefa do černého. Nemůžete Time Machine srovnávat se sofistikovanými zálohovacími programy, není to žádný Retrospect apod. Jeho síla je právě v dokonalé JEDNODUCHOSTI a samozřejmě v krásném designovém zpracování. Je to pro BĚŽNÉ uživatele to nejlepší co jsem zatím poznal. Zkrátka jen ZAPNI a NESTAREJ se. Toť vše. Nic víc, ale ani míň! Počet lidí, kteří konečně začali díky Time Machine zálohovat určitě stoupl o nezanedbatelné procento…
Streda, 28. november 2007, 13:01
Proto jsem umyslne daval jako priklad MP3 v iTunes nebo strih videa (v iMovie). MP3 se automaticky ukladaji do slozky iTunes, kterou CHCI mit zalohovanou (hlavne Library), DV v iMovie se ukladaji dovnitr bundlu projektu, takze opet casteny zakaz zalohovani neni mozny.
Za to mazani diky, hledal jsem to predtim, nenasel. Cekal jsem, ze to bude akce v UI time machine, ne v UI jeho obsahu. To zcela neapplovsky postrada logiku (stejne jako nutnost po provedene akci zvolit “Cancel”). Nicmene to funguje, zaloha je smazana, 3 GB uvolneny. Diky
Streda, 28. november 2007, 13:38
@ Martin:
1. nepomohol ani celkovy restart, za zahadnych pricin som musel vypnut firewall aby sa mi sietove disky objavili v ponuke TM. (pricom opatovne zapnutie firewallu uz nesposobilo nijaky problem).
2. sietovy disk cez MacFuse a sshfs v TM vidim, ale po jeho vybere ako zalohovacieho disku sa nic neudeje (ostane vybraty iny disk).
Neviem, kedy si skusal MacFUSE, vyvija sa vcelku rychlo a to co bolo k dispozicii pred pol rokom a teraz je nebo a dudy. Urobil som maly test so 780.6 MB suborom, @100Mbit ethernet na Leoparde:
samba: zapis na server - 1:29, citanie - 1:21
))
MacFuse + sshfs: zapis - 1:12, citanie - 1:12
pre porovnanie scp: identicke casy ako MacFUSE
(A samozrejme, sshfs aj scp na rozdiel od samby este robia sifrovanie…ano ospravedlnujem sa, nie je to faktor 2 (bud som si zle pamatal alebo na inej konfiguracii to tak bolo
3. Nemam v umysle pouzivat NFS vo firme (aj ked nevidim ziadny dovod, preco by to mala byt minulost, okrem faktu, ze vacsina dnesnych “administratorov” ani nevie, ze NFS existuje
). Chcem doma Gbitovy NAS so vsetkymi datami, z ktoreho napr. linuxovy satelitny prijimac ma cez NFS (bezkonkurencne najrychlejsie) primountovany disk na ktory nahrava a zaroven vsetky domace pocitace sa tam zalohuju / odkladaju velke data. Na to je opat NFS ako stvoreny (opat kvoli pomalosti samby), samozrejme ak clovek ma *nix pocitace. Myslim, ze v mid-size firmach vela Macov nenajdete, skor ich budu mat domaci uzivatelia.
4. Nehovoril som, ze pri zalohovani je rychlost smiesny argument. Hovoril som, ze smiesny (mozno nie celkom vhodne slovo - ospravedlnujem sa) argument je vylucit zalohovanie na sietove disky argumentaciou o rychlosti sieti…(co mimochodom spravil Apple, nie vy v clanku). Gigabit je dnes vcelku bezna vec a switche stoja par korun (nehovorim o velaportovych a managovatelnych switchoch do velkych firiem, ktore su drahe aj vo fast ethernet prevedeni).
A aby som len nefrflal, chcem sa tiez podakovat za dobry clanok, z ktoreho som sa dozvedel nieco, co sa mi isto zide a samemu sa mi nechcelo patrat. Drzim palce.
Štvrtok, 06. december 2007, 21:25
Martin Vrabel: ojojoj, NFS mrtve? Uz si niekedy videl/riesil riesenia vo velkych podnikoch? Priklad T-Com, T-Mobile, Orange… Vedz, ze NFS je dost hojne pouzivane.
Piatok, 07. december 2007, 9:43
@Holden: NFS je obsolete a ma slusne bezpecnostne diery (historicky). Cize tam, kde sa dba na bezpecnost sa NFS nepouziva alebo minimalne, t.j. s dopadom ak dojdu auditori. Dnesne pouzitie NFS je skor z historickych dovodov alebo ak nejde inak. Opytam sa takto, kolko telnetov sa dnes pouziva v tych firmach, kt. si vymenoval?
Co sa tyka toho, kto co robil a videl. Nebud ako maly Jojo, snad si nemyslis, ze neviem o com pisem
? Zhodou okolnosti som pre tych vymenovanych uz zopar projektov absolvoval, takze som pomerne v obraze.
Uzavrime tuto debatu nech sa nam z toho nestane flamewar. Ja mam o NFS svoj nazor, kt. som tu prezentoval. Nemusite s nim suhlasit, ale treba ho respektovat ako ja respektujem Vase.
Piatok, 07. december 2007, 18:24
Martin Vrabel: nekonfrontujem, len sa pytam
K tej uzavretej diskusii len doplnim, ze bezpecnostne chyby v NFS su podobne urban legend ako tie, ktore sa traduju o sendmaili.
S telnetom sa urcite zhodneme
P.S. NFS je momentalne vo verzii 4, to len tak, aby bolo jasne o com vravim.
Pondelok, 10. december 2007, 12:20
@Holden: Na NFS v. 4 sa pozriem nech si osviezim vedomosti. Co sa tyka dier a urban legiend, tak postfix ani qmail nemali ziadneho Morisovho cerva, ale suhlasim s tym, ze to bolo davno (1988) a sendmail castokrat kapal skor na zlu konfiguraciu, nez na kvalitu kodu. Je v tom nevinne
.
@All: Uprimne si vazim, ze sa na MP vedu (aj) vecne technologicke debaty. Len tak dalej.
Streda, 16. apríl 2008, 1:35
Martin Vrabel: NFS zdaleka nie je obsolete. Pouziva sa napriklad vsade tam, kde je potrebna redundancia, kedze je to bezstavovy protokol. Na NFS viem spravit take, ze mam dva NASy, jeden z nich ma IPcku nas sluzby. Dam tam kopirovat velky film a primarny NAS vytiahnem z elektriky pocas kopirovania. Uzivatel zbada akurat tak zastavenie na par (3-10, podla nastavenia) sekund. A vsetko ide dalej.
To je mozne prave kvoli tomu, ze NFS prenasa v kazdom packete vsetky potrebne informacie, teda mu nevadi, ked sa vymeni server.
Ano, funguje to a funguje to spolahlivo, ziadna data corruption. Toto pokial viem nevie ziadny iny bezne pouzivany sietovy suborovy system.
Okrem toho oproti CIFS a podobnym spravne kopiruje prava, ale to je druha vec.
A ten Time machine mi cez CIFS nefunguje (The backup image could not be created), ale este sa s tym pohram, vela som tomu nedal.