Archivierung ? riesige Datenmengen!

>Behaltet ihr alle Bilder von einem shooting?
ich behalte alles und ziehe regelmaessige backups. festplatten sind billig.


momentan habe ich 700GB raw-bilder in dreifacher ausfuehrung aus unterschiedlichen datentraegern gespeichert. na und? selbst flickr hat in der pro version endlosen speicherplatz fuer dich und wenn es wirklich eng wird, gibt es raid und andere loesungen - drobo ist ein gutes beispiel.

mein mbp selbst hat die letzten 1.000 bilder direkt, alles andere hole ich mir via firewire, wenn ich es mal suche.

Was waren die chemischen noch für unkomplizierte Zeiten...

na da hast dann ordner und kisten voll mit bildern

ich sortiere alles auf hd - bzw mehreren... hab die ganze zeit via time machine (ich liebe meinen mac) immer wieder sicherungen erstellt bis ich mir nun ein western digital my-book gekauft hab - 2TB - gespiegelt ergibt das 1TB speicher... da kommt alles wichtige drauf - das gute ist dass es das ganze auch als netzlaufwerk gibt...

Das stimmt schon, aber genau deshalb haben sich die Mengen auch in Grenzen gehalten.

erzaehl das mal meinen fingerkuppen. t-max developer hat mir damals immer monatelang die ganzen haende verschrubbelt. ich habe die (farb-) dunkellkammer geliebt, die meisten richtig grossen prints sind aber mittlerweile nicht mehr vorhanden.

Ich sage ja nicht, das "früher" alles besser war.
Nur macht mir ein Hobby keinen Spaß mehr wenn ich in der Flut der Produktion versinke.

2 mal auf ner festplatte und die ganzen bilder bis mitte 2008 auch noch doppelt auf cd, was allerdings irgendwann ins geld geht, aber was zu verschmerzen ist... das größere problem ist das man irgendwann nur noch alles mit cds voll stehend hat...

@*******rfun: Interessantes Thema!

Etwas Brainstorming:

Wenn wir "Das Archiv" zunächst als Abstraktum stehen lassen
("irgendetwas in das irgendwas irgendwann irgendwie hineingelangt"), so haben wir bislang u.a. drei Sichten auf "Das Archiv"

1) Eine Prozessbasierte

"Ich kopiere meine Daten von der Kamera auf Storage ABC, da bearbeite ich sie und danach... und danach ..."

2) Eine Logikbasierte

"Ich benenne Dateien auf diese und jene Weise und erzeuge eine Struktur S."

3) Eine Physikalische

"Ich nutze RAID/SAN etc"
"Ich brenne die Daten auf CD/DVD etc und lagere die Medien so-und-so"

---

Das sind alles valide und sinnvolle Sichtweisen auf das System, aber zur funktionalen Beschreibung fehlt noch etwas ganz Entscheidendes:

Wenn wir das alles einem Höhlenmenschen ("Ugah" ) erzählen würden, was würde Ugah dann fragen?

Vermutlich würde er fragen: Wozu?

Wenn wir Ugahs Frage in die Sprache der Datentechnik übersetzen, kommt dabei in etwa dies heraus:

"Was soll "Das Archiv" leisten?"

resp.

"Wie würde/sollte der Prozess des Verfügbarmachens von Information aus dem Archiv aussehen?"

---

Anders ausgedrückt, sollten wir sog

"Use Cases"

http://en.wikipedia.org/wiki/Use_case

für das Datenretrieval formulieren.

===

Zum "Wie" fallen auch mir noch ein paar Punkte ein:

1) Jede "Click-Lösung" ist dubios; die Prozesse müssen weitestgehend skriptgesteuert ablaufen. Wenn der Anwender z.B. erst Ordner manuell selektieren muss ist das Auftreten von Fehlern nahezu sicher.

2) Jedes Backup muss validierbar sein; ein physikalischer Vorgang, für den keine validierbaren "Gut" und "Schlecht" Fälle definiert sind ist eine unwägbare Fehlerquelle (Stichwort "Prüfsummen").

