[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backupprogramm



Juergen Sauer <juergen.sauer@automatix.de> writes:

> Am Freitag, 8. August 2003 17:46 schrieb Sven Rudolph:
> > Juergen Sauer <juergen.sauer@automatix.de> writes:

(Zwecks Überblick die relevanten Punkte:
3. incremental Backup
6. große Partitionen sichernd (Part. >> tapemedium)
9. desaster recovery
11. transparent und nicht störend im Hintergrund arbeitend)

> > 3 - kein Problem
> Wie konfigurierst Du das ?

OK, ich nehme mal an, daß inkrementell bedeutet, daß sich
nicht-Full-Backup stets direkt auf ein Full Backup bezieht. Wenn du
das anders meinst, müßten wir uns begrifflich einigen.

       bumpdays int
              Default:  2.   To  insure  redundancy in the dumps,
              Amanda keeps filesystems at  the  same  incremental
              level for at least bumpdays days, even if the other
              bump threshold criteria are met.

Wenn bumpdays also deinem Backup-Zyklus entspricht (hinreichend groß
ist), gibt es nur Full Backups und Level-1-Backups.

> > 6 - man muß halt die Datenhaufen selbst mittels exclude-Pattern aufteilen
> Das ist ja wohl ein Witz ?
> Das ist hier kein Datenhaufen sondern ein regulär arbeitender Betrieb,
> alleine die 3-Monats Filebackups der Datenbanken sprengen jedes
> Tape.

Willst du sagen, daß einzelne Dateien nach Kompression nicht auf ein
Band passen? In diesem Fall hast du mit amanda wirklich ein Problem.

Mal etwas Praxis: Ich mach wöchentlich eine komplette Sicherung, das
sind (nach gzip-Kompression) 1 TB, auf 10 Bänder a 110 GB. Das ist ein
regulär arbeitender Betrieb. Insofern ist mir nicht klar, was du
machst, damit es bei dir nicht geht.

> > 9 - ich sehe kein Problem; was fehlt dir?
> Ich habe in den Amanda Dokus keine klaren Hinweise gefunden, wie man
> ordentlich eine einzelne Datei von einem Tape Restauriert, 
> den Backup Server resauriert nach einem Totalschaden,

In docs/RESTORE steht das für mehrere Fehler-Szenarien. Amanda nutzt
normale Werkzeuge, also tar (mache ich) oder dump. Man kann die Bänder
also auch ohne Amanda einlesen.
 
> Wie stellt man die indices wieder her ?

Indem man sie von Band rücksichert.

> Wie liest man ein einzelnes Band wieder ein ?

Mit tar.

> Wie erstellt man ein inhaltsverzeichnis ?

Indem man es von Band rücksichert.

> Hier hatte mir Tapeware/Novell am besten gefallen, da wurde die komplette
> Index DB ans letzte Sicherungsband angehhängt.

Genau so funktioniert amanda nicht. (Prinzipiell könnte man aus dem
Archiv den Index bauen, aber das hat wohl noch keiner gebraucht.)

> Ich meine tatsächlich "nicht störend im Hintergrund laufend",
> amanda drainiert alle verfügbare CPU clientseitig sobald der
> dumper anläuft ebenso zert es den verfügbaren Ram auf.  Es kommt
> mir vor, daß zuerst in einem Burst alles durchgekämmt und "angelesen" 
> wird. (Verzeichnisse). Wenn Du auf 6 Partionen sechs mal ein 
> "find . -xdev" machst, weißt Du was ich meine ... Wenn Du auch noch die
> Ergebnisse verarbeitest (in ToDo List, pipe in ein tar cz -|send to senddata)
> Dann herschet auch bei nicht allzu großen Abteilungsservern Augenstillstand !

Das wundert mich sehr. Mit maxdumps stellt man die maximale Anzahl von
parallelen Läufen pro Client ein, der default ist 1. ps müßte dir ja
sagen, welche Prozesse und wieviele sich da beschäftigen. 6 parallele
finds auf einer Platte ist nun mal unsinnig, aber man muß amanda ja
nicht extra so konfigurieren.

Ansonsten klingt das nach GNU Tar, das zuerst den Index der Dateien
aufbaut und anschließend sortiert. Bei vielen kleinen Dateien (z.B. 50
GB als Dateien mit ca. 20 kB ...) braucht es da in der Tat sehr viel
CPU. Das ist wohl einer der wenigen Fälle, wo man statt tar dump
nehmen muß.

Amanda ist modular, es nutzt andere Programme zur Datensicherung. Man
müßte wohl die Sortiererei in GNU Tar abschalten, die wohl nur dazu da
ist, Hardlinks zu erkennen und die Datei dann nur einmal abzuspeichern.

Ansonsten viel Spaß mit afbackup; ich habe es mir auch grade mal
installiert, um es wieder mal anzugucken ...

        Sven
-- 
Sven Rudolph <sr1@sax.de>		http://www.sax.de/~sr1/



Reply to: