In diesem Kapitel werden die grundlegenden Funktionen erklärt, die zum Volume-Management benötigt werden. Die meisten dieser Konzepte sind sowohl für Tape- als auch für Disk/Festplatten-Volumes gültig. Allerdings wurde dieses Kapitel ürsprünglich geschrieben, um das Mangement von Disk-Volumes zu beschreiben. Sie werden diese Tendenz sicher stellenweise bemerken, trotzdem gelten alle Konfigurations- Möglichkeiten gleichermaßen für Tape- und Disk-Volumes.
Disk-Volumes werden normalerweise benutzt, wenn sowieso sehr viel Festplatten- Platz verfügbar ist, oder die Backup-Jobs innerhalb eines sehr kleinen Zeitfensters laufen müssen, wo die Festplatten einen Geschwindigkeitsvorteil gegenüber den Bandlaufwerken haben.
Bacula dazu zu bringen, dass es auf Disk-Volumes statt auf Tapes schreibt ist im einfachsten Fall sehr leicht zu bewerkstelligen. In der Konfiguration des Storage-Dienstes geben Sie dazu als Archive Device ein Verzeichnis an. Wenn Sie, zum Beispiel, möchten das Ihre Backups im Verzeichnis /home/bacula/backups gespeichert werden, können Sie folgende Geräte-Konfiguration verwenden:
Device { Name = FileBackup Media Type = File Archive Device = /home/bacula/backups Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; }
Zusätzlich muss der entsprechende Storage-Eintrag in der Konfiguration des Director-Dienstes vorhanden sein:
Storage { Name = FileStorage Address = host.firma.de Password = xxxxx Device = FileBackup Media Type = File }
Bacula wird dann die Backup-Daten in die Datei /home/bacula/backups/<Volume-Name> schreiben. <Volume-Name> ist dabei der Name eines vorher erstellten Volumes. Falls Sie ein Volume namens Vol001 erstellt haben, wird Bacula also in die Datei names /home/bacula/backups/Vol001 schreiben. Obwohl Sie diese Datei später problemlos in ein anderes Verzeichnis verschieben können, dürfen Sie niemals den Namen der Datei ändern. Bacula verwendet den Datei-Namen des Volumes als Teil des internen Volume-Labels, daher wird Bacula das Volume nicht mehr als korrekt erkennen, wenn der Dateiname von Volume-Label abweicht.
Auch wenn bis jetzt alles sehr einfach aussieht gibt es doch ein paar Probleme mit dieser Beispiel-Konfiguration. Das Erste ist, dass Bacula immer auf das selbe Volume schreiben wird, so lange bis die Festplatte voll ist. Die Lösung dafür wird weiter unten beschrieben.
Zusätzlich müssen Sie auch noch andere Details beachten, wenn Sie zum Beispiel wollen, dass mehrere Backup-Jobs gleichzeitig laufen. Eine Beispiel-Konfiguration für so ein Setup finden Sie am Ende dieses Kapitels im Abschnitt gleichzeitige Disk Jobs.
Hier ist eine Liste aller Optionen die Sie in der Pool-Konfiguration angeben können, um die Benutzung der Volumes durch Bacula zu begrenzen:
UseVolumeOnce = yes
in der Pool-Konfiguration angeben.
Maximum Volume Jobs = nnn.
Maximum Volume Bytes = mmmm.
Bitte beachten Sie, dass, wenn Sie Disk-Volumes mit Bacula-Version bis 1.39.28 verwenden, Sie die maximale Volume-Größe auf einen sinnvollen Wert, wie zum Beispiel 5 GB, setzen. Das ist notwendig, weil Bacula während der Wiederherstellung das gesamte Volume lesen muss, bis an den Punkt wo die wiederherzustellenden Daten beginnen. Wenn Ihre Volumes 50GB groß sind, dauert das natürlich entsprechend länger. Auch bei einer teilweise defekten Festplatte verlieren Sie wahrscheinlich weniger Volumes, wenn diese entsprechend kleiner sind.
Volume Use Duration = ttt.
Obwohl Sie wahrscheinlich niemals die Anzahl der Bytes begrenzen wollen, die auf ein Tape geschrieben werden dürfen, können die anderen genannten Konfigurations-Optionen auch bei Bandlaufwerken sehr nützlich sein. Als Beispiel können Sie mit den oben beschriebenen Optionen dafür sorgen, dass Ihre Bänder in einer täglichen Rotation verwendet werden.
Wie schon erwähnt, wird jede dieser Optionen innerhalb der Pool- Konfiguration angegeben die für den Pool, in dem die Volumes sind, gilt. Die Parameter Maximum Volume Job, Maximum Volume Bytes und Volume Use Duration können für jedes Volume einzelt gesetzt werden. Dazu werden die Werte aus der Pool-Konfiguration beim Labeln des Volumes in einen eigenen Datenbank-Eintrag, der nur für das Volume gültig ist, übernommen. Dieser Datenbank-Eintrag kann dann mittels des Console-Kommandos update volume seperat angepasst werden. Dadurch das die Pool-Konfiguration als eigener Eintrag für die Volumes in die Datenbank übernommen wird, ist eine Änderung in der Pool-Konfiguration nur für Volumes gültig die nachher erstellt werden. Um die neue Pool-Konfiguration auch auf die bereits bestehenden Volumes anzuwenden, muss in der Console bei dem Kommando bf update volume die Funktion bf All Volumes from Pool aufgrufen werden.
Als ein Beispiel für die Benutzung eines der oben genannten Paramter, nehmen wir einmal an, Ihre Pool-Konfiguration sieht so aus:
Pool { Name = File Pool Type = Backup Volume Use Duration = 23h }
Wenn Ihre Backup-Jobs dann einmal am Tag laufen (also alle 24 Stunden) wird Bacula für jeden Backup-Lauf ein neues Volume verwenden, da für die Volumes eine maximale Benutzungs-Zeit von 23 Stunden gesetzt ist. Die Zeit gilt dabei ab dem ersten Schreibvorgang auf dem Volume. Bedenken Sie, dass das Setzen einer Use-Duration für Tape-Volumes dazu führen kann, dass eventuell auch am Wochenende neue leere Tapes in das Laufwerk gelegt werden müssen (sofern Sie keinen Autochanger benutzen).
Wenn Sie die genannten Konfigurations-Parameter benutzen, stoßen Sie wahrscheinlich auf das nächste Problem: Sie müssen die Volumes labeln. Sie können dabei zwischen zwei Varianten wählen, entweder Sie labeln die Volumes manuell bevor Bacula sie benötigt, oder Sie lassen Sie automatisch durch Bacula, in dem Moment wo sie gebraucht werden, labeln. Beim automatischen Labeln der Volumes können Sie auf eine vielzahl von Informationen, Umgebungsvariablen und internen Zählern von Bacula zugreifen, um sinnvolle Volume-Label erstellen zu lassen. Sie können auch mittels eines Python-Script das Bacula-Event ,,NewVolume`` auswerten und durch das Script ein neues Volume erstellen lassen. Dabei haben Sie dann alle Freiheit was den Namen des zu erstellenden Volumes angeht. Mehr Informationen über die Verwendung von Python-Scripten finden Sie im Kapitel Python Scripte dieses Handbuchs.
Das automatische Labeln von Volumes kann auch mit Tapes benutzt werden, dabei ist allerdings zu bendeken, dass die Tapes dafür gemountet werden müssen, was eventuell menschliches Eingreifen erfordert. Automatisches Labeln nach Templates (Vorlagen) funktioniert mit Autochangern nicht, da Bacula niemals auf Slots zugreift, die unbekannte Tapes enthalten. Im Kapitel Autochanger dieses Handbuchs sind mehrere Methoden beschrieben, wie alle Tapes innerhalb des Autochangers gelabelt werden können.
Automatisches Labeln der Volumes wird durch Anpassungen in der Pool- (Director) und Geräte- (Storage) Konfiguration, wie unten beschrieben, aktiviert. In der Pool-Konfiguration müssen Sie Bacula das Label-Format vorgeben. In diesem Format werden dann die neuen Volumes benannt. In der einfachsten Form ist das Format nur der Volume-Name an den Bacula dann eine vierstellige laufende Nummer anhängt. Diese Nummer beginnt bei 0000 und wird pro Volume immer uns Eins erhöht. Wenn Sie Ihre Pool-Konfiguration also folgend anpassen:
Pool { Name = File Pool Type = Backup Volume Use Duration = 23h LabelFormat = "Vol" }
wird Bacula Volumes names Vol0001, Vol0002 und so weiter immer dann erstellen wenn sie benötigt werden. Weit komplexere und ausführliche Namen lassen sich mittels Variablen-Auswertung erstellen. Hilfe dazu finden Sie im Kapitel Variablen-Auswertung.
Nähere Angaben zum Label Format finden Sie im Kapitel ,,Label Format`` des Bacula-Installations- und Konfigurations-Handbuchs.
Der zweite notwendige Schritt um das automatische Labeln zu aktivieren, ist es dem Storage-Dienst das Labeln zu erlauben. Das tun Sie indem Sie LabelMedia = yes in der Geräte-Konfiguration angeben:
Device { Name = File Media Type = File Archive Device = /home/bacula/backups Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; LabelMedia = yes }
Das oben beschriebene automatische Labeln der Volumes lässt ein neues Problem entstehen: es wird eine Art Volume-Management benötigt. Mit dem bisherigen Schema wird jeden Tag ein neues Volume erstellt. Wenn Sie keine Aufbewarungszeiträume konfiguriert haben, wird sich Ihre Katalog-Datenbank, zusätzlich zu den jeden Tag enstehenden Volumes, immer weiter mit den Informationen über alle von Bacula gesicherten Dateien füllen.
Bacula stellt folgende Konfigurations-Parameter zur Verfügung um diese Probleme automatisch handzuhaben:
Die ersten drei Konfigurations-Einträge (File Retention, Job Retention und AutoPrune) bestimmen die Zeit, die die Job- und Datei-Einträge in der Katalog-Datenbank aufbewart werden. Eine genaue Beschreibung dieser Parameter finden Sie im Kapitel automatische Volume Wiederverwendung in diesem Handbuch.
Volume Retention, AutoPrune und Recycle bestimmen, wie lange Bacula die Volumes vor dem Wiederbeschreiben aufbewart. Auch das wird im Kapitel automatische Volume Wiederverwendung näher beschrieben.
Der Parameter ,,Maximum Volumes`` kann in Verbindung mit der ,,Volume Retention Period`` dazu verwendet werden, die maximale Anzahl der Volumes zu begrenzen die Bacula verwendet. Wenn eine angemessene Aufbewarungszeit für die Volumes gesetzt ist, werden die Volumes, kurz bevor wieder ein neues Volume benötigt wird, automatisch ablaufen. Das periodische Wiederverwenden einer festen Anzahl von Volumes kann auch durch setzen von Recycle Oldest Volume = yes oder Recycle Current Volume = yes erreicht werden. In diesem Fall wird Bacula, wenn ein neues Volume benötigt wird, das enstsprechende Volume wiederverwenden.
Oberhalb wurde beschrieben, wie Sie ein einzelnes Storage-Gerät namens FileBackup benutzen können, um die zu sichernden Daten auf Volumes im Verzeichnis /home/bacula/backups zu schreiben. Natürlich ist es auch möglich mehrere Jobs gleichzeitig auf diesem einen Storage-Gerät laufen zu lassen. Alle Jobs werden dann parallel auf das Volume geschrieben.
Falls Sie mehrere Pools, was auch bedeutet mehrere Volumes, verwenden wollen, oder möchten das jeder Backup-Client auf ein eigenes Volume gesichert wird, oder in ein seperates Verzeichnis wie etwa /home/bacula/client1 und /home/bacula/client2, dann werden Sie das mit der bisherigen Konfiguration nicht bewerkstelligen können. Das liegt daran, dass Bacula Festplatten-Volumes nach den gleichen Regeln behandelt wie Bandlaufwerke. Ein Storage-Gerät kann zu jeden beliebigen Zeitpunkt nur ein einziges Volume enthalten. Wenn Sie also gleichzeitig auf mehreren Volumes schreiben möchten, müssen Sie auch mehrere Storage-Geräte in der Konfiguration des Storage-Dienstes und des Director-Dienstes angeben.
Mehrere Geräte-Definitionen sind also notwendig, wenn auf mehr als ein Storage-Gerät oder in verschiedene Verzeichnisse gesichert werden soll. Weiterhin müssen Sie wissen, dass in der Katalog-Datenbank nur die Informationen über den ,,Media-Type`` und nicht das spezielle Storage-Gerät gespeichert werden. Dadurch wird es möglich, dass, zum Beispiel ein Tape, in jedem anderen kompatiblen Storage-Gerät gemounted werden kann. Diese Kompitabilität wird durch einen identischen Media-Type der verschiedene Storage-Geräte erreicht. Das ist auch für Festplatten-Volumes gültig. Da ein Volume, das vom Storage- Gerät in dem Verzeichnis /home/bacula/backups beschrieben wurde, nicht von einem Storage-Gerät gelesen werden kann, dass /home/bacula/client1 als ,,ArchiveDevice`` konfiguriert hat, werden Sie Probleme bei der Wiederherstellung von Daten bekommen, falls beide Geräte mit Media Type = File angegeben sind. Bei der Wiederherstellung von Daten wird Bacula das erste zur Verfügung stehende Laufwerk mit dem passenden ,,Media Type`` wählen, unabhähngig davon, ob es das Richtige ist. Falls das verwirrend klingt, erinnern Sie sich daran, dass der Director-Dienst nur den Volume-Namen und den Media-Type kennt. Auf welchen Gerät das Volume beschrieben wurde, und unter welchem Verzeichnis, ist zu diesem Zeitpunkt unbekannt. Daher müssen Sie Ihre Volumes, mittels des Media Types, den korrekten Geräten zuordnen.
Das folgende Beispiel zeigt eine Konfiguration, bei der zwei Clients zwei verschiedene Pools und Verzeichnisse zum speichern ihrer Daten benutzen.
Das folgende Beispiel ist nicht sehr praxisnah, aber es reicht aus, um in kurzer Zeit, den Ablauf zu demonstrieren. In diesem Beispiel gibt es zwei Clients die auf je einen Satz von 12 Volumes und in zwei verschiedene Verzeichnisse gesichert werden. Jedes Volume wird nur einmal benutzt und innerhalb einer Stunden werden vier Vollbackups gestartet. Damit dauert der komplette Lauf über alle 12 Volumes pro Client nur 3 Stunden.
Der Schlüssel hierbei ist, dass die beiden physikalischen Storage- Geräte unterschiedliche Media Types benutzen. Das ermöglicht dem Director-Dienst, bei der Wiederherstellung von Daten, das richtige Geraät auszuwählen.
Die Director-Dienst-Konfiguration sind wie folgend aus:
Director { Name = my-dir QueryFile = "~/bacula/bin/query.sql" PidDirectory = "~/bacula/working" WorkingDirectory = "~/bacula/working" Password = dir_password } Schedule { Name = "FourPerHour" Run = Level=Full hourly at 0:05 Run = Level=Full hourly at 0:20 Run = Level=Full hourly at 0:35 Run = Level=Full hourly at 0:50 } Job { Name = "RecycleExample" Type = Backup Level = Full Client = Rufus FileSet= "Example FileSet" Messages = Standard Storage = FileStorage Pool = Recycle Schedule = FourPerHour } Job { Name = "RecycleExample2" Type = Backup Level = Full Client = Roxie FileSet= "Example FileSet" Messages = Standard Storage = FileStorage1 Pool = Recycle1 Schedule = FourPerHour } FileSet { Name = "Example FileSet" Include { Options { compression=GZIP signature=SHA1 } File = /home/kern/bacula/bin } } Client { Name = Rufus Address = rufus Catalog = BackupDB Password = client_password } Client { Name = Roxie Address = roxie Catalog = BackupDB Password = client1_password } Storage { Name = FileStorage Address = rufus Password = local_storage_password Device = RecycleDir Media Type = File } Storage { Name = FileStorage1 Address = rufus Password = local_storage_password Device = RecycleDir1 Media Type = File1 } Catalog { Name = BackupDB dbname = bacula; user = bacula; password = "" } Messages { Name = Standard ... } Pool { Name = Recycle Use Volume Once = yes Pool Type = Backup LabelFormat = "Recycle-" AutoPrune = yes VolumeRetention = 2h Maximum Volumes = 12 Recycle = yes } Pool { Name = Recycle1 Use Volume Once = yes Pool Type = Backup LabelFormat = "Recycle1-" AutoPrune = yes VolumeRetention = 2h Maximum Volumes = 12 Recycle = yes }
und die Konfiguration des Storage-Dienstes:
Storage { Name = my-sd WorkingDirectory = "~/bacula/working" Pid Directory = "~/bacula/working" MaximumConcurrentJobs = 10 } Director { Name = my-dir Password = local_storage_password } Device { Name = RecycleDir Media Type = File Archive Device = /home/bacula/backups LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; } Device { Name = RecycleDir1 Media Type = File1 Archive Device = /home/bacula/backups1 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; } Messages { Name = Standard director = my-dir = all }
Mit ein wenig Anpassung können Sie dieses Beispiel als Grundlage für einen wöchentlichen oder monatlichen Backup-Ablauf verwenden. Beacht6en Sie dabei aber den zur Verfügung stehenden Festplattenplatz.
Bacula kann natürlich auch auf mehrere Festplatten sichern, dabei muss aber jede Festplatte in der Storage-Dienst-Konfiguration als eigenes Gerät angegeben werden. Dann kann über die Client-Konfiguration das zu benutzende Gerät, also die Festplatte, ausgewählt werden. Zusätzlich muss jedes Storage-Gerät einen anderen Media Type benutzen, damit Bacula bei der Wiederherstellung von Daten das richtige Gerät auswählen kann.
Wenn Sie zwei Festplatten oder Partitionen als ein logisches Storage-Gerät verwenden wollen, wird es etwas komplizierter, da Bacula so ein vorgehen nicht direkt unterstützt. Trotzdem ist es möglich zwei Festplatten als ein Gerät anzusprechen, indem Sie die Volume-Dateien auf den Festplatten verlinken.
Angenommen Sie haben zwei Festplatten namens /disk1 und /disk2. Wenn Sie jetzt die Standard-Konfiguration für ein Backup auf die erste Festplatte anlegen, sieht Ihre Storage-Dienst-Konfiguration wie folgt aus:
Device { Name = client1 Media Type = File Archive Device = /disk1 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; }
Da es keinen Weg gibt diese Geräte-Konfiguration auf beide Festplatten zeigen zu lassen, müssen Sie die Volumes auf /disk2 auf folgende Weise von Hand erstellen:
ln -s /disk2/Disk2-vol001 /disk1/Disk2-vol001 ln -s /disk2/Disk2-vol002 /disk1/Disk2-vol002 ln -s /disk2/Disk2-vol003 /disk1/Disk2-vol003 ...
An diesem Punkt können Sie die Volumes mit den folgenden Namen labeln: Disk2-vol001, Disk2-vol002, ... . Bacula wird sie dann so benutzen als wären sie auf /disk1, aber die Daten werden in Wirklichkeit auf /disk2 geschrieben. Die einzigen Unbequemlichkeit dabei sind, dass Sie die Namen der Volumes ausdrücklich angeben müssen und dass das automatische Labeln der Volumes nur noch funktioniert, wenn die Label der Volumes genau den Namen der Links entsprechen, die Sie angelegt haben.
Wichtig zu wissen ist, dass Bacula Volumes auf Festplatten, soweit wie möglich, als Bandlaufwerke zu behandelen zu versucht. Das bedeutet, dass immer nur ein einziges Festplatten-Volume zur Zeit in einem, in der Storage-Dienst-Konfiguration angebenen Gerät, gemounted sein kann. Sie können mehrere Backup-Jobs parallel auf das gerade gemountete Volume schreiben lassen, aber wenn Sie die Jobs gleichzeitig auf unterschiedliche Volumes schreiben lassen wollen, müssen Sie mehrere Geräte-Konfiguration, eine für jeden gleichzeitigen Job, anlegen. Das ist dasselbe Vorgehen, wie es bei zwei Bandlaufwerken erforderlich ist. Allerdings gibt es einen großen Unterschied, die Volumes die Sie auf Festplatten erstellen können nicht so ohne weiteres gegen einander ausgetauscht werden, wie es bei Bandlaufwerken möglich ist. Daher muss jedes Festplatten-Volume/-Gerät einen anderen Media Type verwenden, nur so kann sichergestellt werden, dass Bacula bei der Wiederherstellung das korrekte Gerät auswählt.
Ein Beispiel dafür:
Device { Name = Disk1 Media Type = File1 Archive Device = /disk1 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; } Device { Name = Disk2 Media Type = File2 Archive Device = /disk2 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; }
Mit den oben genannten Geräte-Konfigurationen können Sie zwei Backup-Jobs parallel auf zwei veschiedene Geräte schreiben, eine Job auf /disk1 und einen Job auf /disk2. Durch den unterschiedlichen Media Type kann Bacula das richtige Gerätzur Wiederherstellung von Daten bestimmen.
Bevor wir dem obigen Beispiel einen weiteren Client hinzufügen, sollten, sollten folgende Aspekte bedacht werden:
Hier ein Beispiel für zwei Backup-Clients die jeder in einen anderen Pool und auf unterschiedlich viele Volumes gesichert werden. Zusätzlich schreiben sie in unterschiedliche Verzeichnisse mit unterschiedlich gelabelten Volumes.
Hier die Konfiguration des Director-Dienstes:
Director { Name = my-dir QueryFile = "~/bacula/bin/query.sql" PidDirectory = "~/bacula/working" WorkingDirectory = "~/bacula/working" Password = dir_password } # Basic weekly schedule Schedule { Name = "WeeklySchedule" Run = Level=Full fri at 1:30 Run = Level=Incremental sat-thu at 1:30 } FileSet { Name = "Example FileSet" Include { Options { compression=GZIP signature=SHA1 } File = /home/kern/bacula/bin } } Job { Name = "Backup-client1" Type = Backup Level = Full Client = client1 FileSet= "Example FileSet" Messages = Standard Storage = File1 Pool = client1 Schedule = "WeeklySchedule" } Job { Name = "Backup-client2" Type = Backup Level = Full Client = client2 FileSet= "Example FileSet" Messages = Standard Storage = File2 Pool = client2 Schedule = "WeeklySchedule" } Client { Name = client1 Address = client1 Catalog = BackupDB Password = client1_password File Retention = 7d } Client { Name = client2 Address = client2 Catalog = BackupDB Password = client2_password } # Two Storage definitions with different Media Types # permits different directories Storage { Name = File1 Address = rufus Password = local_storage_password Device = client1 Media Type = File1 } Storage { Name = File2 Address = rufus Password = local_storage_password Device = client2 Media Type = File2 } Catalog { Name = BackupDB dbname = bacula; user = bacula; password = "" } Messages { Name = Standard ... } # Two pools permits different cycling periods and Volume names # Cycle through 15 Volumes (two weeks) Pool { Name = client1 Use Volume Once = yes Pool Type = Backup LabelFormat = "Client1-" AutoPrune = yes VolumeRetention = 13d Maximum Volumes = 15 Recycle = yes } # Cycle through 8 Volumes (1 week) Pool { Name = client2 Use Volume Once = yes Pool Type = Backup LabelFormat = "Client2-" AutoPrune = yes VolumeRetention = 6d Maximum Volumes = 8 Recycle = yes }
und die Storage-Dienst-Konfiguration:
Storage { Name = my-sd WorkingDirectory = "~/bacula/working" Pid Directory = "~/bacula/working" MaximumConcurrentJobs = 10 } Director { Name = my-dir Password = local_storage_password } # Archive directory for Client1 Device { Name = client1 Media Type = File1 Archive Device = /home/bacula/client1 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; } # Archive directory for Client2 Device { Name = client2 Media Type = File2 Archive Device = /home/bacula/client2 LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; } Messages { Name = Standard director = my-dir = all }
eric 2009-05-06