3) Auch eine Baumstruktur mit Bilddateien auf der Festplatte ist eine Form eine Datenbank; namentlich eine, die genau eine flache Zuordnung von Attributen (z.B. Erstelldatum) zu Entitäten (Bilddaten) zulässt (UNIX-Links ausser Ansatz gelassen).

Dies kann man auch mit dedizierten Datenbanksystemen erreichen und darüber hinaus noch viel mehr.

Hier fiel der Begriff schon der Begriff "Access"; ich will hier nicht alle DB-Systeme auflisten, aber darauf verweisen, dass manche Hersteller (z.B. Oracle) "Express" resp. "Community" Editions ihrer Produkte anbieten.

4) Eng mit 3) zusammenhängend ist ein Entkoppelung von Produktionsdatums (TP) der Bilder und dem Datum der Archiverstellung (TA).

Bei dem Ansatz von @****YD sehe ich eine umkehrbar eindeutige Abbildung zwischen TP und TA.

Das muss nicht zwingend so sein; wir sollten mal diskutieren inwieweit dies entkoppelt werden könnte.

Bei einer Lösung mittels einer dedizierten Datenbank ergäbe sich solch eine Entkoppelung schon ganz natürlich.

Fraglich ist aber, inwieweit der Anwender noch in der Lage wäre, die dadurch entstehende höhere Komplexität auch zu beherrschen.


Grüsse,

Dungeoneer

Gute Punkte, Dungeoneer!
Von wegen skriptgesteuert: falls es wen interessiert, das hier benennt alle übergebenen Dateien nach <datum>-<originalname> um, wobei das Datum aus dem EXIF-Tag gezogen wird:
Sehr praktisch, mach ich üblicherweise noch zusätzlich zur Ordnerbenamsung mit Datum.

Zur Zeit habe ich auch einen kleinen Fileserver, der regelmäßig auf externe HD gebackupt wird, falls er zum Failserver werden sollte HD ist momentan einfach konkurrenzlos billig, aber denkt dran: wenn der Blitz reinhaut oder jemand sein Bier in den Rechner kippt, ist im Zweifel das ganze schöne RAID auf einmal hin! Deswegen extern, und immer schön abstöpseln.

Bänder sind da schon sicherer, die kann man im Laufwerk lassen und automatisch backupen lassen, aber mittelgroße elektrische Störungen machen ihnen trotzdem nix. Wer richtig viele Daten richtig sicher aufbewahren will, braucht das. Das Laufwerk ist halt erstmal stinkteuer (so ab 400/500 Euro für ein DLT oder AIT), aber dann kosten 100 GB jeweils gerade mal noch etwa einen Zwanziger.

Eine ordentliche Datenbank ist dafür sicher was feines, allerdings halte ich ausgerechnet Access für die Antithese zur sicheren Archivierung. Nicht nur dass die "Datenbanken" über 10.000 Einträgen gern mal zu zerbröseln anfangen, das ist auch noch ein Format, wo man wieder auf spezielle Software angewiesen ist. Ich hab's nocht nicht probiert, aber MySQL mit CSV-Tables klingt interessant für sowas. Ist zwar nicht das schnellste, reicht für übliche Fotosammlungen aber allemal, und v.a. kann man die Dateien zur Not auch noch mit einem Texteditor von der Platte kratzen. Wär nicht das erste Mal, dass ich das brauche

Für unser Noch-Abstraktum "Das Archiv" können wir jetzt wir jetzt noch eine (vlt generische resp. Meta-)Klasse "Transaktion" einführen.

"Transaktion" sei hier auf einem hohen Abstraktionsniveau angesiedelt und nicht gleichbedeutend mit einer Transaktion im Datenbank/SQL-Sinne ("begin...commit/rollback"); sondern ein Oberbegriff für JEDE Manipulation "Des Archives"

Das Skript von @******min wäre ein Exemplar von "Transaktion".

An "Transaktion" können wir zwei Forderungen stellen

1) "Atomizität" - "Ganz oder gar nicht"
Wenn eine Transaktion fehlschlägt, dann ist der Ausgangszustand der weiterhin gültige; Zwischenergebnisse werden verworfen.
Dafür muss der Ausgangszustand bis zum Abschluss der Transaktion erhalten bleiben.

