Langzeitarchivierung von Produktionsdaten

[Thomas Wildgruber]

Hi Group,

wir müssen eine "Archivreform" bei uns durchführen, unser derzeitiges ist
zu zeitintensiv und für die menge der Daten nicht mehr zeitgemäß. Derzeit
lagern wir Produktionsdaten nach Abschluß auf DVDs aus, haben aber noch
Altbestände zurück bis in PD und MO Zeiten. Das ist eine tickende
Zeitbombe.

Was wir jetzt suchen würden, wäre ein System wo jeder Benutzer in der Lage
ist seine Daten einfach (zB durch Drag & Drop auf ein dediziertes
auszulagern und bei Bedarf auch wieder zurückzuholen. Die einzige
Vorraussetzung die ich jetzt sehe wäre, dass die Daten nach dem auslagern
zwar noch gelesen aber nicht mehr verändert werden können (read-only). Das
ist bei konventionellen Systemen erstmal gar nicht so einfach, denn wenn er
auf ein Volume Daten schreiben kann, darf er sie auch wieder zB löschen.

Ein naiver Gedanke zur Lösung des Problems wäre zB ein Skript welches
regelmäßig die Daten auf read-only setzt aber wirklich ausgereift scheint
mir das nicht zu sein.

Hinzu kommt noch, dass hier letztlich neben einen Nearline-Bereich (die
Daten liegen noch auf einem Server im Filesystem) langfristig auch ein
Offline-bereich eingeführt werden müsste (Die Daten zB auf Bänder
auszulagern). An dieser Stelle wird das zurückholen der Daten für den User
schon schwieriger, denn er müsste entweder aktiv ein Band einlegen oder
zumindest die Software des Loaders bedienen können. Fazit: Der User
bräuchte aktiven Zugang zum System und das kann langfristig auch nicht das
Gelbe vom Ei sein.

Schön wäre demnach ein System, welches den Content selbst verwaltet, egal
ob die Daten jetzt noch im Nearline-Bereich oder schon im Offline-Bereich
sind. Ein Zugang über zB ein simples und plattformunabhängiges Webinterface
wäre da sicher eine ideale Lösung. BTW: Die Hauptplattform von der die
Daten kommen wäre Mac OSX, es muss aber auch mit Windows (7) gerechnet
werden.

Zuletzt stellt sich noch die Frage wie man das Archiv dann sichert und
gegen Totalverlust der Daten schützt. Ins konventionelle Backup
(Retrospect) kann ich das Archiv nicht auch noch integrieren, dass würde
den finanziellen und vermutlich auch sinnvollen Rahmen sprengen. Das
Backupsystem als Archivsystem kann ich auch schon deshalb nicht nutzen,
weil die Benutzer Zugang zum System haben müssten, welcher ihnen zuviele
Möglichkeiten bietet Fehler zu machen.

Das Datenvolumen des bestehenden Archivs beträgt derzeit ca. 8 bis 10 TB,
gleiches Volumen wird schätzungsweise in den nächsten fünf Jahren wieder
anfallen. Demnach sollte das Sizing des Gesamtsystems bei ca. 30 TB liegen,
was aber angesichts des Datenvolumens von zB LTO 5 Bändern nicht so wild
wäre, wie es sich anhört. Die Kompressionsrate im Backup der betroffenen
Daten liegt auch relativ hoch (~70%). Die Geschwindigkeit des System spielt
bei erster Betrachtung erstmal eine untergeordnete Rolle, da täglich nur
überschaubar Daten aus- bzw. wieder eingelagert werden müssen.

Habt ihr da brauchbare Systeme produktiv am Laufen? Wenn Ja, welche und
welche Probleme habt ihr damit. Beim Budget dachte ich an ca. 10K Euro,
habe sie aber noch nicht beantragt.

Thx & Bye Tom

[Goetz Hoffart]

Post by Thomas Wildgruber
Produktionsdaten nach Abschluß auf DVDs aus, haben aber noch
Altbestände zurück bis in PD und MO Zeiten. Das ist eine tickende
Zeitbombe.

Da halte ich eher noch die DVDs als die PDs und MOs für eine Zeitbombe.
Bei denen sterben nur die Laufwerke, nicht die Medien.

Post by Thomas Wildgruber
auszulagern und bei Bedarf auch wieder zurückzuholen. Die einzige
Vorraussetzung die ich jetzt sehe wäre, dass die Daten nach dem auslagern
zwar noch gelesen aber nicht mehr verändert werden können (read-only). Das
ist bei konventionellen Systemen erstmal gar nicht so einfach, denn wenn er
auf ein Volume Daten schreiben kann, darf er sie auch wieder zB löschen.
Ein naiver Gedanke zur Lösung des Problems wäre zB ein Skript welches
regelmäßig die Daten auf read-only setzt aber wirklich ausgereift scheint
mir das nicht zu sein.

Es gibt WORM-Medien - write once, read many, schön bei LTO mit viel
Platz. Aber du willst ja Drag&Drop - vielleicht RDX?

http://www.tandbergdata.com/de/index.cfm/rdx-worm/

Grüße
Götz

[Daniel K®ebs]

Post by Thomas Wildgruber
Habt ihr da brauchbare Systeme produktiv am Laufen?

Im Augenblick archivieren wir noch auf einem Solaris System mit SAM-FS
(Plattencache und zwei Kopien (Platten und LTO 4).

Post by Thomas Wildgruber
Wenn Ja, welche undwelche Probleme habt ihr damit.

Läuft prima, aber ist nicht sehr transparent für die Nutzer.
Außerdem weiß niemand, wie es mit SAM-FS weitergeht :-\

Deshalb steigen wir bald auf das hier um:
<http://www.crossroads.com/Products/StrongBox/>

Post by Thomas Wildgruber
Beim Budget dachte ich an ca. 10K Euro,
habe sie aber noch nicht beantragt.

Du träumst...
Wenn erstmal eine Archivlösung da ist, die jeder Nutzer einfach befüllen
kann, dann ist das Archiv auch in nullkommanix voll.
Denk also dran, gewisse Hürden einzubauen, z.B. die Pflicht zur Eingabe
von Metadaten.
Daniel

[Thomas Wildgruber]

Post by Daniel K®ebs
<http://www.crossroads.com/Products/StrongBox/>

Hab mir grad mal das Overview-PDF angeschaut, muss mir das aber nochmal
genauer anschauen. Danke für den Tipp.

Post by Daniel K®ebs

Post by Thomas Wildgruber
Beim Budget dachte ich an ca. 10K Euro,
habe sie aber noch nicht beantragt.

Du träumst...

Viel ist es nicht aber wenn das Storage und die Tapelibrary mitwachsen
kann, dann würde ja erstmal eine solide Grundausstattung reichen. Also
hardwaretechnisch hab ich schon erweiterbare Systeme mit 5TB
Grundausstattung für weniger Geld aufgestellt und die laufen heute noch.
Die große Unbekannte ist hier wohl die Software. Die Preise zB von
Archiware haben sich mittlerweile zwar ein wenig dem Markt angepasst aber
für die initiale Größe wollen die schon noch was sehen (vor allem die
Lizenz für den Tape-Loader).

Andererseits aber hast du natürlich Recht, wenn du jetzt mit der
Langlebigkeit des Setups argumentierst, welche ja gerade in diesem
Zusammenhang eine elementare Rolle spielt. Da muss ich noch mal in mich
gehen...

Um wieviel Daten gehts bei euch und was habt ihr dafür budgetiert?

Post by Daniel K®ebs
Wenn erstmal eine Archivlösung da ist, die jeder Nutzer einfach befüllen
kann, dann ist das Archiv auch in nullkommanix voll.

Im Prinzip haben sie das jetzt auch schon, sie markieren einfach die
Aufträge die ausgelagert werden können und ein armes Mädel muss die Daten
dann auf DVD brennen. Also bis auf das Mädl kann es für den Rest nicht
bequemer werden... ;-)

Post by Daniel K®ebs
Denk also dran, gewisse Hürden einzubauen, z.B. die Pflicht zur Eingabe
von Metadaten.

Welche Metadaten meinst du? Verschlagwortung der ausgelagerten Daten?
Scheint mir in unserem Workflow nicht notwendig. Jeder Auftrag hat einen
eigenen Ordner, welcher die Auftragsnummer, den Kundennamen und einer
Kurzbeschreibung im Ordner (zB: 12345_Maier_Modekatalog). Dieser Ordner
wird ausgelagert und die DVD-Nummer wird mit der Auftragsnummer zusammen
dokumentiert. Unsere Auftragsdisposition kann aus der Kunden- und
Auftrags-Datenbank die benötigten Daten immer mit der Auftragsnummer
benennen. Bei Bedarf wird der gesamte Vorgang zum Auftrag 12345 wieder
eingelagert werden. Klappt bislang prima, ich sehe keinen Grund an diesem
System etwas zu ändern. Jeder hat es verinnerlicht...

Das Problem liegt allein an dem Wust aus unterschiedlichen Medien der sich
mittlerweile hier schon tausendfach angesammelt hat. Gefunden wird aber
jetzt schon alles, was benötigt wird. Lassen wir jetzt mal so Geschichten
wie das uU etliches redundant ausgelagert wird (zB ein Firmelogo eines
Kunden mit vielen Aufträgen, wird sich in jedem Auftragsordner
wiederfinden), beiseite, dann ist das Konzept als solches okay. Das
Speichermedium als solches ist das eigentliche Problem.

Thx & Bye Tom

[Daniel Krebs]

Post by Thomas Wildgruber

Post by Daniel K®ebs
Denk also dran, gewisse Hürden einzubauen, z.B. die Pflicht zur Eingabe
von Metadaten.

Welche Metadaten meinst du? Verschlagwortung der ausgelagerten Daten?

Es gibt Standards.

Post by Thomas Wildgruber
Scheint mir in unserem Workflow nicht notwendig. Jeder Auftrag hat einen
eigenen Ordner, welcher die Auftragsnummer, den Kundennamen und einer
Kurzbeschreibung im Ordner (zB: 12345_Maier_Modekatalog). Dieser Ordner
wird ausgelagert und die DVD-Nummer wird mit der Auftragsnummer zusammen
dokumentiert. Unsere Auftragsdisposition kann aus der Kunden- und
Auftrags-Datenbank die benötigten Daten immer mit der Auftragsnummer
benennen. Bei Bedarf wird der gesamte Vorgang zum Auftrag 12345 wieder
eingelagert werden. Klappt bislang prima, ich sehe keinen Grund an diesem
System etwas zu ändern. Jeder hat es verinnerlicht...

Bei uns wäre das der vollkommen falsche Ansatz. Hier sind die Metadaten
(Beispiel: http://gis.hsr.ch/wiki/Geo-Metadaten) der Schatz.

Post by Thomas Wildgruber
Das Problem liegt allein an dem Wust aus unterschiedlichen Medien der sich
mittlerweile hier schon tausendfach angesammelt hat. Gefunden wird aber
jetzt schon alles, was benötigt wird. Lassen wir jetzt mal so Geschichten
wie das uU etliches redundant ausgelagert wird (zB ein Firmelogo eines
Kunden mit vielen Aufträgen, wird sich in jedem Auftragsordner
wiederfinden), beiseite, dann ist das Konzept als solches okay. Das
Speichermedium als solches ist das eigentliche Problem.

Dein Ansatz ist langfristig zum Scheitern verurteilt.

Daniel

[Thomas Wildgruber]

Post by Daniel Krebs

[...]

Bei uns wäre das der vollkommen falsche Ansatz. Hier sind die Metadaten
(Beispiel: http://gis.hsr.ch/wiki/Geo-Metadaten) der Schatz.

Sorry aber nach einem Drittel des Artikels habe ich die Reißleine gezogen.
Keine Ahnung mit was ihr euer Geld verdient aber mit uns hat das _nichts_
zu tun...

Post by Daniel Krebs

[...]

Dein Ansatz ist langfristig zum Scheitern verurteilt.

...gut, solche Aussagen ohne weitere Kommentare sind selten der Einstieg in
eine fruchtbare Diskussion. Das hatte ich irgendwie schon mal anders in
Erinnerung...

Bye Tom

[Thomas Kaiser]

Post by Thomas Wildgruber
Was wir jetzt suchen würden, wäre ein System wo jeder Benutzer in der Lage
ist seine Daten einfach (zB durch Drag & Drop auf ein dediziertes
auszulagern und bei Bedarf auch wieder zurückzuholen. Die einzige
Vorraussetzung die ich jetzt sehe wäre, dass die Daten nach dem auslagern
zwar noch gelesen aber nicht mehr verändert werden können (read-only).

Wir setzen bei Kunden im graphischen Gewerbe dafür seit Jahren PresStore
Archive ein: http://www.archiware.de/

Damit kannst Du den Kram auf Disk oder Tape (oder beides) auslagern, ein
Basis-Set an Metadaten als auch bei Medien-Daten die Previews bleiben
online und erlauben Usern später simpel per Browser nach archivierten
Daten zu suchen oder auch ein Rückholen (auf ihre Macs oder
Window-Rechner oder irgendwo ins Filesystem des Servers auf dem
PresStore Archive läuft).

Manuelles Archivieren ist damit ebenfalls per Browser möglich, das Ganze
kann aber auch vollautomatisch eingerichtet werden, weil PresStore bzgl.
Namenskriterien Sachen anstubsen kann als auch vor und nach jedem Job
(egal ob Backup, Archiv oder Synchronize) Skripte automatisch ausführen
lassen kann (nennen sich pre- und postscript).

Bei Yann haben wir das am Weitesten automatisiert. Dort kommt die
Information, daß ein Auftrag archiviert werden darf von den Kontaktern,
die in der Agentur-Software eine Checkbox anklicksen, wenn Job
abgerechnet und bezahlt worden ist. Die Agentursoftware schreibt dann
ein klitzekleines Jobticket, in dem der Pfad zum Auftrag steht, auf den
Server, wo diese Jobtickets dann hotfolderbasiert verarbeitet werden
(dieser Weg ist nötig, weil die User von den Berechtigungen her nicht
direkt an den Ordner-Strukturen rumfummeln können. Der
Hotfolder-Mechanismus darf das aber, da unter privilegiertem Account
laufend).

Das Hotfolder-Skript erzeugt dann einen kryptisch benannten Ordner (auf
dessen Namensschema PresStore Archive konfiguriert ist) und verschiebt
den zu archivierenden Auftrag dort hinein.

Wenn der Admin dann irgendwann entscheidet, wieder einen Archiv-Lauf
durchzuführen, erkennt PresStore anhand des Namensschemas alle in der
Zwischenzeit zu archivierenden Jobs, schiebt diese ins Archiv und synct
diese parallel noch per pre-/postscript auf einen zweiten Server, wo
diese Jobs wieder in ihrer ursprünglichen Struktur herumliegen und
read-only per AFP/SMB allen Usern direkt zur Verfügung stehen (doppelt
gemoppelt wegen Ausfallsicherheit des Ganzen und weil paar User wohl
nicht mit PresStores Web-Interface zurechtkamen, weil sie das nur alle
paar Jahre mal wirklich für einen Restore oder um was aus dem Archiv zu
holen, brauchen). Nach der automatisierten Archivierung (und eben Sync
auf Zweitsystem) wird der Job dann aus den Produktivdaten per postscript
gelöscht.

Unprivilegierte User entscheiden per Checkbox, was archiviert werden
soll (ginge auch per Drag&Drop auf ein Droplet, das dann analog zur
Agentur-Software das Archiv-Jobticket erstellt), Admin entscheidet ab
und an, wann archiviert werden soll, Archivierung läuft dann voll-
automatisch durch, User haben per Browser (oder read-only-Sync-System)
permanent Zugriff auf alle archivierten Daten und können diese im Rahmen
ihrer Berechtigungen wieder zurückholen. Sollte alle Deine Anforderungen
abdecken.

Wir haben damit IIRC mit PresStore 2 gestartet, und Archiware hat in der
Zwischenzeit vieles von dem, was wir initial nur über pre-/postscripts
und cron-jobs an PresStore drangeschraubt hatten, selbst implementiert.
Daher steig ich heute mit PresStore 4 auch nicht mehr so ohne weiteres
durch, wenn ich mir die bei Yann handgeklöppelte Archiv-Infrastruktur so
anschaue. Vieles von dem, was ich da programmiert habe, dürfte heute
obsolet sein, weil mit PresStore-Bordmitteln schon vollständig
abzudecken.

Gruss,

Thomas

[Thomas Kaiser]

Post by Thomas Kaiser

Post by Thomas Wildgruber
Was wir jetzt suchen würden, wäre ein System wo jeder Benutzer in der
Lage ist seine Daten einfach (zB durch Drag & Drop auf ein
dediziertes auszulagern und bei Bedarf auch wieder zurückzuholen. Die
einzige Vorraussetzung die ich jetzt sehe wäre, dass die Daten nach
dem auslagern zwar noch gelesen aber nicht mehr verändert werden
können (read-only).

Wir setzen bei Kunden im graphischen Gewerbe dafür seit Jahren
PresStore Archive ein: http://www.archiware.de/

Da da jetzt schon zwei Anfragen per Mail dazu reinkamen, kurz die
Kostenrechnung hier aufgemacht:

Die Idee dahinter ist, zwei billige ZFS-basierte Filer an verschiedenen
Standorten zu nutzen [1]. Der eine hängt -- ggf. per dedizierter Leitung
-- via iSCSI am Fileserver, auf dem auch PresStore läuft, der andere
steht möglichst weit weg davon und wird irgendwie synchron gehalten
(bspw. per rsync oder ZFS send/receive).

Mittels PresStores Archive-Modul und ein klein wenig Automatismen (bspw.
mittels eines extrem simplen Droplets, das per Drag&Drop Jobtickets
erstellt, welche Jobs archiviert werden sollen, das Anstubsen der
automatischen Archivierung und eines postscript, das die archivierten
Daten anschl. löscht) hat man dann 'ne Lösung, die trotz ggf. sehr
restriktiv gesetzter Zugriffsrechte von jedem User bedienbar ist.
"Bedienbar" im Sinne von: Ein definierter Personenkreis kann die
Archivierung anstubsen, ein -- ggf. davon abweichender -- definierter
Personenkreis erhält die Erlaubnis, im Archiv zu suchen und ggf. zu
rearchivieren. Da PresStore beim Archivieren Metadaten und Previews von
Mediendateien online hält und das Ganze mittels aktueller Browser
funktioniert, geht das Ganze auch 1:1, falls man nicht auf Online-
Storage (permanent erreichbarer iSCSI-Filer) sondern Near- oder gar
Offline-Medien archiviert.

Zu den Preisen: Die "Archive Edition" (AWB540-W) kostet 3.100,- und hat
zus. zum Archiv-Modul (AWB200-W à 1.800,- solo) 'ne unlimitierte
Media-Management- und Storage-Lizenz an Bord. Meist sinniger ist es,
gleich auf die "Professional Edition 48" (AWB411-W à 4.300,-) oder
"Professional XXL Edition" (AWB420-W à 5.400,-) zu setzen, die neben
Archive noch das Backup- und Synchronize-Modul enthalten und im ersten
Fall 48 Media-Slots bzw. 48 TByte Storage umfassen und im zweiten Fall
diesbzgl. unlimitiert sind.

Prontos Vorgabe von 10.000,- ist damit jedenfalls simpel einzuhalten. Ob
ein solches Archiv aber ggf. vorhandene Anforderungen an Revisions-
sicherheit erfüllt, steht auf 'nem anderen Blatt.

Gruss,

Thomas

[1] Ein simpler iSCSI-Filer mit einfacher Redundanz und 12 TByte netto
besteht aus 'nem HP Microserver N40L, 4 x WD4000FYYZ (4 TByte 24/7)
mit FreeNAS. Stückpreis 1.500,- netto. Sinniger wäre aber mehr
Redundanz, d.h. in den N40L noch 'ne SAS-Karte rein, ein externes
SATA-JBOD mit 4 oder 5 Einschüben dran und dann bspw. 8 oder 9
WD30EURS (3 TByte à ca. 120,- netto) nutzen. Das macht dann trotz
doppelter oder dreifacher Redundanz (raidz2/raidz3) und ggf. einer
Hotspare je Filer 15 TByte netto und das für unter 2.000,-

2 Filer, weil der eine per iSCSI am Server hängt und der andere
mindestens in anderem Brandabschnitt stehend, synchronisiert wird.

Wenn man initial mehr Platz braucht, dann greift man halt gleich zu
entsprechenden Gehäusen, die eine entsprechende Anzahl interner
SATA-Einschübe haben. Da gibt's ja Kram für jeden Geschmack bzw.
Geldbeutel und mit den -- aktuell zwar noch recht teuren -- 4 TByte
Platten kriegt man auf 4HE satte 240 TByte brutto ins Rack, siehe
http://eurostor.com/products/raid-sas-host/es-8060-toploader-jbod.html

Und dann muß man halt alle paar Jahre mal neue Filer hinstellen oder
aber die Platten aus einem System rausrupfen und wegparken, dann
verfügbare Platten mit 6/8/10 (?) TByte in einen File stecken, den
anderen Filer ebenfalls an den Server stecken und PresStore die
Datenmigration auf den größeren Filer durchführen lassen, anschl.
den zweiten Filer mit frischen Platten aufrüsten, etc. pp.

[Ralph Boehme]

Post by Thomas Kaiser

Post by Thomas Kaiser

Post by Thomas Wildgruber
Was wir jetzt suchen würden, wäre ein System wo jeder Benutzer in der
Lage ist seine Daten einfach (zB durch Drag & Drop auf ein
dediziertes auszulagern und bei Bedarf auch wieder zurückzuholen. Die
einzige Vorraussetzung die ich jetzt sehe wäre, dass die Daten nach
dem auslagern zwar noch gelesen aber nicht mehr verändert werden
können (read-only).

Wir setzen bei Kunden im graphischen Gewerbe dafür seit Jahren
PresStore Archive ein: http://www.archiware.de/

Da da jetzt schon zwei Anfragen per Mail dazu reinkamen, kurz die
Die Idee dahinter ist, zwei billige ZFS-basierte Filer an verschiedenen
Standorten zu nutzen [1]. Der eine hängt -- ggf. per dedizierter Leitung
-- via iSCSI am Fileserver, auf dem auch PresStore läuft, der andere
steht möglichst weit weg davon und wird irgendwie synchron gehalten
(bspw. per rsync oder ZFS send/receive).

zrep:
<http://www.bolthole.com/solaris/zrep/>

Gruß
-Ralph

[Thomas Wildgruber]

Servus Thomas,

Post by Thomas Kaiser
2 Filer, weil der eine per iSCSI am Server hängt und der andere
mindestens in anderem Brandabschnitt stehend, synchronisiert wird.

Mehrere Brandabschnitte haben wir hier in unserer alten Burg nicht,
deswegen syncen wir ja die Produktionsdaten schon übers Internet an einen
anderen Standort (auch mit Archiware). Ob demnach zwei Filer notwendig bzw.
sinnvoll sind, bleibt mal dahingestellt. Ich muss mal ermitteln wie viele
Daten da täglich ausgelagert werden und ob die Internetleitung das noch
relativ sicher über Nacht wegpacken könnte...

Post by Thomas Kaiser
Und dann muß man halt alle paar Jahre mal neue Filer hinstellen oder
aber die Platten aus einem System rausrupfen und wegparken, dann
verfügbare Platten mit 6/8/10 (?) TByte in einen File stecken, den
anderen Filer ebenfalls an den Server stecken und PresStore die
Datenmigration auf den größeren Filer durchführen lassen, anschl.
den zweiten Filer mit frischen Platten aufrüsten, etc. pp.

Irgendwie scheint mir das Prinzip nur mit Fileservern zu arbeiten etwas
wackelig. ich dachte zwar schon auch an einen Filer (der durchaus ganz
normal im Netzwerk hängen könnte, so viele Daten werden es auch nicht
werden) aber in nächster Instanz dann schon ein Bandlaufwerk dazuhängen.

Ich weiß jetzt nicht wie sich da Archiware bedienen und einrichten lässt
aber der Archivserver (nennen wir ihn mal so) sollte halt relativ frische
Daten noch auf seinem Storage bereit halten (bis zu einer definierten
Anzahl oder Gesamtdateimenge) und dann anfangen das ganze auf Bänder
auzulagern. Anderseits könnte er sogar gleich hergehen und alles was er
auch auf dem Storage liegen hat, gleich auch auf Baänder sichern, dann wäre
auch ein Backup des Archiv Storage vorhanden.

Irgendwann sollte er dann halt hergehen und die Daten auch vom
Archivstorage löschen (wenn halt Platz gebraucht wird) und sichergestellt
sein, dass die Daten alle auch auf Band sind. Wir vermutlich ein Mischmasch
aus Backup und Archiv, zumindest was die Bänder betrifft.

Schön wäre es nun, wenn das für den Anwender transparent ist. D.h. ihm ist
es egal wo die Daten liegen (ob auf dem Storage oder auf einem Band) er
sieht die verfügbaren daten und holt sie sich zurück. Geht schnell, wenn
auf dem Storage, dauert halt ein paar Minuten, wenn schon auf Band. Aber im
Prinzip sollte der benutzer keine Bänder wehcseln müssen. Gut irgendwann
mal, wenn alle Bänder in der Library voll sind und auch Bänder ausgelagert
werden müssen, kann es vorkommen, dass der Benutzer aufgefordert wird Band
xyz einzulegen. Aber unter uns gesagt, eine 24-Slot oder auch 12-Slot LTO-5
Library hat soviel Platz, dass bis die voll ist, eh das gesamte System
ausgetauscht und umgelagert werden muss. AFAIK sind die LTO-Laufwerke bis
zu zwei Generationen abwärts kompatibel, LTO-6 sollte langsam kommen, also
ist eh nicht soviel Zeit bis zum ersten Umlagern. Wenn es fünf Jahre hält,
hat es seinen Dienst erfüllt, alles was drüber geht wird dankenswert
angenommen ;-)

Da jetzt Performance nicht so sehr das Thema ist, muss es auch kein rießig
dimensioniertes RAID-Subsystem, wie unsere Infortrends, sein, sondern ein
Server mit 6 oder 8 Slots (á 2TB) zusammen als RAID 5 (oder 6) mit einer
angeschlossen Tape Library hätte bei meinem naiven Sachverstand eigentlich
schon reichen müssen.

Die Software bzw. Benutzbarkeit (Jeder kann es, plattformunabhängig) und
Fehlertoleranz (ausgelagerte Daten können zwar gelesen aber nicht
überschrieben werden (Bei einem Band eh kein Problem)) wären sicher die
wichtigeren Kriterien. Bei der Preispolitik von Archiware (darauf wird es
vermutlich eh hinaus laufen) wusste ich jetzt nicht so Bescheid aber die
Preise, die du genannt hast sind ganz okay. Ich denke das sollte alles ins
Budget passen und wenn nicht, dann nehmen wir die LTO-Bänder halt aus der
Budgetierung heraus und bestellen die ein paar Tage später seperat ;-)

Also ich denke ich komme auch mit Tape-Library noch in die Nähe meines
Budgets und die Geschichte mit dem zweiten Filer (sollte sie überhaupt
notwendig sein) kann man ja später immer noch etablieren...

BTW: Läuft Archiwarew auf Linux oder Windows?

Thx & Bye Tom

[Thomas Kaiser]

Post by Thomas Wildgruber

Post by Thomas Kaiser
Und dann muß man halt alle paar Jahre mal neue Filer hinstellen
oder aber die Platten aus einem System rausrupfen und wegparken,
dann verfügbare Platten mit 6/8/10 (?) TByte in einen File
stecken, den anderen Filer ebenfalls an den Server stecken und
PresStore die Datenmigration auf den größeren Filer durchführen
lassen, anschl. den zweiten Filer mit frischen Platten aufrüsten,
etc. pp.

Irgendwie scheint mir das Prinzip nur mit Fileservern zu arbeiten
etwas wackelig.

Wahrscheinlich weil Du ausblendest, daß ich von "Filer" schreibe und das
exakte Gegenteil von "Fileserver" meine. Besagte "Filer" werden als
SAN-Device (iSCSI) eingebunden, agieren aus Sicht der Archiv-Software
als VTL (virtuelle Tape Library) und stellen *echte* Datensicherheit
eine Ebene drunter durch ZFS/RAID-Z und Replizierung der ZFS-Snapshots
auf ein zweites Gerät (in anderem Brandabschnitt, d.h. bei Euch eben an
anderem Standort) sicher.

Das sind keine Fileserver, weil kein User jemals irgendwas da drauf
direkt zu Gesicht bekommt und die Archiv-Software auch die archivierten
Daten da drauf in Container-Dateien speichert. Das ist aus Sicht der
User daher komplett read-only, weil das einzige Interface zu diesen
Daten der Web-Browser und die Archiv-Software (PresStore) ist, die
Recherche und Rückholen nur autorisierten Personen über ein definiertes
Interface gestattet.

Post by Thomas Wildgruber
BTW: Läuft Archiwarew auf Linux oder Windows?

Natürlich. Und auf MacOS X und Solaris auch noch. Die Preise, die ich
genannt habe, gelten für die ersteren Plattformen, auf Solaris ist alles
aus irgendeinem seltsamen Grund doppelt so teuer.

Aber das interessiert Dich eigentlich eh alles nicht, denn Dir schwebt
nicht Archivierung vor sondern HSM (hierarchical Storage Management) bei
der irgendeine Art von Logik bzw. Regelwerk Daten von teuren auf
billigen Speicher verdrängt und bei dem Du Teile des FS irgendwann auf
read-only stellst. Außerdem scheinst Du ein Faible für Anachronismen,
konkret LTO, zu haben ;-)

Im Ernst: Das, was Dir vorschwebt, weicht so stark von einem klaren
Archivierungs-Ansatz ab, daß weiteres Diskutieren zwecklos erscheint
(die Einhaltung Deines Budgets auf der HSM-Basis übrigens auch).

Gruss,

Thomas

[Thomas Wildgruber]

Servus Thomas,

Post by Thomas Kaiser
[...]
Wahrscheinlich weil Du ausblendest, daß ich von "Filer" schreibe und das
exakte Gegenteil von "Fileserver" meine. Besagte "Filer" werden als
SAN-Device (iSCSI) eingebunden, agieren aus Sicht der Archiv-Software
als VTL (virtuelle Tape Library) und stellen *echte* Datensicherheit
eine Ebene drunter durch ZFS/RAID-Z und Replizierung der ZFS-Snapshots
auf ein zweites Gerät (in anderem Brandabschnitt, d.h. bei Euch eben an
anderem Standort) sicher.
[...]

Das Thema hat die GL jetzt wohl abgenickt und das Budget vermutlich auch.
Ein wenig habe ich mich mal mit oz Aussage beschäftigt und schon das Thema
ZFS hat uns alle begeistert. Wir haben uns gefragt warum wir das nicht
schon früher eingesetzt haben. So simpel und so praktisch wie das ist. Auch
einen Podcast zu diesem Thema habe ich mir angehört und wenn man dem
glauben schenken darf, scheint das auch noch äusserst robust zu sein.

http://cre.fm/cre049

Beim Thema VTL aber wurde das Eis schon dünner, ausser Marketingaussagen
waren da wenig Infos zu finden. Welche Implementierung würdest du da
vorschlagen oder ist das Bestandteil von Archiware? Ich würde das ja gerne
mal in einem Testsystem durchspielen, um ein Gefühl davon zu bekommen, wie
das am Ende abläuft. Aber ich habe jetzt nur mal das hier gefunden, was
preislich erstmal nicht unattraktiv zu sein scheint und auch als Demo zu
haben wäre, aber...

https://www.cristalink.com/fs/Default.aspx

...das läuft aber unter Windows und ob sich das nicht mit ZFS etwas
spreizt? Getestet habe ich ZFS bislang nur unter Linux (Debian), die
Repository Variante ZFS-Fuse auf einem 32 Bit System und die selbst
kompilierte Variante auf einem 64 Bit System. Die Fuse Geschichten haben ja
nicht gerade den Ruf Rennsemmeln zu sein, kann aber gut sein, dass diese
Aussage mittlerweile überholt ist. Anyway, ZFS unter Windows spuckt im Netz
mehr Fragen als Antworten aus, was mich skeptisch macht...

Da ich das VTL jetzt aber in diesem Zusammenhang zum ersten mal gehört
habe, fehlt mir ein wenig die Phantasie. Wozu brauchts das eigentlich?

Auch die Geschichte mit der Synchronisierung mit dem zweiten Standort hat
durchaus Anklang gefunden aber in diesem Zusammenhang wäre noch zu klären,
wie die Replizierung der ZFS Snapshots an einen zweiten Standort im Detail
auschauen soll? Wir sind über das Internet nur mit 10 MBit angebunden und
die Snapshot Technik in ZFS basiert darauf den aktuellen Stand sofort
einzufrieren, in dem dieser Bereich nicht mehr beschrieben wird und die
weiteren Änderungen am Dateisystem dann anschließend bei Kopien der
gesnaptshoten Blöcke durchgeführt werden, was ZFS ja eh zu machen scheint,
nur das am (erfolgreichen) Ende des Schreibvorgangs dann der originale
Block eben nicht gelöscht wird.

Also was müsste dann zum zweiten Standort synchronisiert werden? Der jetzt
durch den Snapshot eingefrorene Zustand? Das können einige Terrabyte sein.
Oder die darauf folgenden Änderungszyclen? Was den Ausgangszustand aber
immer noch nicht zum zweiten Standort gebracht hat. Wozu überhaupt
Snapshots? Es ändert sich an den Daten ja im Prinzip nichts, ausser das es
mehr und noch mehr Daten werden.

Wäre es da nicht einfacher einfach die am Hauptstandort ausgelagerten
Projekte über Nacht zum zweiten Standort zu syncen? Machen wir ja mit
Teilen der Produktionsdaten jetzt auch schon. Wobei ich aber mit der
Datensicherheit dieses Konzeptes so meine Sorgen hätte. Ein
softwareseitiger Amoklauf oder Fehlbedienung am Hauptstandort betrifft auch
(wahrscheinlich) immer den zweiten Standort, wenn auch mit einem
Zeitversatz von ein paar Stunden. Im bereits vorliegenden Anwendungsfall
ersetzt das Synchronisierungskonzept ja nicht das klassische Backup, es
erfüllt nur eine Kundenanforderung. Anders verhält sich das bei
Langzeit-archivierten Daten (ohne Backup im klassischen Sinne), hier muss
ich nicht nur Redundanz gewährleisten, sondern sicherstellen die Daten in
10 Jahren immer noch zu haben, egal was passiert, ausser beide Standorte
fackeln gemeinsam ab (was unwahrscheinlich ist)...

Bei Archiware wird das Archivierungs-Modul auch nur für BWLer erklärt, ich
kann damit wenig anfangen, zumal mich dann noch die Fußnote...

---snip---
Folgende Integrationen sind bereits für P4’s Archiv Software verfügbar:
Final Cut Server, Canto Cumulus, CatDV, Xinet, Helios
---snap---

...stark irritiert. Wir haben nichts davon.

BTW irritiert: Eine SAN Infrastruktur haben wir auch nicht. Den Filer über
SAN einzubinden, heisst was konkret? Wo einbinden?

Also dein Konzept klingt interessant und ich habe dabei zwar ein gutes
Gefühl aber konkret vorstellen kann ich mir das Zusammenspiel zwischen
Archiware, ZFS, VLT, SAN, Replikation an einen zweiten Standort und
ausreichende Datensicherheit noch nicht...

Thx & Bye Tom

[Hermann Schaefer]

Post by Thomas Wildgruber
Da ich das VTL jetzt aber in diesem Zusammenhang zum ersten mal gehört
habe, fehlt mir ein wenig die Phantasie. Wozu brauchts das eigentlich?

Grob gesagt: Bandlaufwerke sind nett, aber teuer und anfällig. Bandroboter noch
teurer und noch anfälliger. Im Gegensatz dazu sind aber Festplatten inzwischen
so billig, daß man große Datenmengen auf RAID-Systemen günstig wegspeichern
kann. Problem ist aber oft fehlende oder veraltete Sicherungssoftware oder
überhaupt Sicherungssoftware, die auch mal was anderes als Band-Jukeboxes
ansprechen kann. Hier hakt sich nun VTL ein (gibt es btw. auch freie
Linuxvarianten wie mhVTL https://sites.google.com/site/linuxvtl2/) und gaukelt
der Software beliebig große Bandlaufwerke resp. Libraries vor. Typischerweise
ersetzt so ein VTL-iSCSI-Bündel eine zu lahme oder kleine Bandlösung, wobei als
finales Backup immer noch Bandlaufwerke keine so schlechte Lösung sind (Disk to
Disk to Tape). Man definiert lediglich eine neue Tapelibrary in der
Sicherungssoftware und braucht sonst nicht groß was am laufenden System zu
schrauben. Einige Hersteller von Speicherlösungen bieten auch "fertige"
RAID-Systeme an, die nicht nur iSCSI sondern auch VTL beherrschen. Vorher
Kompatibilität abzuklären ist da aber ein Muss.
Als Alternative zu Archiware würde ich btw. noch bru nennen (von Tolis).

Post by Thomas Wildgruber
Wir sind über das Internet nur mit 10 MBit angebunden

Viele lokale Stadtwerke vermieten gegen wenig Geld Glasfaser. Da sind für ein
paar Kilometer oft nur geringe dreistellige Beträge monatlich für Gigbit-Links
zu berappen. Bis zu 10km kosten auch entsprechende GBICs nicht die Welt, da tut
es dann Stangenware von Dlink & Co.

Post by Thomas Wildgruber
BTW irritiert: Eine SAN Infrastruktur haben wir auch nicht. Den Filer über
SAN einzubinden, heisst was konkret? Wo einbinden?

SAN = eigenes getrenntes Netzwerk, meist Gigabit-Ethernet oder Fibrechannel, für
die Speichersysteme. Die Server selbst haben nur noch lokale Bootlaufwerke und
die dicken Speichersysteme werden über Fibrechannel oder iSCSI angebunden.
Vorteil daran: Man kann so was transparent spiegeln, synchen, sichern, .. ohne
daß die Fileserver davon was mitbekommen, z.B. mit den Geräten von FalconStor.
Gut, is aber gut fünfstellig...
Server --> Fibrechannel--> Falconstore ---> zwei gespiegelte Speichersysteme,
die auch an unterschiedlichen Standorten stehen können.
Alternativ sind Geräte von z.B. EMC, NetApp & Co. auch in der Lage, von selbst
Backups auf entfernte Systeme zu fahren. Kostet halt auch Geld (Santricity &
Co.) resp. Lizenzen.
Dieses Speichernetzwerk ist völlig unabhängig vom restliche Hausnetzwerk und hat
damit auch keinerlei Verbindungen (außer vielleicht zur Administration, aber
auch das sollte man anders lösen).

Post by Thomas Wildgruber
Also dein Konzept klingt interessant und ich habe dabei zwar ein gutes
Gefühl aber konkret vorstellen kann ich mir das Zusammenspiel zwischen
Archiware, ZFS, VLT, SAN, Replikation an einen zweiten Standort und
ausreichende Datensicherheit noch nicht...

Guck dir mal an, wie Failover-Systeme für VMware & Co. gebaut werden, findet
sich einiges im Netz.

[Thomas Wildgruber]

Post by Thomas Wildgruber
Da ich das VTL jetzt aber in diesem Zusammenhang zum ersten mal gehört
habe, fehlt mir ein wenig die Phantasie. Wozu brauchts das eigentlich?

[...] Typischerweise
ersetzt so ein VTL-iSCSI-Bündel eine zu lahme oder kleine Bandlösung, wobei als
finales Backup immer noch Bandlaufwerke keine so schlechte Lösung sind (Disk to
Disk to Tape)[...]

Genau das ist doch dann der Punkt, wo das Setup dann teurer wird als ein
klassisches Disk to Tape Backup (Disk to Disk to Tape). Bei Verwendung
einer virtuellen Tape Library auf ein klassisches Band zu verzichten, würde
mir jetzt schon den ein oder anderen Tropfen Angstschweiß auf die Stirn
treiben. Vor allem so lange, diesen Archiv-Server gibts ja praktisch eine
Ewigkeit...

Post by Thomas Wildgruber
Wir sind über das Internet nur mit 10 MBit angebunden

Viele lokale Stadtwerke vermieten gegen wenig Geld Glasfaser. Da sind für ein
paar Kilometer oft nur geringe dreistellige Beträge monatlich für Gigbit-Links
zu berappen. Bis zu 10km kosten auch entsprechende GBICs nicht die Welt, da tut
es dann Stangenware von Dlink & Co.

Negativ, hier in der Wallachei gibt es sowas nicht. Der zweite Standort
bekommt jetzt langsam Glasfaser, bei uns hier - no way. Wir müssen schon
30% mehr für die Standleitung zahlen; Country Area nennt Telekom das
Tarifmodell... ;-)

Bei den 10 MBit wird es bleiben.

Post by Thomas Wildgruber
BTW irritiert: Eine SAN Infrastruktur haben wir auch nicht. Den Filer über
SAN einzubinden, heisst was konkret? Wo einbinden?

SAN = eigenes getrenntes Netzwerk, meist Gigabit-Ethernet oder Fibrechannel, für
die Speichersysteme [...] Man kann so was transparent spiegeln, synchen, sichern, .. ohne
daß die Fileserver davon was mitbekommen, z.B. mit den Geräten von FalconStor.
Gut, is aber gut fünfstellig [...] Dieses Speichernetzwerk ist völlig unabhängig vom restliche Hausnetzwerk und hat
damit auch keinerlei Verbindungen (außer vielleicht zur Administration, aber
auch das sollte man anders lösen).

Der prinzipielle Nutzen von SAN bzw der Unterschied zu NAS war mir schon
klar, ich musste das jetzt erstmal in das hier diskutierte Setup einbauen
und vor allem mit dem Budget in Einklang bringen.

Post by Thomas Wildgruber
Also dein Konzept klingt interessant und ich habe dabei zwar ein gutes
Gefühl aber konkret vorstellen kann ich mir das Zusammenspiel zwischen
Archiware, ZFS, VLT, SAN, Replikation an einen zweiten Standort und
ausreichende Datensicherheit noch nicht...

Guck dir mal an, wie Failover-Systeme für VMware & Co. gebaut werden, findet
sich einiges im Netz.

Jupp Danke, etwas Lektüre könnte jetzt nicht schaden. Ich hab zwar beim
Budgetantrag noch etwas zu den 10K Euro draufgelegt aber so ganz bring ich
das jetzt noch nicht alles unter...

Thx & Bye Tom

[Thomas Wildgruber]

Post by Hermann Schaefer
[...]
Hier hakt sich nun VTL ein (gibt es btw. auch freie
Linuxvarianten wie mhVTL https://sites.google.com/site/linuxvtl2/) und gaukelt
der Software beliebig große Bandlaufwerke resp. Libraries vor.
[...]

Danke für den Tipp, die mhVTL Library wird von Archiware sogar gefunden.
Alle virtuellen Laufwerke und alle virtuellen Tapes werden angezeigt. Das
scheint mir jetzt schon mal eine gute Basis zum Testen zu sein...

Thx & Bye Tom :-)

[Hermann Schaefer]

Post by Thomas Kaiser
2 Filer, weil der eine per iSCSI am Server hängt

Btw.. im Falle Fileserver = Mac kommt noch bissi was für Atto's iSCSI-Treiber
dazu. Oder man versucht 'nen freien ohne Support..

*Appleverfluch*

[Ingo Soetebier]

Post by Thomas Wildgruber
Habt ihr da brauchbare Systeme produktiv am Laufen? Wenn Ja, welche und
welche Probleme habt ihr damit. Beim Budget dachte ich an ca. 10K Euro,
habe sie aber noch nicht beantragt.

Im medizinischen Bereich wird gern FAST LTA eingesetzt für die
Langzeitarchivierung:
http://www.fast-lta.de/de/

Dort müssen die Daten lt. Gesetz immerhin 10 Jahre verfügbar sein.
Die Daten sind über SMB zugreifbar und nach einem Verify auch gegen
Überschreiben geschützt.

Gruß,
Ingo

[Michael Jaeger]

Post by Thomas Wildgruber
Habt ihr da brauchbare Systeme produktiv am Laufen? Wenn Ja, welche und
welche Probleme habt ihr damit. Beim Budget dachte ich an ca. 10K Euro,
habe sie aber noch nicht beantragt.

Kofax Capture. Da langen aber Deine 10 kEUR höchstens für die Software.
Archivierung im Hochsicherheitsrechenzentrum, Auslagerung auf Tapes.

Aber Deine Daten scheinen ja wertlos zu sein, wenn Du so einen Murks
machen willst.



Gruß

Michael

[Thomas Kaiser]

Post by Michael Jaeger

Post by Thomas Wildgruber
Habt ihr da brauchbare Systeme produktiv am Laufen? Wenn Ja, welche
und welche Probleme habt ihr damit. Beim Budget dachte ich an ca. 10K
Euro, habe sie aber noch nicht beantragt.

Kofax Capture. Da langen aber Deine 10 kEUR höchstens für die Software.
Archivierung im Hochsicherheitsrechenzentrum, Auslagerung auf Tapes.
Aber Deine Daten scheinen ja wertlos zu sein, wenn Du so einen Murks
machen willst.

Herrlich unqualifitierte Aussagen, zu denen Du Dich hier herabläßt. :-)

Eine bestimmte Software empfehlen ohne die Ausgangsbedigungen, die
Datenformate und die Workflows zu kennen, ist immer prima. Und weil
Deine Lösung, die mit sehr hoher Wahrscheinlichkeit komplett am Ziel
vorbeischießt bzw. erstmal zu den Anforderungen und Formaten des
graphischen Gewerbes kompatibel gemacht werden müsste, nicht für den
Preis zu haben ist, der dem OP vorschwebt (weil oversized), ist das, was
er vorhat "Murks"? Interessant.

Gruss,

Thomas, steckt grad in einem ähnlichen Projekt, wo mit den Maßstäben der
"großen Rechenzentren-IT" ohne sich die Anforderungen des "Kunden" im
Groben geschweige denn im Detail anzusehen, Lösungen geplant werden, die
am Ende nur die Kombination aus "schlecht" und "teuer" ergeben. Und an
Archivierung hat da kurioserweise noch gar niemand gedacht, weil man
sich mit dem, was der Kunde da eigentlich so macht, noch nie auseinan-
dergesetzt hat. "Viel hilft viel" stimmt nur bedingt.

[Goetz Hoffart]

Post by Thomas Kaiser
"Viel hilft viel" stimmt nur bedingt.

Wieso, stimmt immer.

Fragt sich nur, wem da geholfen wird - dem Kunden oder dem Inhaber oder
dem Shareholder des Systemhauses.

Grüße
Götz

[Thomas Kaiser]

Post by Goetz Hoffart

Post by Thomas Kaiser
"Viel hilft viel" stimmt nur bedingt.

Wieso, stimmt immer.
Fragt sich nur, wem da geholfen wird - dem Kunden oder dem Inhaber
oder dem Shareholder des Systemhauses.

Oder dem Hersteller des anzuschaffenden Systems, der das Konzept für
dieses System selbst schreiben durfte, freilich ohne irgendwelche
Informationen, die für ein vernünftiges Sizing notwendig sind, erhalten
zu haben und daher -- letztlich völlig zu recht -- nur das Nonplusultra
verkaufen kann, denn wenn man den abzulösenden Status Quo nicht kennt,
muß man vom "Schlimmsten" ausgehen. Mei, gibt Schlimmeres als gezwungen
zu werden, das dickste Blech verkaufen zu _müssen_...

Gruss,

Thomas, grad beruflich wieder ausgedehnte Spaziergänge durch Absurdistan
unternehmend...