Názory k článku
Windows 10 má vlastní nástroj na obnovení smazaných souborů
-
Zatim je realna funkcnost resp. pouzitelnost dost slaba a to az na hranici totalni nepouzitelnosti. To, co napr, Recuva zvlada zcela standardne, tak "winfr" bud zvlada velmi omezene, nebo vubec??!!
Za mne je tento nastroj zatim spise deklaraci budoucich snah Microsoftu, nez uvolnenim nastroje s realnou pouzitelnosti. Dokonce se obavam, ze uvolnovat "winfr" za tohoto stavu jeho funkcionality je spise kontraproduktivni, protoze uzivatel si muze napachat jeste vice skody, nez cokoli vyresit.
Dostopna dokumentace je take dost vagni a neni jasne jake jsou doporucovane scenare pouziti.
-
U ZFS je to to iste. Myslim, ze existuje nejake platene riesenie ktore slubuje ze by vedelo obnovit zmazany subor na ZFS, ale opensource som nenasiel nic. Ale v ramci toho ze snapshoty su prakticky "zadarmo", najlepsie riesenie je mat pravidelne automaticke snapshoty a subory obnovit "systemovo" zo snapshotu - tym sa clovek vyhne aj prehladavaniu celeho disku aj riziku ze subor nebude po obnoveni kompletny. Pravda kratkodobo (v ramci rotacie snapshotov) to znamena ze zmazany subor hned neuvolni miesto na disku.
-
J ouda (neregistrovaný)
Je to celkem smutné, že snad poslední systém, který měl rozumnou správu smazaných fajlů (set file delete wait time, set minimum file delete wait time, purge attribut, purge/salvage syscall) byl Novell NetWare 3.xx, od té doby je to dost důsledně ignorovaná featura filesystémů, která když už tak se dodělává spíš data recovery tooly než na úrovni filesystému.
-
Ona je to totiž dost okrajová operace.
V provozu stejně potřebujete zálohy, archiv záloh, (u Microsoftu zase shadow copy), snapshoty.
Když půjdeme výš, směrem k uživateli, tak v rámci OS API zase využíváte koš.
Takže k tomu samému výsledku se dopracujete s využitím všeho ostatního, co je k dispozici.
Nástroj na "undelete" měl smysl naposledy v dobách DOS/Windows9x/NT4. Což (ne náhodou) je přibližně stejná éra, kdy se přecházelo z Novellu 3 na Novell 4.
29. 6. 2020, 12:42 editováno autorem komentáře
-
J ouda (neregistrovaný)
Ale ono to není to samé, salvage == někdo/něco omylem smazalo fajl a potřebuju verzi z dopoledne, jinak mám práci na další den.
Záloha tohle neřeší (inkrementálka nebo diferenčka každou minutu sám cítíte že je blbost), a tím pádem žádná technologie co je pod tím (jak píšete, snapshot, VSS ...) sama o sobě taky ne, ta je užitečná na jiné věci.Koš není OS API, ale s prominutím nekoncepční opičárna (znalci windows mě doufám nezabijou za špatný název) shell extension, podporovaný kromě exploreru v pár programech, když prostě smažete fajl, tak už není. (v porovnání s více verzemi každého dokumentu v Novellovském salvage, pokud aplikace jede rozumně udělám temp, uložím to do něj, smažu dokument, přejmenuju temp na dokument).
Ale podle postesků na Internetu i v archive.org bych si rozhodně netroufnul tvrdit, že je to zbytečná featura kterou nikdo nechce. ;-)S časovou korelací souhlasím, s kausalitou naopak. Jednouživatelský DOS na FAT ten undelete celkem dával protože to nemělo co přepsat, Novell taky (i na 4.xx se používal), od té doby co se MS podařilo prosadit na servery NT systémy se nepoužívá, ale myslím že hlavně proto že ty podobnou funkci nemají.
(druhá věc - jako uživatel jste si pustil Salvage a obnovil si co potřebujete. I přes existenci záloh si nedovedu nějak představit jak si běžný jeden z několika tisíc uživatelů pouští třeba Networker klienta a recoveruje file na firemní NASce.)
-
od té doby co se MS podařilo prosadit na servery NT systémy se nepoužívá, ale myslím že hlavně proto že ty podobnou funkci nemají.
(druhá věc - jako uživatel jste si pustil Salvage a obnovil si co potřebujete. I přes existenci záloh si nedovedu nějak představit jak si běžný jeden z několika tisíc uživatelů pouští třeba Networker klienta a recoveruje file na firemní NASce.)
Myslím, že toto docela přesvědčivě suplují "Předchozí verze", na které se využívá shadow volume copy. Když už někdo smaže soubor, vrátí se k verzi o nějaký čas zpět. Svazky s uživatelskými daty se takto "snapshotují" častěji.
Zaměstnanec přijde o nějaký čas práce, ale není to tak hrozné a neděje se to často. Já třeba docela chápu, že se tímto okrajovým use casem nezaneplešují filesystemy.
-
Ondra Satai NekolaZlatý podporovatel"Záloha tohle neřeší (inkrementálka nebo diferenčka každou minutu sám cítíte že je blbost)"
Ne, proc? A hlavne - proc zaloha, kdyz tohle resi snapshoty?
Hlavne smazani je smazani, ale clovek se vetsinou o data pripravi tim, ze si je omylem smaze, ale tak, ze jsou prepsana nejakou horsi verzi,
-
J ouda (neregistrovaný)
Tak pouštějte tu inkrementálku pořád dokola na firemní NASce (a nejspíš se stejně netrefíte do chvíle kdy byly data konzistentní).
Snapshot je príma, ale je to úplně jiný use case, (hook co po každém unlink() udělá snapshot? Pro jednoho usera asi na hraně, pro víc?)
že jsou jiné formy ztráty než smazání souhlas, ale i tak pořád lepší když se dá najít aspoň předposlední uložená verze před přepsáním, než (navíc přes tiket) v lepším případě záloha z noci.
-
S btrfs není problém dělat snapshot klidně každou minutu (a postupně snapshoty zahazovat tak, aby u starších byla menší granularita, třeba starší než hodinu už nechat jen pětiminutové, starší než den hodinové, a tak).
A tyto tenké delty můžete stejně automaticky odesílat jako komprimované, šifrované a podepsané archivy na zálohovací úložiště.
-
Btrfs má offline* btrfs restore, kterým se dá, mimo jiné, obnovit smazaný soubor, a to i s plnými metadaty (název, umístění, ...), v podstatě můžete obnovit celou adresářovou strukturu pokud nebyla přepsána, narozdíl od třeba ext4 kde dostanete plochý adresář s čísly inodes.
Už jsem obnovoval i týdny smazané věci. Když je dost místa, fs to nemá důvod zahazovat. Garbage collector nebo něco podobného tam není.
* offline, ale dá se spustit i na připojené zařízení, je to read-only příkaz
29. 6. 2020, 16:59 editováno autorem komentáře
