Dotaz: Identifikace poškozených či smazaných souborů v živém systému vůči záloze

[JanM]

Dobré poledne,

rád bych využil vánoční pohody k dořešení pár problémů s archivem fotek, ale nerad bych objevoval Ameriku.

Fotek je mraky a nemám dost diskové kapacity na uchovávání kompletní historie záloh, čili záloha je v mém případě spíše jen datová redundance kvůli náhlým haváriím.

Potíž je, že snadno přijdu o nějaké fotky přepsáním zálohy aktuálním stavem pozměněného archivu: někdy jsou fotky poškozeny nějakou proradnou aplikací, někdy může být zdrojem hw chyba, někdy už není podporován formát obrázku a v neposlední řadě ji může smazat sám uživatel.

Zatím to vidím na nějaký skript: udržující databázi náhledů všech obrázků a generující seznam "zmizelých" souborů či "nefunkčních" datových formátů (výstup buď HTML nebo jen uložení do dočasného adresáře). Skript by mohl být spouštěn cronem + shrnutí problémů emailem.

Neexistuje něco takového? Nebo problém (ne)řešíte jinak?

---

---

Odpovědi

[Franta]

rdiff-backup dělá rozdílové zálohy

[JanM]

V tom není problém - i rozdílové zálohy časem rostou. (Používám ZFS snapshoty.)

Teoreticky vzato by archív fotek mohl být dostatečně "neměnný", v mém případě však není: fotky popisuji až dodatečně (geolokace, štítky, přejmenování) a metadata udržuji nejen v databázi digiKamu, ale i přímo v JPEG/TIFF/PNG [1]. Pouze RAW soubory nechávám beze změn. Navíc pracuju i s hodně velkými soubory (gigapixel pano, hdr).

[1] Mám pro to své důvody, což je zde off-topic.

[HrabalVojta]

Tak samozřejmě můžete mazat starší zálohy. Rdiff backup to umí. Příklad: Vytvoříte novou každých 14 dní a zároveň mazání záloh starších než 3 měsíce ... takže pokud měníte jen metadata tak se velikost udržuje cca stabilní.

[JanM]

Zřejmě jsem se špatně vyjádřil: pokud nějaký uživatel smaže fotku či aplikace soubor poškodí (mám už pár JPEGů s nulovou velikostí z devadesátých let), tak na to příjdu více méně náhodně, klidně až za několik let.

Takže být průběžně informován o potenciálním problému je IMHO lepší strategie, než držet všechny zálohy (nebo alespoň občasné zálohy) za celou historii archivu a pak v nich vyhledávat.

V každém případě bych mohl analyzovat jen výstup z rsync --dry-run namísto procházení celého archivu vlastním skriptem.

[Šangala]

cron + find + md5sum (sha1sum).
Kdesi, z trochu jiného důvodu mám, paralelní strukturu, vše stejné jen soubory jsou .md5 a v každém je uložena md5 daného filesu (fotky).
Pak stačí jen strukturu .md5 procházet a kontrolovat existenci jpeg-ů a shodu md5-ky, a případně projít i obráceně.
Taková paralelní struktura mi zabírá 42MiB pro 22GiB fotek (9400ks) - není to mnoho - vím, jen pro poměr.
Při vysokém stupni paranoi si můžete ještě uchovat 1× md5-ku všech md5-tek, případně několik ze daných struktur (vrcholových adresářů).

[host]

zdravim, toto vidim na pouzitie DMS systemu, napr. knowledgetree.com(je aj community verzia) alebo aj http://gallery.menalto.com/. Obidva vedia generovat nahlady a vedia spravovat verzie suborov.

[JanM]

Pro správu fotek používám digiKam (předtím MaPiVi) a měnit způsob organizace archivu je PITA, které bych se rád po dobu mnoha dalších pětiletek vyhnul. Takže to spíše vidím pouze na jednoúčelovou nadstavbu nad existujícím souborovým systémem.