2007-01-14 23:30:44 +01:00
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
|
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
|
|
|
|
|
<title>SIMBA: Konzept</title>
|
|
|
|
|
<link rel="stylesheet" href="doc.css" type="text/css" />
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
<h1> SIMBA - Simple Integrated Multiplatform Backup and Archive </h1>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h2> Anforderungen </h2>
|
|
|
|
|
<p>
|
|
|
|
|
Die Anforderungen ergeben sich im Wesentlichen aus den
|
|
|
|
|
Erfahrungen am WSR in den letzten Jahren:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
Zwischen Backup und Archiv wird nicht unterschieden. Das mag
|
|
|
|
|
daraus begründet sein, dass unser Archiv bislang einfach aus
|
|
|
|
|
archivierten Backup-Bändern besteht, aber generell ist die
|
|
|
|
|
Unterscheidung weder einfach noch besonders sinnvoll: Es ist
|
|
|
|
|
egal, ob eine File-Version, die früher einmal existiert hat,
|
|
|
|
|
nun nicht mehr existiert, weil sie absichtlich durch eine
|
|
|
|
|
neuere ersetzt wurde, absichtlich gelöscht wurde, oder durch
|
|
|
|
|
einen (Hardware-, Software- oder Benutzer-)Fehler verloren
|
|
|
|
|
gegangen ist. In jedem Fall will man sie wiederherstellen
|
|
|
|
|
können.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Bei weitem der häufigste Fall, für den ein
|
|
|
|
|
Backup/Archiv-System benötigt wird, ist das Wiederherstellen
|
|
|
|
|
von Fileversionen von vor wenigen Tagen. Das muss schnell und
|
|
|
|
|
einfach funktionieren und sollte vom Benutzer selbst
|
|
|
|
|
durchgeführt werden können.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Seltener, aber auch immer wieder, werden alte Filebestände
|
|
|
|
|
benötigt, häufig mehrere Jahre alt, und Metadaten (Filenamen,
|
|
|
|
|
Zeitpunkt, zu dem die Files existiert haben) sind nicht immer
|
|
|
|
|
vollständig bekannt. Das muss weniger schnell gehen, kann
|
|
|
|
|
Eingreifen des Admins erfordern, wichtig sind aber gute
|
|
|
|
|
Suchmöglichkeiten.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Idealerweise sollte jede Fileversion, die jemals existiert
|
|
|
|
|
hat, archiviert werden. Dieses Ideal ist wahrscheinlich nicht
|
|
|
|
|
erreichbar, aber zumindest Fileversionen, die über 24-48
|
|
|
|
|
Stunden existiert haben, sollten wieder auffindbar sein.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Das System soll einfach sein. Ich habe eine eine tiefsitzende
|
|
|
|
|
Abneigung gegen Systeme, die ich nicht verstehe, insbesondere
|
|
|
|
|
dann, wenn ich ihnen wichtige Daten anvertraue, und dafür
|
|
|
|
|
verantwortlich bin, diese Daten auch wieder rauszubekommen.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Das System muss mit Datenmengen im Terabyte-Bereich zurecht
|
|
|
|
|
kommen.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Das System muss die Performance aktueller Hardware ausnützen
|
|
|
|
|
können.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Es sollte vermieden werden, unveränderte Daten immer wieder zu
|
|
|
|
|
archivieren.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
"Ein Band ist kein Band." Bänder sind nicht extrem zuverlässig,
|
|
|
|
|
insbesondere, wenn sie lange aufbewahrt werden. Daten sollen
|
|
|
|
|
daher redundant archiviert werden können.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Integrationsmöglichkeit für Datenbanken und andere
|
|
|
|
|
Datenquellen, die nicht einfach durch Kopieren einzelner Files
|
|
|
|
|
gesichert werden können.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
Nicht benötigt werden folgende Features:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
Standortübergreifende Backups über langsame Leitungen.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Verschlüsselte Backups.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h2> Architektur </h2>
|
|
|
|
|
<div>
|
|
|
|
|
<img src="arch.png" alt="Deployment und Datenfluss" />
|
|
|
|
|
</div>
|
|
|
|
|
<p>
|
|
|
|
|
Das System besteht aus mehreren "Agents", die jeweils bestimmte
|
|
|
|
|
Aufgaben haben. Die Abbildung zeigt einen Client (d.h., ein
|
|
|
|
|
System, von dem Backups erstellt werden sollen) und einen
|
|
|
|
|
Backup-Server, der die Backups verwaltet.
|
|
|
|
|
</p>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h3> Collection Agent </h3>
|
|
|
|
|
<p>
|
|
|
|
|
Die Zentrale Komponente bildet der "Collection Agent", der in
|
|
|
|
|
regelmäßigen Abständen (typischerweise täglich), Kontakt zu
|
|
|
|
|
den Clients aufnimmt, den aktuellen Filebestand festellt, neue
|
|
|
|
|
bzw. geänderte Files vom Client anfordert und im FS Cache
|
|
|
|
|
sowie im Catalog speichert.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Der FS Cache hat die von
|
|
|
|
|
<a href="http://www.hjp.at/programs/rsync-snapshot/index.en.html">rsync-snapshot</a>
|
|
|
|
|
bekannte Struktur:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
Ein Directory für jeden Zeitpunkt, an dem ein Backup begonnen
|
|
|
|
|
wurde.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Darunter ein Directory für jeden Client
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Darunter die gesamte Directorystruktur des Clients. Files
|
|
|
|
|
haben die selben Metadaten (insbesondere Owner und
|
|
|
|
|
Permissions) wie das File am Client), Files, die sich seit dem
|
|
|
|
|
letzten Backup nicht geändert haben, sind Hardlinks auf das
|
|
|
|
|
bestehende File.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
Da jeder Subtree des FS Cache eine vollständige Kopie des
|
|
|
|
|
entsprechenden Subtrees am Client ist, kann der FS Cache
|
|
|
|
|
einfach über Samba oder ein anderes Netzwerk-Filesystem
|
|
|
|
|
read-only export werden. Restores erfolgen einfach durch
|
|
|
|
|
Kopieren der Files auf den Client.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Der Catalog enthält die Metadaten aller Files in einer
|
|
|
|
|
relationalen Datenbank. Das dient einerseits der schnelleren
|
|
|
|
|
Suche, andererseits dazu, Informationen über bereits auf Band
|
|
|
|
|
ausgelagerte Dateien zu halten, die nicht mehr im FS Cache
|
|
|
|
|
vorhanden sind.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h3> Disk Agent </h3>
|
|
|
|
|
<p>
|
|
|
|
|
Der Disk Agent muss auf jedem Client installiert werden. Er
|
|
|
|
|
dient dazu, Informationen über das lokale Filesystem des
|
|
|
|
|
Clients an den Collection Agent zu übertragen. Im wesentlichen
|
|
|
|
|
sind das:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li> ein rekursives Listing eines Directories samt Metadaten </li>
|
|
|
|
|
<li> Metadaten und Inhalt eines bestimmten Files </li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
Der Disk-Agent kann konfiguriert werden, dass er bestimmte
|
|
|
|
|
Directories, von denen kein Backup gewünscht ist (z.B. /proc
|
|
|
|
|
und /sys auf Linux-Systemen, aber auch z.B. Directories mit
|
|
|
|
|
Datenbankfiles) ausspart.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Im aktuellen Prototyp wird der DA über SSH gestartet, die
|
|
|
|
|
Authentifikation erfolgt über Public-Keys. Sollte sich das als
|
|
|
|
|
zu langsam erweisen, kann Agent auch über eine "nackte"
|
|
|
|
|
TCP-Verbindung kommunizieren, die dafür notwendige
|
|
|
|
|
Authentifikation ist aber im aktuellen Prototyp noch nicht
|
|
|
|
|
implementiert.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Directorylistings und Filedaten werden über unterschiedliche
|
|
|
|
|
Verbindungen übertragen, was effektives Streaming erleichtert.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Der Disk-Agent übersetzt systemspezifische Daten in ein
|
|
|
|
|
"allgemeines" Format. Z.B. werden Filenamen vom lokalen
|
|
|
|
|
Encoding nach UTF-8 übersetzt, und ACLs werden im
|
|
|
|
|
POSIX-Textformat dargestellt.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Es wäre möglich, statt eines Disk-Agents, der auf ein
|
|
|
|
|
Filesystem zugreift, einen zu implementieren, der beliebige
|
|
|
|
|
andere Daten (Datenbanken, etc.) exportiert.
|
|
|
|
|
Z.B. könnte ein Disk-Agent für Online-Backups einer
|
2007-01-15 17:30:31 +01:00
|
|
|
Oracle-Datenbank folgendes Interface implementieren (bitte das
|
|
|
|
|
als Beispiel zu verstehen, bei Oracle würde man
|
|
|
|
|
wahrscheinlich eher RMAN verwenden):
|
2007-01-14 23:30:44 +01:00
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
Ein Directory pro Tablespace mit einem Subdirectory pro
|
|
|
|
|
Datafile und je einem Start/Ende-Markerfile.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Durch Zugriff auf das Start/Ende-Markerfile wird der
|
|
|
|
|
jeweilige Tablespace in den Backup-Modus bzw. wieder aktiv
|
|
|
|
|
gesetzt.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Jedes Datafile wird durch ein Directory von Files
|
|
|
|
|
repräsentiert, die Teile des Datafiles abbilden. Für jeden
|
|
|
|
|
Teil wird ein eigenes Last-Modified-Datum verwaltet.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Archive-Logs werden als je ein File dargestellt.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Der Collector-Agent sieht nur eine einfache
|
|
|
|
|
Directory-Struktur, die er einfach rekursiv durchgeht,
|
|
|
|
|
wodurch er den Disk-Agent dazu veranlasst die jeweil
|
|
|
|
|
richtigen Tablespaces in den Backup-Modus zu schalten.
|
|
|
|
|
Nur Teile von Datenfiles, die sich geändert haben, müssen
|
|
|
|
|
über das Netz übertragen und auf Band geschrieben werden.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
In diesem Fall
|
|
|
|
|
ist das einfache Restore über ein Netzwerkfilesystem natürlich
|
|
|
|
|
nicht möglich.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h3> Media Agent </h3>
|
|
|
|
|
<p>
|
|
|
|
|
Der Media Agent dient dazu, Files auf Bänder (oder andere
|
|
|
|
|
Wechselmedien) auszulagern.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Er liest Daten über den aktuellen Stand aus dem Catalog,
|
|
|
|
|
bestimmt anhand seines Regelwerks, welche Files auf welches
|
|
|
|
|
Band geschrieben werden müssen, und führt das durch.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Aus Performance-Gründen werden Files nicht direkt aus dem
|
|
|
|
|
FS Cache auf Band kopiert. Speziell bei vielen kleinen Files
|
|
|
|
|
wäre so nicht sicherzustellen, dass die zum Streamen
|
|
|
|
|
erforderliche Transferrate erreicht wird. Statt dessen werden
|
|
|
|
|
in der Media Queue Files sinnvoller Größe (1GB dürfte
|
|
|
|
|
bauchgefühlmäßig für LTO-3 angemessen sein) im
|
|
|
|
|
Standard-PAX-Format erzeugt. Diese Files werden dann 1:1 auf
|
|
|
|
|
Band kopiert. Wahrscheinlich ist es sinnvoll, für die Media
|
|
|
|
|
Queue eine eigene Disk (bzw. ein RAID-1-Paar) zu reservieren.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Der Media Agent besteht aus zumindest zwei Prozessen mit
|
|
|
|
|
unterschiedlichen Aufgaben. Wahrscheinlich ist es sinnvoll,
|
|
|
|
|
ihn in zwei Programme zu splitten ("Archiving Agent" schreibt
|
|
|
|
|
in die Media Queue, "Media Agent" kopiert von dort auf
|
|
|
|
|
Wechselmedium).
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
|
|
|
|
<h2> Auslagerungsregeln </h2>
|
|
|
|
|
<p>
|
|
|
|
|
Prinzipiell können die Auslagerungsregeln beliebig komplex
|
|
|
|
|
werden, wobei folgende Daten zur Verfügung stehen:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li> Die Metadaten aller Fileversionen. </li>
|
|
|
|
|
<li> Die Zuordnung von Fileversionen zu Files </li>
|
|
|
|
|
<li> Ob eine Fileversion sich auf einem Band befindet, und wenn
|
|
|
|
|
ja, auf welchem </li>
|
|
|
|
|
<li> Eine Zuordnung von Bändern zu Pools </li>
|
|
|
|
|
<li> Ob das Band im Laufwerk, im Bandroboter, on-site oder off-site ist.</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
Folgende Regeln könnten unsere aktuellen Bedürfnisse abdecken:
|
|
|
|
|
</p>
|
|
|
|
|
<div class="section">
|
2007-01-15 17:30:31 +01:00
|
|
|
<h3> Archiv </h3>
|
2007-01-14 23:30:44 +01:00
|
|
|
<p>
|
|
|
|
|
Das Archiv dient dazu, alle Files, für die das sinnvoll ist
|
|
|
|
|
(in erster Näherung alle außer Oracle-Datenbanken,
|
|
|
|
|
tmp-Directories, etc.), "ewig" aufzubewahren. Das kann wie
|
|
|
|
|
folgt erreicht werden:
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Erstelle eine Liste aller Files im aktuellen FS Cache.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Exkludiere ev. Files, die nicht archiviert werden sollen
|
|
|
|
|
(Anm.: Die meisten solchen Files sind vermutlich gar nicht im
|
|
|
|
|
FS Cache, da sie bereits vom DA ausgeschlossen werden können).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Exkludiere ev. Files, die nur während eines CA-Runs existiert
|
|
|
|
|
haben (wahrscheinlich temporäre Files).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Bestimme alle Fileversionen, die noch nicht auf Band gesichert
|
|
|
|
|
wurden.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Wenn sich alle existierenden Fileversionen am gleichen Band
|
|
|
|
|
befinden, aber nicht auf dem Band, das gerade geschrieben
|
|
|
|
|
werden soll, selektiere auch die aktuelle Version.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
2007-01-15 17:30:31 +01:00
|
|
|
<h3> Offsite-Backup für Disaster-Recovery </h3>
|
2007-01-14 23:30:44 +01:00
|
|
|
<p>
|
|
|
|
|
Ein volles Backup sollte sich off-site befinden, um im Fall
|
|
|
|
|
eines Komplettausfalls ein Ersatzrechenzentrum aufbauen zu
|
|
|
|
|
können. Austausch erfolgt (derzeit) wöchentlich.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Erstelle eine Liste aller Files im aktuellen FS Cache.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Exkludiere ev. Files, die für ein Offsite-Backup nicht
|
|
|
|
|
benötigt werden.
|
|
|
|
|
(Anm.: Das ist gefährlich - das Offsite-Backup wird nicht
|
|
|
|
|
regelmäßig getestet, und wenn im Ernstfall wichtige Files
|
|
|
|
|
fehlen, hat man ein Problem).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Bestimme die aktuelle Fileversion, aber nur wenn diese
|
|
|
|
|
noch nicht auf ein Band in diesem Pool gesichert wurde, oder
|
|
|
|
|
wenn sie sich auf einem Band befindet, das recycelt werden
|
|
|
|
|
soll.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Man kann entweder immer das älteste Band, das sich off-site
|
|
|
|
|
befindet, zum Recyclen markieren, oder einen intelligenteren
|
|
|
|
|
Algorithmus verwenden - z.B. das Band, auf dem sich die
|
|
|
|
|
wenigsten noch-aktuellen Fileversionen befinden.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="section">
|
2007-01-15 17:30:31 +01:00
|
|
|
<h3> Datenbank-Backups </h3>
|
2007-01-14 23:30:44 +01:00
|
|
|
<p>
|
2007-01-15 16:49:43 +01:00
|
|
|
Datenbank-Backups in Form von Datenfiles sind hauptsächlich
|
|
|
|
|
für Disaster-Recovery und zum Clonen einer Datenbank für
|
|
|
|
|
Migrationstest sinnvoll. Ein älteres Datenbank-Backup samt
|
|
|
|
|
Software sollte sich restoren lassen, sofern die
|
|
|
|
|
Datenbank-Software auf der aktuellen Hardware/OS-Kombination
|
|
|
|
|
noch läuft. Wegen des relativ hohen Aufwands wird das nur
|
|
|
|
|
in Notfällen gemacht. Die aktuelle Backup/Archiv-Strategie
|
|
|
|
|
könnte einfach weiterverwendet werden:
|
2007-01-14 23:30:44 +01:00
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Erstelle eine Liste der aktuellen Fileversionen der
|
|
|
|
|
entsprechenden Datenbank.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Jeder Pool enthält eine fixe Anzahl von Bändern, das jeweils
|
2007-01-15 16:49:43 +01:00
|
|
|
älteste wird recycelt. Ein Band pro Quartal wird in den
|
|
|
|
|
Archiv-Pool verschoben.
|
2007-01-14 23:30:44 +01:00
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
2007-01-15 17:40:26 +01:00
|
|
|
<div class="section">
|
2007-01-15 17:30:31 +01:00
|
|
|
<h2>Mengengerüst</h2>
|
|
|
|
|
<p>
|
|
|
|
|
Filesystem-Backups: Die Filesystembackups benötigen derzeit ca.
|
|
|
|
|
50-100 GB an täglichen Incrementals (Domino-Server nicht
|
|
|
|
|
eingerechnet), ca. 1-2 Wochen sollten sich also auf einem
|
|
|
|
|
LTO-3-Band ausgehen. D.h., beim derzeitigen Datenaufkommen muss
|
|
|
|
|
mit 2-4 Archivbändern pro Monat gerechnet werden (derzeit: 11
|
|
|
|
|
LTO-1-Bänder).
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Für Lotus Notes müsste eine geeignete Strategie
|
|
|
|
|
gefunden werden, täglich die Datenbankfiles zu archivieren ist
|
|
|
|
|
sicherlich sinnlos. Mehr als ein Band pro Monat sollten wir
|
|
|
|
|
eigentlich nicht brauchen.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Bei Datenbanken hängt der Verbrauch stark von der
|
|
|
|
|
Archivierungsstrategie und Nutzung ab. Bei Online-Sicherung
|
|
|
|
|
aller Archive-Logs habe ich mal vor längerer Zeit 1700 GB (also
|
|
|
|
|
ca. 2 Bänder) pro Monat geschätzt. Wenn wir beim Quartalsmäßigen
|
|
|
|
|
Backup bleiben, ließe sich das auf 1 Band/Quartal reduzieren.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Insgesamt sollten wir beim aktuellen Datenaufkommen mit ca. 6
|
|
|
|
|
Bändern pro Monat für's Archiv auskommen. Laufende Kosten ca. €
|
|
|
|
|
400 / Monat? (+ Strom, Arbeit, etc.)
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Für die Bänder in der Wollzeile brauchen wir einen Pool fixer
|
|
|
|
|
Größe, der regelmäßig recycelt wird. 3 TB sollten auf 4 Bändern
|
|
|
|
|
Platz haben, u.U. möchte man mehr Bänder zur einfacheren
|
|
|
|
|
Organisation.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
2007-01-14 23:30:44 +01:00
|
|
|
</body>
|
|
|
|
|
</html>
|