Bezogen auf das Skript hiesse das, dass nicht mit "mv" ("move") gearbeitet wird sondern z.B. mit

"cp" ("copy")

(tar/cat etc gingen auch)

und nachfolgend EINEM rm ("del") auf den gesamten Ausgangsentitäten.

2) Redundanz

Der Anfangszustand einer Transaktion muss jederzeit mindest aus dem Anfangszustand der vorhergehenden Transaktion restaurierbar sein.

Beispiel:

Bilder auf Kamera/Stick/Wherever =Tr1=> Bilder auf HD =Tr2=> Umbenannte Bilder auf HD

Zumindest bevor Tr2 nicht KOMPLETT abgeschlossen ist, dürften die Bilder auf dem Ausgangsmedium nicht gelöscht werden.

"Zumindest" steht da, weil nach Tr2 die Daten sich noch nicht auf eine sekundären Medium befinden; haute nach Tr2 der Blitz/das umgestossene Bier etc in den Rechner wären die Bilder verloren, wenn das Original gelöscht wäre!

Wir müssen also bei der Gewährleistung von Redundanz auch die Verteilung auf Medien berücksichtigen.

===

@******min

Bei der CSV-Engine von MySQL würde ich mir Sorgen über das Encoding machen; wir behandeln hier ja "BLOB"s.

Wenn man den BLOB nicht in der DB haben will, gibt es z.B die Möglichkeit, nur eine Referenz auf eine Entität im Dateisystem in der DB zu speichern.

Ich selbst mache das allerdings anders; wir arbeiten mit PostgreSQL und Oracle und legen "BLOBS" und "CLOBS" direkt in der DB ab.

"Access" ist in der Tat ein DB-System, das für solch kritische Anwendungen nicht geeignet ist; MS selbst empfiehlt den Einsatz von MS SQL Server.

Access ist eben KEIN generisches Client/Server-System sondern kann C/S nur über Filesharing-Mechanismen gewährleisten...

===

Bevor wir aber eine DB auswählen, brauchen wir ein Mengengerüst!

übrigens, falls es noch nicht erwähnt wurde: die sicherste Variante des DVD backup ist die DVD Ram - sie funktioniert im Grunde wie eine Festplatte.

Angeblich sollen Daten bis zu 30 Jahren auf diesem Medium sicher sein.

Hä? Beim Fotografieren? Wovon sprichst du? Mach doch mal Videofilme, dann weißt du ungefähr, was große Datenmengen sein können. Festplatten gibts doch fast nachgeschmissen. Ich verheddere mich nur in den Dutzenden externen Platten mit unterschiedlichen Netzteilen und Anschlüssen.

Da geht nur USB, dort nur S-ATA, das geht wiederum an dem einen Rechner nicht, nur an dem anderen, usw ...

@***ne
Die Gefahr des "Verhedderns" entsteht nach meiner Erfahrung dadurch, dass die physikalische Verteilung der Daten auf Medien zugleich die logische Struktur bestimmt.

Das ist ein "Bottom-Up"-Ansatz, der Probleme macht.

Deshalb plädiere ich dafür, ZUNÄCHST eine logische Struktur zu definieren und diese dann auf Medien abzubilden.

... dass ich völlig chaotisch und unorganisiert bin. Ein Kreativer eben, ich kümmere mich immer erst um die Technik, wenn es sein muss

Hmm...Hältst die Schöpfer von "Ratatouille" für unkreativ?

SCNR

... aber die Ausführenden schon. Da ich in meiner kleinen Firma alles in Personalunion bin, liegt mein Hauptaugenmerk eben auf den kreativen Prozessen und nicht auf dem, was mich nur ermüdet.
Aber wir sprechen bei mir auch nicht von mehr als grob geschätzt 25 TB, das ist nicht sehr viel im Vergleich zu einer Renderfarm.

Ich glaube, Du unterschätzt wie viele Laien den kreativen Anteil an der Erstellung von Softwaresystemen.

Da taucht nicht Gottes Handschrift an der Wand auf und man muss das nur noch in Code umsetzen, sondern Softwareentwicklung ist ein zutiefst kreativer Prozess.

Aber btw - bei 25 TB solltest Du Dich nicht mehr mit Schnittstelleninkompatibilitäten herumärgern - da braucht es eine Storage-Lösung.

