From 1df0e25ed6317b011fbc8e43c00221544c73b28c Mon Sep 17 00:00:00 2001
From: hjp <hjp@d47eeb7a-11fe-0310-b519-e5a4e12f9765>
Date: Mon, 15 Jan 2007 15:49:43 +0000
Subject: [PATCH] Mehr zu DB-Backups.

---
 doc/konzept.html | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/doc/konzept.html b/doc/konzept.html
index 5e4110d..5d3d562 100644
--- a/doc/konzept.html
+++ b/doc/konzept.html
@@ -335,13 +335,14 @@
       <div class="section">
 	<h2> Datenbank-Backups </h2>
 	<p>
-	  Die sinnvolle Lebensdauer von Datenbank-Backups ist begrenzt
-	  (spätestens nach einem Versionsupgrade sind sie nicht mehr
-	  brauchbar), Datenbank-Backups (in ihrer aktuellen Form) werden
-	  daher hauptsächlich für Desaster-Recovery und Migrationstests
-	  gemacht, eine Archivierung ist nicht sinnvoll.
-	  (Anm.: Dieses Szenario geht von unseren aktuellen Cold-Backups
-	  aus)
+	  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:
 	</p>
 	<p>
 	  Erstelle eine Liste der aktuellen Fileversionen der
@@ -349,7 +350,8 @@
 	</p>
 	<p>
 	  Jeder Pool enthält eine fixe Anzahl von Bändern, das jeweils
-	  älteste wird recycelt.
+	  älteste wird recycelt. Ein Band pro Quartal wird in den
+	  Archiv-Pool verschoben.
 	</p>
       </div>
     </div>