From 41c7d6b6ed0ba4c1fde1fc7228a7a44aa1a2ab78 Mon Sep 17 00:00:00 2001
From: hjp <hjp@d47eeb7a-11fe-0310-b519-e5a4e12f9765>
Date: Mon, 15 Jan 2007 16:30:31 +0000
Subject: [PATCH] =?UTF-8?q?Mengenger=C3=BCst?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 doc/konzept.html | 45 +++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/doc/konzept.html b/doc/konzept.html
index 5d3d562..e4bd8d6 100644
--- a/doc/konzept.html
+++ b/doc/konzept.html
@@ -189,7 +189,9 @@
 	  Filesystem zugreift, einen zu implementieren, der beliebige
 	  andere Daten (Datenbanken, etc.) exportiert.
 	  Z.B. könnte ein Disk-Agent für Online-Backups einer
-	  Oracle-Datenbank folgendes Interface implementieren:
+	  Oracle-Datenbank folgendes Interface implementieren (bitte das
+	  als Beispiel zu verstehen, bei Oracle würde man
+	  wahrscheinlich eher RMAN verwenden):
 	</p>
 	<ul>
 	  <li>
@@ -273,7 +275,7 @@
 	Folgende Regeln könnten unsere aktuellen Bedürfnisse abdecken:
       </p>
       <div class="section">
-	<h2> Archiv </h2>
+	<h3> Archiv </h3>
 	<p>
 	  Das Archiv dient dazu, alle Files, für die das sinnvoll ist
 	  (in erster Näherung alle außer Oracle-Datenbanken,
@@ -303,7 +305,7 @@
 	</p>
       </div>
       <div class="section">
-	<h2> Offsite-Backup für Disaster-Recovery </h2>
+	<h3> Offsite-Backup für Disaster-Recovery </h3>
 	<p>
 	  Ein volles Backup sollte sich off-site befinden, um im Fall
 	  eines Komplettausfalls ein Ersatzrechenzentrum aufbauen zu
@@ -333,7 +335,7 @@
 	</p>
       </div>
       <div class="section">
-	<h2> Datenbank-Backups </h2>
+	<h3> Datenbank-Backups </h3>
 	<p>
 	  Datenbank-Backups in Form von Datenfiles sind hauptsächlich
 	  für Disaster-Recovery und zum Clonen einer Datenbank für
@@ -355,5 +357,40 @@
 	</p>
       </div>
     </div>
+    <div>
+      <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>
   </body>
 </html>