Hallo zusammen,

hier kurz mein Workflow:

CF-Karte mit RAW und kleinsten jpgs auf die Festplatte des PC´s kopieren. Hier logische Sortierungen nach Themen und Datum

Dann Import in Lightroom mit grober Verschlagwortung für ein Shooting oder Event.

Spiegelung des kompletten Bilderverzeichnisses mittels inkrmentellen Backups auf eine Ext Platte

Spiegelung der ext. Platte auf eine 2. ext Platte (anderer Hersteller aber typischerweise gleiche Grösse)

Bearbeitung der Bilder und Export der fertigen in ein Unterverzeichniss von den Rohdaten. Backup der Lightroom Datenbank auf die interne Platte.

Danach wieder Spiegelung der internen Platte auf die 1. Ext. Diese wird dann wieder auf die 2. gespiegelt. (Die LR Datenbankbackups werden auch gesichert)

Somit habe ich immer 3 Kopien. Ich muss sicherlich nicht erwähnen dass die ext Platten nicht angeschlossen sind, wenn Sie nicht benötigt werden.

Wenn die interne Platte voll ist, lösche ich dort die Bilder, und biege den Pfad in Lightroom auf die externe Platte um. Somit habe ich immer alle Bilder im Zugriff wenn ich eine ext. Platte kurz anschliesse.

Von Zeit zu Zeit muss dann natürlich der Satz an ext. Platten gegen grössere Ausgetauscht werden. Was die Möglichkeit bietet die alten Platten dann in einem Archiv abzulegen (Bank - Eltern- ect.)

Habe ich das verständlich gemacht, oder sind noch Fragen? Dann Fragt einfach.

Bis dann . . . Jan

Ein Bekannter von mir hatte neulich einen interessanten Gedanken. Die SD-Cards sind inzwischen so billig, dass man einfach diese selbst als Archiv behalten kann und wenn sie voll sind einfach eine neue SD-karte in die Kamera steckt. Man kommt so immer noch nicht an die Kosten, die früher bei analogem Film entstanden sind, die Karten sind sehr sicher (weil sie ja nicht mehrfach und immer wieder überschrieben werden, was sie übrigens mit der Zeit immer langsamer und untauglicher für den Fotoapparat macht). Man zieht sich nur die Bilder auf den Rechner, die man bearbeiten oder sonstwie haben will.

Ich finde den gedanken nicht ganz verkehrt.

...der SD-Karten liegt zwischen 3 und 7 Jahren, je nach Qualität. Das solltest du bedenken.

Gerade sehe ich mir die neue WD My Book mit 4 TB, also 4000 Gigabyte an. Würde ich nur als USB Variante nehmen.

Reicht Euch das wirklich nicht? Die kann man auch bequem in einen Panzerschrank zur Feuersicherung lagern.

Gruß
Kreuzweise

@ nakedcity: der Gedanke ist wirklich nicht schlecht, doch bei der Lebensdauer würde ein Überdenken nicht schaden...

@ Kreuzweise: Was kostet der/die/das WD My Book mit 4 TB?

Ich habe anderes gehört und das hörte sich überzeugend an, weil es einer sagte, der mit Computen sein Geld verdient. Vielleicht ist die Angabe zur Lebensdauer darauf bezogen, dass man sie immer wieder verwendet.

Aber ich habe mich auf dem Gebiet nicht schlau gemacht.

Zur Lebensdauer bitte einmal Wiki bemühen und unter Flash-Speicher nachschauen, ca. 100.000 Lese/Schreibzyklen sind bei handelsüblichen Cards normal. Auch die Erhaltung ist leider begrenzt, siehe 'Retention'.

Eine 4 TB MyBook liegt zur Zeit bei 600 Euro (Brutto incl. Steuer).
Zwei je 2TB MyBook kosten zusammen 400 Euro Brutto, also noch billiger.

Das sind 10 Eurocent je Gigabyte, ein sensationeller Wert. - Nur als Tipp: Nicht die Ethernet-Variante (die ist zu lahm), nur die USB Variante nehmen!!

@ Kreuzweise 600 Euro klingen fair ls