Backup mittels Bacula unter Debian GNU/Linux 5.0 "Lenny" Howto

Backup mittels Bacula unter Debian GNU/Linux 5.0 "Lenny" Howto 03.07.2016 02:42:19 FAQArtikelAusdruck Kategorie: Software::BACULA Bewertungen: 0 Status: öffentlich (Alle) Ergebnis: 0.00 % Sprache: de Letzte Aktualisierung: 21:14:25 13.08.2013 Schlüsselwörter linux,, backup Symptom (öffentlich) Einleitung Die Erstellung und Verwaltung von zuverlässigen Backups beschäftigt seit jeher die Administratoren und ITVerantwortliche. Unabhängig davon, ob wir unsere Server redundant betreiben und unsere Daten auf mehrfach redundanten StorageArrays lagern, werden menschliche Fehler und Vertipper damit nicht verhindert, mit teilweise schwerwiegenden Folgen. Nur durch eine konsequente BackupStrategie der Systeme können wir die Gefahr von Datenverlusten minimieren. Dabei sollte im Fall eines Desasters das Backup möglichst schnell und unkompliziert rekontruiert werden können. Ich habe bereits in einem [1]anderen Howto eine einfache Datensicherung mittels rsync vorgestellt, die bspw. für einfache Systeme verwendet werden kann. Je komplexer und heterogener jedoch die ITInfrastruktur wird, umso komplexer sind auch die Anforderungen, die an ein BackupSystem gestellt werden. In dem vorliegenden Howto möchte ich die Installation und Konfiguration einer dezentralen BackupLösung unter Verwendung der Open Source EnterpriseAnwendung Bacula beschreiben. Dabei handelt es sich bei Bacula um eine ausgewachsene und skalierbare BackupLösung, die eine ServerClientArchitektur verwendet und die u.a. in kleinen und mittleren Rechenzentren zum Einsatz kommt. So unterstützt Bacula bspw. auch BarcodeLeser bei LibraryRobotern und erfüllt somit auch alle Ansprüche, die in professionellen BackupUmgebungen gestellt werden. Meine persönliche Meinung zu Bacula ist, dass es sich dabei um die beste BackupSuite handelt, die aktuell auf dem gesamten Open Source Markt zu finden ist. Und auch den kommerziellen Anwendungen kann Bacula längst das Wasser reichen. Wie in den meisten anderen Howtos verwende ich an dieser Stelle Debian GNU/Linux 5.0 Lenny als Basissystem für den Bacula BackupServer. Bacula selbst ist in der Version 2.4.4 in den DebianRepositories enthalten. Da inzwischen jedoch die BackupLösung in der wesentlich aktuelleren Version 5.0.3 released wurde und diese mit eine Vielzahl von erweiterten Features aufwartet, werden wir an dieser Stelle den Sourcecode von Bacula kompilieren. Funktionsweise von Bacula Das Architekturmodell von Bacula basiert auf einer Vielzahl von Komponenten, die miteinander interagieren. Die Kapselung der Aufgaben in Modulen und die Interaktion zwischen diesen Komponenten bilden die Basis für die Mächtigkeit von Bacula. Die BackupLösung kann für alle Betriebssysteme und Hardwareplattformen verwendet werden. Bacula besteht aus den folgenden Modulen: Catalog (SQLDatenbank, in unserem Fall MySQL) Director ( dir ) StorageDaemon ( sd ) FileDaemon ( fd ) Console (CLI bzw. GNOME/wxWidgets GUI) Monitor Da Bacula für komplexe, verteilte und heterogene Umgebungen geschaffen wurde, können auch die einzelnen Komponenten verteilt werden und müssen nicht auf einem einzigen Server laufen. Insbesondere kann so bspw. eine zentrale BackupLösung für Unternehmen, die über mehrere Standorte verfügen, implementiert werden und die einzelnen Komponenten unter den Gesichtspunkten der Performance und Redundanz auf diese Standorte verteilt werden. Die einzelnen Komponenten kommunizieren dabei untereinander via IP. Katalog Seite 1

Der Katalog stellt die gesamte Logik der BackupLösung dar. Dabei handelt es sich um eine Datenbank (aktuell werden MySQL, PostgreSQL und SQLite unterstützt), die als Verzeichnisdienst fungiert und die bspw. den Dateiindex der gesicherten Dateien und die gesamten SicherungsVolumes verwaltet. Eine wichtige Aufgabe des Katalogs ist bspw. das Auffinden und die Wiederherstellung einzelner BackupDateien. In unserem Fall verwenden wir das RDBMS PostgreSQL als Backend für unseren Katalog. Director Der Director (Dienst dir ) bildet die Schaltzentrale von Bacula und steuert alle Vorgänge, die die Sicherung, Wiederherstellung und Überprüfung der Daten betreffen. Der Director ist bspw. für das zeitgesteuerte Ausführen der einzelnen Aktionen verantwortlich. Er regelt ebenfalls das Management von Medienpools und steuert die einzelnen File und StorageDaemons. Der Systemadministrator kommuniziert mit dem Director über die Console (s.u.). StorageDaemon Der StorageDaemon verrichtet auf dem Sicherungsserver seinen Dienst und ist für das Schreiben bzw. Lesen der Backupdaten auf den BackupDatenträgern verantwortlich. Die Auswahl von Sicherungsmedien reicht hierbei von einfachen Files auf Festplatten über CDs/DVDs bzw. einzelne Bandlaufwerke bis hin zu großen TapeLibraries. Der StorageDaemon erhält alle zu sichernden Dateien von dem jeweiligen FileDaemon. Der StorageDaemon muss auf jedem Server installiert werden, auf dem die BackupDaten gesichert werden sollen. So kann die Last, die das Schreiben eines Backups mit sich bringt, auf mehrere Storage Server verteilt werden. FileDaemon Auf jedem Rechner, dessen Daten von Bacula gesichert werden sollen, läuft ein entsprechender FileDaemon ( fd ). Je nach verwendetem Betriebssystem muss ein entsprechender Daemon installiert werden. Aktuell werden neben Linux und diversen UnixDerivaten (FreeBSD, OpenBSD, NetBSD, BSDi, Solaris, Mac OS X, AIX, Tru64, HPUX u.a.) die verschiedenen Varianten von Microsoft Windows unterstützt. Zudem wird Microsoft Volume Shadow Copy Service (VSS) unterstützt, so dass Bacula auch geöffnete Dateien, wie bspw. DatenbankFiles konsistent sichern kann. Der FileDaemon liest die Dateien von der Festplatte der Clients und übermittelt alle zu sichernden Dateien an den StorageDaemon. Console Die Console stellt eine Schnittstelle zur Kommunikation mit dem Director dar. Der Systemadministrator, der mit dem Director von Bacula kommunizieren möchte, kann dabei zwischen unterschiedlichen Frontends wählen. Zum einen existiert die CLIApplikation Bconsole, zum anderen grafische Frontends für Linux und Unix (GNOME bzw. wxwidgets), sowie eine native WindowsApplikation. Ebenfalls bietet das Projekt mit bweb eine webbasierte Oberfläche, mittels der sowohl die einzelnen Aufgaben getriggert werden können als auch das gesamte BaculaSystem überwacht wird. Zusätzlich zu diesem Howto habe ich bereits an einer [2]anderen Stelle ein Howto zur Installation und Konfiguration von bweb als Weboberfläche für Bacula auf einem Debian GNU/Linux 5.0 Lenny System beschrieben. Monitor Der Monitor bietet dem Anwender die Möglichkeit den Zustand aller Komponenten und Daemons, die zum Sicherungssystem dazugehören zu überwachen und so bspw. auch den aktuellen Sicherungszustand von Bacula einzusehen. Als Frontend verfügt der Bacula Monitor über eine GNOME bzw. KDEGUI. Verwendetes Netzwerkszenario Um das BaculaSetup an dieser Stelle möglichst einfach zu halten und dennoch einen allgemein gültigen und oft geforderten Einsatzfall abzubilden, verwende ich an dieser Stelle die folgenden Netzwerktopologie: Server.example.lan : verwaltet alle BaculaModule (Director, Storage und FileDaemon) und sichert jeweils einen Client im gleichen LAN ( client1.example.lan ) und einen externen Client client2.example.com. Client im LAN client1.example.lan via Internet erreichbarer Client client2.example.com Auf den beiden zu sichernden Clients kommt jeweils ein lokaler FileDaemon zum Einsatz. Zudem ist auf dem Sicherungsserver.example.lan Seite 2

selbst ein FileDaemon installiert, der für das Sichern der KatalogDatenbank zuständig ist. Graphisch aufbereitet sieht unser Netzwerkszenario folgendermaßen aus: client2.example.com FileDaemon: client2.example.comfd DSLRouter LAN client1.example.lan.example.lan FileDaemon: client1.example.lanfd Director:.example.landir StorageDaemon:.example.lansd FileDaemon:.example.lanfd Console: bconsole Verwendetes BackupSchema Bacula kennt drei unterschiedliche Arten von Backups: vollständig: sichert alles differenziell: sichert alle Dateien, die sich seit dem letzten vollständigen Backup verändert haben inkrementell: sichert alle Dateien, die sich seit dem letzten Backup geändert haben (unabhängig von der Art des Backups) In unserem Fall verwenden wir ein weit verbreitetes BackupSchema: jeden ersten Sonntag im Monat führen wir eine Vollsicherung durch jeden zweiten, dritten und vierten Sonntag im Monat führen wir ein differenzielles Backup durch jeden Tag ausser Sonntag führen wir ein inkrementelles Backup durch Dieses Vorgehen entspricht dem üblichen BackupZyklus. Da eine Vollsicherung eine hohe Netzwerklast auslösen kann, legen wir den Sicherungszeitpunkt auf Sonntag am frühen Morgen. Installation von benötigter Software Zunächst einmal benötigen wir auf dem BackupServer einige Softwarepakete, um Bacula bspw. kompilieren zu können: # aptitude install buildessential libpqdev libncurses5dev libssldev psmisc Installation eines RDBMS für den Katalog Bacula verwaltet alle ManagementDaten, die bspw. während eines Backup bzw. Wiederherstellungsvorgangs generiert werden, in einem relationalen Datenbankmanagementsystem. Bacula unterstützt von sich aus MySQL, PostgreSQL und SQLite als Backend für den Katalogdienst. In unserem Fall verwenden wir PostgreSQL, das wir zunächst installieren mittels: # aptitude install postgresql Anschließend sollten wir unseren PostgreSQLServer absichern und bspw. für den DBAdmin ein Passwort setzen. Ich habe bereits in einem [3]anderen Howto die dazu notwendigen Schritte beschrieben, so dass der Leser diesem Howto folgen und anschließend hierhin zurückkehren kann. Installation des BaculaServers Nun installieren wir auf dem zukünftigen BackupServer alle Komponenten der BaculaSuite, da wir sowohl den Director, den StorageDaemon als auch einen lokalen FileDaemon auf der gleichen physikalischen Maschine betreiben werden. Wie bereits oben beschrieben, verwenden wir dafür direkt das Projektarchiv, das wir zunächst herunterladen und entpacken: # cd /usr/local/src # wget http://downloads.sourceforge.net/project///5.0.3/5.0.3.tar.gz # tar xzvf 5.0.3.tar.gz # rm 5.0.3.tar.gz Anmerkung: da die Entwicklung von Bacula stetig voranschreitet, sollte an dieser Stelle die zum Installationszeitpunkt aktuelle Version der BackupSuite verwendet werden. Anschließend wechseln wir in das Projektverzeichnis /usr/local/src/5.0.3 und lassen darin zunächst die entsprechenden Makefiles von unserem System erstellen: # cd 5.0.3 #./configure Seite 3

prefix=/usr sbindir=/usr/sbin sysconfdir=/etc/ withscriptdir=/etc/ enablesmartalloc enableconio withpostgresql withopenssl withdiruser= withdirgroup= withsduser= withsdgroup= withfduser=root withfdgroup= withworkingdir=/var/lib/ withpiddir=/var/run withsubsysdir=/var/run/subsys Anmerkung: mittels der obigen Verzeichnisangaben wird die gesamte BaculaSuite so kompiliert, dass sie sich in das restliche LinuxSystem gut integriert. Wir verwenden die standardkonformen Verzeichnisse für die jeweiligen Teile der Suite (Binaries, Konfigurationsskripte, PIDDateien etc.). Zudem aktivieren wir OpenSSL, da wir später die Kommunikation zwischen den einzelnen Komponenten SSLverschlüsseln werden. Zudem legen wir den Benutzer für alle Komponenten ausser dem FileDamon als Standardbenutzer fest, unter dessen UID der jeweilige Prozess ausgeführt wird. Lediglich der FileDaemon muss als Root laufen, da dieser entsprechend Lesezugriff auf das gesamte zu sichernde Dateisystem haben muss. Konnte das ConfigureSkript die entsprechenden Makefiles fehlerfrei erstellen, quittiert es diesen Vorgang mit einer entsprechenden Statusmeldung: Configuration on Sat Dec 11 16:16:18 UTC 2010: Host: i686pclinuxgnu debian 5.0.3 Bacula version: Bacula 5.0.3 Source code location:. Install binaries: /usr/sbin Install libraries: /usr/lib Install config files: /etc/ Scripts directory: /etc/ Archive directory: /tmp Working directory: /var/lib/ PID directory: /var/run Subsys directory: /var/run/subsys Man directory: ${datarootdir/man Data directory: /usr/share Plugin directory: /usr/lib C Compiler: gcc 4.3.21.1) Seite 4

C++ Compiler: /usr/bin/g++ 4.3.21.1) Compiler flags: g O2 Wall fnostrictaliasing fnoexceptions fnortti Linker flags: Libraries: lpthread ldl Statically Linked Tools: no Statically Linked FD: no Statically Linked SD: no Statically Linked DIR: no Statically Linked CONS: no Database type: PostgreSQL Database port: Database lib: L/usr/lib lpq lcrypt Database name: Database user: Job Output Email: root@localhost Traceback Email: root@localhost SMTP Host Address: localhost Director Port: 9101 File daemon Port: 9102 Storage daemon Port: 9103 Director User: Director Group: Storage Daemon User: Storage DaemonGroup: File Daemon User: root File Daemon Group: SQL binaries Directory /usr/lib/postgresql/8.3/bin Large file support: yes Bacula conio support: yes ltermcap readline support: no TCP Wrappers support: no TLS support: yes Encryption support: yes ZLIB support: yes enablesmartalloc: yes enablelockmgr: no bat support: no enablegnome: no enablebwxconsole: no enabletraymonitor: no clientonly: no builddird: yes buildstored: yes ACL support: no XATTR support: yes Python support: no Batch insert enabled: yes Anschließend installieren wir den BaculaServer mittels: # make && make install Erstellen der PostgreSQL Datenbank Nachdem wir Bacula installiert haben, müssen wir nun unsere PostgreSQL Datenbank, die als Backend für den Katalogdienst verwendet wird, mit den entsprechenden Datenbanktabellen und Initialdaten füllen. In diesem Abschnitt möchte ich die entsprechenden Schritte erläutern, die manuell durchgeführt werden müssen. Bei der Installation von Bacula wurden automatisch entsprechende DatenbankSkripte angelegt, die wir im Folgenden verwenden, um die Datenbank zu initialisieren: # cd /etc/ # chown postgres:postgres create database create_postgresql_database make tables make_postgresql_tables grant privileges grant_postgresql_privileges drop tables drop_postgresql_tables drop database drop_postgresql_database # su postgres $./create database PostgreSQL quittiert den Vorgang mit der folgenden Statusmeldung: Creating PostgreSQL database CREATE DATABASE ALTER DATABASE Creation of database succeeded. $./make tables Creation of Bacula PostgreSQL tables succeeded. $./grant privileges Privileges for granted on. Nach der Initialisierung der PostgreSQL Datenbank enthält diese nun sowohl die benötigten Tabellen als auch die eigentlichen Initialdaten. Um den Zugriff auf die Datenbank abzusichern vergeben wir noch Seite 5

dem DBBenutzer (dieser wurde von dem Skript grant privileges automatisch angelegt) ein Passwort. Dazu rufen wir als Benutzer postgres das folgende Kommando auf: $ psql Nun befinden wir uns in der PostgreSQLKonsole. Darin setzen wir das Passwort mittels: =# alter user with password 'GeheimesDBPasswort ; Das erfolgreiche Setzen des Passworts bestätigt uns PostgreSQL mit dieser Meldung: ALTER ROLE Anschließend verlassen wir die PostgreSQL Konsole mittels: =# \q... und passen die Konfigurationsdatei /etc/postgresql/8.3/main/pg_hba.conf so an, dass der DBBenutzer beim Zugriff auf die DB authentifiziert wird. Dazu fügen wir vor die vorhandenen ZugriffsPolicies (ca. Zeile 76) die folgende Policy hinzu: local md5 Anschließend starten wir PostgreSQL neu: # /etc/init.d/postgresql8.3 restart Konfiguration von Bacula Die Komplexität von Bacula und das modulare Design dieser BackupSuite erfordern einige Einarbeitungszeit und ein gewisses Grundverständnis für die Funktionsweise von Bacula. Um das Setup einfach und übersichtlich zu halten, möchte ich in den folgenden Abschnitten die Konfiguration von Bacula auf einem einzigen Server beschreiben. Das bedeutet insbesondere, dass alle Bacula Dienste auf der gleichen Hardware ausgeführt werden (Director, Storage, Catalog etc.). Die Konfiguration von Bacula besteht im Prinzip in der Anpassung der folgenden Konfigurationsdateien: /etc//dir.conf : Konfiguration des Directors /etc//sd.conf : Konfiguration des Storage Daemons /etc//fd.conf : Konfiguration des File Daemons /etc//bconsole.conf : Konfiguration der Console Konfiguration des Directors Der Director stellt, wie bereits oben beschrieben, die Schaltzentrale eines BaculaSystems dar. Über den Director werden alle Aktionen, die in Verbindung mit Backups, Restores, Validierung der Backups etc. stehen, koordiniert. Daher ist die Konfiguration des Directors relativ komplex und findet sich in der Konfigurationsdatei /etc//dir.conf wieder. Zunächst definieren wir den Director selbst: # Director Director { Name =.example.landir Seite 6

DIRport = 9101 QueryFile = "/etc//query.sql" WorkingDirectory = "/var/lib/" PidDirectory = "/var/run" Maximum Concurrent Jobs = 1 Password = "09876543210987654321098765432109876543210987" Messages = Daemon Anmerkung: Die Kommunikation mit dem Director geschieht von Aussen mittels der mitinstallierten CLI Anwendung bconsole bzw. einer GUI (bat, wxwidgets Client, web, bweb etc.). Die entsprechende Steuerungskonsole muss sich gegenüber dem Director mit dem Passwort authentifizieren, das in der obigen Konfiguration festgelegt wurde. Ebenso müssen wir den BaculaKatalog definieren, der u.a. alle Metadaten über alle gesicherten Dateien verwaltet: # Catalog Catalog { Name = MyCatalog dbname = ""; dbuser = ""; dbpassword = "GeheimesDBPasswort" Anmerkung: die obige Direktive enthält alle Daten, die zum Verbindungsaufbau mit der Katalogdatenbank benötigt werden. Haben wir ein Passwort für den DBBenutzer angelegt, so muss dieses auch hier angegeben werden! Anschließend benötigen wir einen Media Pool, der zum Speichern der Sicherungsdaten definiert werden muss. Ein Media Pool bietet die Schnittstelle für den eigentlichen Schreib und Lesezugriff auf die BackupMedien, abstrahiert jedoch hierbei von dem eigentlichen physikalischen Speichermedium. In unserem Fall definieren wir in der Konfigurationsdatei /etc//dir.conf den MediaPool Default : # Media pool Pool { Name = Default LabelFormat = "BackupVol" Pool Type = Backup Recycle = yes AutoPrune = yes Volume Retention = 365 days Anschließend müssen wir unser StorageDevice definieren. An dieser Stelle wollen wir uns mit dem StorageDaemon verbinden, der auf der gleichen physikalischen Maschine ausgeführt wird, wie der Director. # Storage device Storage { Name = File Address =.example.lan SDPort = 9103 Password = "aaaaabbbbbcccccdddddeeeeefffffggggghhhhhiiii" Device = FileStorage Media Type = File Anmerkung: um eine gewisse Sicherheit zu erreichen, müssen sich der Director und der StorageDaemon gegenüber authorisieren. Dazu müssen beide Komponenten über das gleiche Passwort verfügen, das in der obigen Konfiguration bereits gesetzt wurde. Nun konfigurieren wir die Clients, deren Daten gesichert werden sollen. Wie bereits oben beschrieben, wollen wir unser BaculaSetup dafür nutzen, drei Clients zu sichern: den lokalen BaculaKatalog, den LANRechner client1.example.lan und den Remote Client client2.example.com. Die drei ClientDefinitionen sehen demnach folgendermassen aus: # Clients Client { Name =.example.lanfd Address =.example.lan FDPort = 9102 Catalog = MyCatalog Password = "11111222223333344444555556666677777888889999" File Retention = 30 days Job Retention = 6 months AutoPrune = yes Seite 7

Client { Name = client1.example.lanfd Address = client1.example.lan FDPort = 9102 Catalog = MyCatalog Passwort = "12345678901234567890123456789012345678901234" File Retention = 30 days Job Retention = 6 months AutoPrune = yes Client { Name = client2.example.comfd Address = client2.example.com FDPort = 9102 Catalog = MyCatalog Password = "99999888887777766666555554444433333222221111" File Retention = 30 days Job Retention = 6 months AutoPrune = yes Anmerkung: Da die einzelnen Komponenten u.u. verteilt auf verschiedenen Rechnern laufen, muss sich der Director, der die FileDaemons auf den einzelnen Clients steuert, sich diesen gegenüber authentifizieren. Daher müssen sowohl der FileDaemon als auch die entsprechende ClientDefinition in der obigen Konfiguration das gleiche Passwort aufweisen. Da die Entwickler der BackupSuite Bacula ein hohes Mass an Sicherheit von der Applikation fordern, werden Passwörter niemals im Klartext im Netzwerk übertragen, sondern als MD5Hashsumme übermittelt. Anschließend legen wir ein FileSet fest. Dieses definiert, welche Daten auf den Clients gesichert werden sollen. In unserem Fall wollen wir die beiden Clients client1.example.lan und client2.example.com komplett sichern, d.h. wir sichern das gesamte RootFilesystem / und schließen lediglich die für das Backup nicht benötigten Verzeichnisse /tmp, /proc, das BaculaVerzeichnis /var/lib/ etc. aus: # File sets FileSet { Name = "Full Set" Include { Options { signature = MD5 File = / Exclude { File = /tmp File = /proc File = /var/lib/ File = /.journal File = /.fsck Zudem benötigen wir ein weiteres FileSet, das zum Sichern des Katalogs benötigt wird und das demnach lediglich das entsprechende DatenbankFile beinhaltet: FileSet { Name = "Catalog" Include { Options { signature = MD5 File = /var/lib//.sql Anmerkung: Bacula legt für jede gesicherte Datei eine entsprechende Signatur an (in unserem Fall MD5) und ermöglicht so die Backups auf Integrität zu überprüfen. Damit wird die Manipulation von bereits geschriebenen Backups vermieden. Anschließend können wir den Zeitplan definieren, der beschreibt wann welche Aktionen ausgeführt werden: # Backup schedules Schedule { Seite 8

Name = "WeeklyCycle" Run = Full 1st sun at 2:05 Run = Differential 2nd5th sun at 2:05 Run = Incremental monsat at 2:05 Anmerkung: die Backupstrategie, die wir für unser BackupSetup verwenden, haben wir bereits weiter oben beschrieben. Zudem benötigen wir einen weiteren Zeitplan, der jeden Tag nach dem Durchlauf des jeweiligen Jobs aus dem WeeklyCycle Schedule folgt. Dieser wird für das Sichern des BaculaKatalogs benötigt: Schedule { Name = "WeeklyCycleAfterBackup" Run = Full sunsat at 2:10 Nachdem wir unseren MediaPool, unser StorageDevice, unsere Clients, unsere FileSets und die Schedules definiert haben, haben wir alle Informationen zusammen, um die eigentlichen Sicherungsjobs zu definieren. Da wir bspw. für jeden Client einen eigenen Job benötigen, ist es sinnvoll, alle allgemeingültigen Jobcharakteristica in einem Template zusammenzufassen. Daher definieren wir zunächst das JobTemplate: # Job definitions JobDefs { Name = "DefaultJob" Type = Backup Level = Incremental FileSet = "Full Set" Schedule = "WeeklyCycle" Storage = File Messages = Standard Pool = Default Priority = 10 Anschließend definieren wir die drei Jobs, die wir zum Sichern des LANClients client1.example.lan, des externen Clients client2.example.com und des lokalen BaculaCatalogs benötigen. Wir verwenden dabei die DefaultWerte aus den soeben erstellten JobDefinitionen, wobei diese jederzeit überschrieben werden können: # Jobs Job { Name = "Backup client1.example.lan" Client = client1.example.lanfd JobDefs = "DefaultJob" Write Bootstrap = "/var/lib//client1.example.lan.bsr" Job { Name = "Backup client2.example.com" Client = client2.example.comfd JobDefs = "DefaultJob" Write Bootstrap = "/var/lib//client2.example.com.bsr" Job { Name = "Backup catalog" Client =.example.lanfd JobDefs = "DefaultJob" Level = Full FileSet = "Catalog" Schedule = "WeeklyCycleAfterBackup" RunBeforeJob = "/etc//make_catalog_backup GeheimesDBPasswort" RunAfterJob = "/etc//delete_catalog_backup" Write Bootstrap = "/var/lib//catalog.bsr" Priority = 11 Anmerkung: sollten wir diesem Howto gefolgt sein, haben wir den Datenbankbenutzer durch ein Passwort geschützt. Daher muss dieses in der obigen Konfiguration entsprechend gesetzt werden! Zuletzt definieren wir noch, wie Status Nachrichten des BaculaSystems verarbeitet werden sollen: # Messages Messages { Name = Standard mailcommand = "/usr/sbin/bsmtp h localhost f \"\(Bacula\) \<%r\>\" \ s \"Bacula: %t %e of %c %l\" %r" operatorcommand = "/usr/sbin/bsmtp h localhost f \"\(Bacula\) \<%r\>\" \ s \"Bacula: Intervention needed for %j\" %r" mail = root@localhost = all,!skipped Seite 9

operator = root@localhost = mount console = all,!skipped,!saved append = "/var/log/.log" = all,!skipped catalog = all Messages { Name = Daemon mailcommand = "/usr/sbin/bsmtp h localhost f \"\(Bacula\) \<%r\>\" \ s \"Bacula daemon message\" %r" mail = root@localhost = all,!skipped console = all,!skipped,!saved append = "/var/log/.log" = all,!skipped Anmerkung: an dieser Stelle konfigurieren wir das System so, dass es alle Statusnachrichten sowohl an den Systembenutzer root an root localhost@ via Mail verschickt, sowie diese der Logdatei /var/log/.log anhängt. Konfiguration des Storage Daemons Die Konfigurationsdatei /etc//sd.conf steuert das Verhalten des StorageDaemons. Insbesondere wird hier das StorageDevice definiert, das später unsere gesamten BackupDaten aufnehmen wird. In unserem Fall verwenden wir das Verzeichnis /backup als BackupMedium. Bei der Installation von Bacula wurde auch diese Konfigurationsdatei bereits angelegt. Da Bacula sehr vielfältig ist und eine breite Vielzahl von Sicherungsmedien unterstützt, ist diese Datei mit vielen Beispielen gespickt, wie diese als BackupMedien verwendet werden können. Wir reduzieren diese Konfigurationsdatei auf das Wesentliche und verwenden lediglich das Verzeichnis zur Sicherung unserer Daten: Storage { Name = client1.example.lansd SDPort = 9103 WorkingDirectory = "/var/lib/" Pid Directory = "/var/run" Maximum Concurrent Jobs = 20 Director { Name =.example.landir Password = "aaaaabbbbbcccccdddddeeeeefffffggggghhhhhiiii" Device { Name = FileStorage Media Type = File Archive Device = /backup LabelMedia = yes; Random Access = Yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; Messages { Name = Standard director =.example.landir = all Anmerkung: das hier angegebene Passwort muss mit dem Password der StorageDefinition in der DirectorKonfigurationsdatei /etc//dir.conf übereinstimmen. Konfiguration des File Daemons Der FileDaemon wird in der Konfigurationsdatei /etc//fd.conf auf dem jeweils zu sicherndem Client konfiguriert und enthält Angaben über den Director, mit dem er sich verbinden soll, sowie eine Definition des Directors, an den alle Statusmeldungen geschickt werden sollen. Anmerkung: der FileDaemon sollte auch auf dem Sicherungsserver selbst installiert werden. Dieser wird dazu benötigt, um die Katalogdatenbank des BackupServers selbst zu sichern. Im Folgenden zeigen wir exemplarisch die Installation eines solchen lokalen FileDaemons. Die Konfigurationsdatei Seite 10

/etc//fd.conf kann in großen Teilen unverändert gelassen werden. Das Attribut Name wird mit dem Hostnamen des BaculaServers initialisiert (in unserem Fall heisst der BaculaServer ): Director { Name =.example.landir Password = "11111222223333344444555556666677777888889999" FileDaemon { Name =.example.lanfd FDport = 9102 WorkingDirectory = /var/lib/ Pid Directory = /var/run Maximum Concurrent Jobs = 20 Messages { Name = Standard director =.example.landir = all,!skipped,!restored Anmerkung: wie bereits oben erwähnt, muss sich der BaculaDirector beim FileDaemon authentifizieren. Daher muss bei der obigen Konfiguration in dem Konfigurationsblock für den Director das gleiche Passwort gesetzt sein, wie in der DirectorKonfigurationsdatei /etc//dir.conf bei der Definition des jeweiligen Clients. Konfiguration der Console Die Console regelt die Kommunikation zum Director. Die entsprechenden Optionen für diese Kommunikation werden in der Konfigurationsdatei /etc/bconsole.conf gesetzt. In unserem Fall sieht die Konfigurationsdatei folgendermaßen aus: Director { Name =.example.landir DIRport = 9101 address =.example.lan Password = "09876543210987654321098765432109876543210987" Anmerkung: diese Datei können wir im Großen und Ganzen ungeändert lassen. Der Hostname unseres BackupServers lautet.example.lan und wird automatisch in die Konfigurationsdatei eingefügt. Das hier gesetzte Passwort muss mit dem Passwort in der DirectorKonfigurationsdatei /etc/dir.conf im Block Director übereinstimmen. Kommunikation zwischen den einzelnen BaculaKomponenten In unserem Fall verwenden wir die Standard TCPPorts, die von den BaculaEntwicklern empfohlen werden: Director dir : Port 9101 FileDaemon fd : Port 9102 StorageDaemon sd : Port 9103 Sonstige Nacharbeiten Da wir ein sicheres BackupSystem anstreben, werden wir alle BaculaProzesse unter der UID und GID ausführen. Lediglich der FileDaemon Prozess muss als Root laufen, da dieser Prozess alle Dateien des zu sichernden Dateisystems lesen muss. Daher Seite 11

erstellen wir den Benutzer und die Gruppe mittels: # groupadd # useradd g d /var/lib/ c Bacula User s /bin/bash # passwd # chown root: /var/lib/ Außerdem benötigen wir das Verzeichnis /var/run/subsys, das für den Benutzer les und beschreibbar sein muss, da Bacula darin seine LockDatei des Subsystems während seiner Ausführung ablegt: # mkdir /var/run/subsys # chown R : /var/run/subsys Zudem müssen wir das Sicherungsverzeichnis anlegen und dem Benutzer und der Gruppe zuordnen: # mkdir /backup # chown R : /backup Anschließend benötigen wir eine entsprechende Logdatei, die vor dem ersten Starten der BaculaKomponenten vorhanden sein sollte: # touch /var/log/.log && chown : /var/log/.log Für die Sicherung des BaculaKatalogs werden die beiden Skripte /etc//make_catalog_backup und /etc//delete_catalog_backup benötigt (s. Jobdefinition für KatalogBackup). Diese müssen für den Systembenutzer ausführbar sein: # chown : /etc//make_catalog_backup /etc//delete_catalog_backup Installation des Bacula File Daemons auf dem Client Ist der Leser diesem Howto bis hierhin gefolgt, hat er nun ein System vor sich, das lediglich die Sicherung von lokalen Dateien ermöglicht, was natürlich relativ sinnfrei ist. In unserem Fall wollen wir externe Clients, wie bspw. Server, die extern gehostet werden, sichern. Dazu benötigen die Clients lediglich den FileDaemon fd, der entsprechend konfiguriert werden muss und der anschließend automatisch mit dem Director dir und dem StorageDaemon sd (beide auf unserem BackupServer bereits installiert) kommuniziert. Sind die Rechnerarchitekturen und die Betriebssysteme des BaculaServers und des zu sichernden Clients gleich, reicht es aus, das Binary /sbin/fd vom Server auf den Client samt der Konfigurationsdatei /etc//fd.conf auf den Client zu kopieren und diese Konfigurationsdatei anzupassen, sowie eine entsprechende ClientDefinition für diesen zu sichernden Client im Director in /etc//dir anzulegen. Unterscheiden sich entweder die Rechner in deren Architektur oder dem darauf Seite 12

laufenden Betriebssystem, müssen wir im Prinzip auf dem Client die gleichen Schritte durchführen, wie auf dem Server (Kompilierung der Sourcen), nur dass wir auf dem Client allein nur den FileDaemon fd kompilieren müssen. Im Folgenden gehe ich von einem Debian GNU/Linux 5.0 Lenny System als dem zu sichernden Client aus. In meinem, diesem Howto zugrudeliegenden Fall, handelt es sich um einen in einem entfernten Rechenzentrum gehosteten Server. Zunächst installieren wir eine entsprechende BuildUmgebung, um die Sourcen des Bacula FileDaemons (entspricht dem Client) kompilieren zu können: # aptitude install buildessential libssldev Anschließend laden wir den vollständigen Bacula Quellcode herunter und entpacken das Archiv: # cd /usr/local/src # wget wget http://downloads.sourceforge.net/project///5.0.3/5.0.3.tar.gz # tar xzvf 5.0.3.tar.gz # rm 5.0.3.tar.gz Nun wechseln wir in das soeben erstellte Verzeichnis /usr/local/src/5.0.3 und lassen darin zunächst das entsprechende Makefile für die Kompilierung des Bacula FileDaemons von unserem System erstellen: # cd 5.0.3 #./configure prefix=/usr sbindir=/usr/sbin sysconfdir=/etc/ withscriptdir=/etc/ enablesmartalloc withopenssl enableclientonly withworkingdir=/var/ withpiddir=/var/run withsubsysdir=/var/lock/subsys Anschließend liefert uns der ConfigureDurchlauf eine entsprechende Statusmeldung: Configuration on Sun Dec 12 10:07:08 CET 2010: Host: x86_64unknownlinuxgnu debian 5.0.3 Bacula version: Bacula 5.0.3 (18 October 2009) Source code location:. Install binaries: /sbin Install libraries: /usr/lib Install config files: /etc/ Scripts directory: /etc/ Archive directory: /tmp Working directory: /var//working PID directory: /var/run Subsys directory: /var/run/subsys Man directory: ${datarootdir/man Data directory: /usr/share Plugin directory: /usr/lib C Compiler: gcc 4.3.21.1) C++ Compiler: /usr/bin/g++ 4.3.21.1) Compiler flags: g O2 Wall fnostrictaliasing fnoexceptions fnortti Linker flags: Libraries: lpthread ldl Statically Linked Tools: no Statically Linked FD: no Statically Linked SD: no Statically Linked DIR: no Statically Linked CONS: no Database type: None Database port: Database lib: Database name: Database user: Job Output Email: root@localhost Traceback Email: root@localhost SMTP Host Address: localhost Director Port: 9101 File daemon Port: 9102 Storage daemon Port: 9103 Director User: Director Group: Storage Daemon User: Storage DaemonGroup: File Daemon User: File Daemon Group: SQL binaries Directory Large file support: yes Bacula conio support: yes ltermcap readline support: no TCP Wrappers support: no TLS support: yes Encryption support: yes ZLIB support: yes Seite 13

enablesmartalloc: yes enablelockmgr: no bat support: no enablegnome: no enablebwxconsole: no enabletraymonitor: no clientonly: yes builddird: yes buildstored: yes ACL support: no XATTR support: yes Python support: no Batch insert enabled: no Wir installieren nun den Bacula FileDaemon mittels: # make && make install Anschließend konfigurieren wir den FileDaemon, indem wir dessen Konfigurationsdatei /etc//fd.conf anpassen: *** TODO *** Auch hier benötigen wir das Verzeichnis /var/run/subsys. Dieses muss diesmal für Root les und beschreibbar sein, da wir den Bacula FileDaemon mit der UID root ausführen. In dieses Verzeichnis schreibt der Bacula FileDaemon fd seine LockDatei, während er ausgeführt wird: # mkdir /var/run/subsys Automatischer Start der Bacula Komponenten Nachdem wir Bacula soweit installiert und konfiguriert haben, müssen wir noch die Startskripte so verlinken, dass Bacula automatisch beim Starten des Servers mitgestartet wird. Dazu wurden bei der Installation von Bacula die folgenden InitSkripte automatisch im Verzeichnis /etc// abgelegt: ctldir : steuert den DirectorDaemon ctlsd : steuert den StorageDaemon ctlfd : steuert den FileDaemon InitSkripte auf dem Server Um die Dienste unserem InitSystem hinzuzufügen kopieren wir zunächst die einzelnen Skripte in das Verzeichnis /etc/init.d # cp /etc//ctldir /etc/init.d/dir # cp /etc//ctlsd /etc/init.d/sd # cp /etc//ctlfd /etc/init.d/fd... und machen sie ausführbar: # chmod 755 /etc/init.d/* Anschließend fügen wir die Dienste in unser InitSystem ein: # updaterc.d sd defaults 90 # updaterc.d fd defaults 91 # updaterc.d dir defaults 92 InitSkripte auf dem Client Da auf dem Client lediglich der FileDaemon seinen Dienst verrichtet, muss auch nur dessen InitSkript an die richtige Stelle kopiert und dort aktiviert werden: Seite 14

# cp /etc//ctlfd /etc/init.d/fd # chmod 755 /etc/init.d/fd Anschließend fügen wir den FileDaemon unserem InitSystem hinzu: # updaterc.d fd defaults 90 Überprüfen des Bacula Setups Nachdem wir sowohl den Server als auch den BaculaClient konfiguriert haben, überprüfen wir das Setup, indem wir zunächst, falls nicht bereits geschehen, alle BaculaKomponenten auf dem Server aufrufen: # /etc/init.d/sd start # /etc/init.d/fd start # /etc/init.d/dir start Zudem starten wir den FileDaemon auf dem zu sichernden Client: # /etc/init.d/fd start Anschließend rufen wir die Console bconsole auf dem BaculaServer auf: # bconsole Daraufhin präsentiert uns die Bacula Console einen entsprechenden Prompt: Connecting to Director localhost:9101 1000 OK: backupdir Version: 2.4.4 (28 December 2008) Enter a period to cancel a command. * Ich werde im nächsten Abschnitt die Arbeit mit der Bacula Console und die wichtigsten Kommandos erläutern. Dennoch verwenden wir bereits hier bconsole, um unser gesamtes Setup einmal zu validieren. Dabei reichen uns die folgenden bconsole Kommandos: list clients : listet alle in der Konfiguration des Directors definierten Clients auf. status client : zeigt den Status der einzelnen Clients an. Hierbei verbindet sich bconsole via Director mit den FileDaemons der jeweiligen ClientRechner. An dieser Stelle darf es zu keinen Verbindungsproblemen kommen, da sonst auch das Backup dieser Clients fehlschlägt. Firewall / NAT zwischen dem Storage Daemon und remote Clients Nicht selten wird ein BackupServer im LAN aufgesetzt, um entfernte Clients zu sichern, wie bspw. Server, die bspw. in einem externen Rechenzentrum ihren Dienst verrichten. Das Setup, wie es oben beschrieben ist, läßt sich problemlos auf das Backup von Clients anwenden, bei den kein NAT in die Kommunikation involviert ist. Dabei können die einzelnen Module auf verschiedenen Servern laufen, müssen aber über statische IP s verfügen (kein NAT). Leider bereitet NAT, wie bei vielen anderen Diensten, auch hier einige Probleme. So bekommt bspw. der entfernte File Daemon die lokale IPAdresse des StorageDaemons geliefert und versucht sich mit diesem zu verbinden. Aufgrund der IPAdresse aus einem privaten IPAdresspool scheitert jedoch diese Verbindung. Der typische Datenfluss bei einer BaculaInstallation, bei der ein entfernter Client gesichert werden soll, sieht folgendermaßen aus: bc(code) Catalog (RDBMS) ^ Console > Director <> Storage Daemon > physikalischer Speicher (Port 9101) (Port 9103) (HDD, AIT, LTO etc.) ^ =========================================== Firewall / NAT v File Daemon (Port 9102) Wichtig: bevor wir weiter verfahren, müssen wir zunächst von unserer Firewall den Port 9103 auf unseren BaculaServer weiterleiten lassen. Um die Problematik des Mixes aus öffentlichen und privaten IPAdressen in einem BaculaSetup darzustellen, rufen wir auf dem entfernten, zu sichernden Client tcpdump auf: # tcpdump port 9103 Anschließend starten wir auf dem BackupServer einen Sicherungslauf, indem wir in der Bacula Console run aufrufen und den entsprechenden Client auswählen. Daraufhin sollte der Durchlauf von tcpdump uns die folgende Ausgabe liefern: Seite 15

14:42:18.599466 IP 81.211.22.97.44312 > 192.168.1.40.sd: S 1887049424:1887049424(0) win 5840 <mss 1460,sackOK,timestamp 139093572 0,nop,wscale 7> Daran erkennen wir, dass der entfernte File Daemon mit der öffentlichen IPAdresse 81.211.22.97 versucht, sich mit der privaten IPAdresse 192.168.1.40` zu verbinden. Dieser Verbindungsaufbau ist natürlich zum Scheitern verurteilt Arbeiten mit der Bacula Console bconsole Wir ich bereits oben beschrieben habe, stellt die CLIAnwendung bconsole eine mögliche Schnittstelle zwischen dem Bacula Director und dem Systemadministrator bzw. dem Benutzer dar. Daneben existieren einige weitere bspw. auf QT oder wxwidgets basierenden Steuerungsapplikationen. Wie so oft, gilt jedoch die CLIVersion bconsole als Referenzimplementierung, da sie u.a. alle Features von Bacula unterstützt. Bconsole verfügt über eine Vielzahl von Kommandos. Die wichtigsten dieser Kommandos möchte ich an dieser Stelle erläutern. Da alle Bacula Komponenten über IP miteinander kommunizieren, ist es an nicht notwendig, dass die Console auf dem gleichen Rechner ausgeführt wird, auf dem der Director seinen Dienst verrichtet. Anmerkung: viele der unten aufgelisteten Kommandos können mit Parametern versehen werden. Wird kein Parameter übergeben, fragt die Bacula Console nach den fehlenden Parametern, indem sie dem Benutzer eine Vorauswahl in Form eines Menüs präsentiert. Eine genaue Auflistung aller Optionen mit den entsprechenden Parametern finden wir unter http://www..org/de/devmanual/bacula_console.html. Steuerung von Jobs cancel jobid=xxx : bricht den Job mit der ID xxx ab. Nach Ausführung dieses Kommandos kann es u.u. zu einer Verzögerung von bis zu einer Minute kommen, bis der Job tatsächlich abgebrochen wird. delete JobId=xxx : löscht einen JobEintrag aus der KatalogDatenbank samt den zu dem Job zugehörigen JobMedia und DateiEinträgen. disable job : verhindert die automatische, in der Konfiguration des Directors definierte, Ausführung eines bestimmten Jobs. Das Kommando verliert nach Neustart des Directors seine Wirkung. enable job : ein durch disable deaktivierter Job wird wieder aktiviert estimate : zeigt an, wieviel Dateien und welche Datenmenge mittels eines bestimmten Jobs beim nächsten Ausführen dieses Jobs gesichert würden. Dabei wird der eigentliche Job nicht ausgeführt. Wird als Parameter zusätzlich listing angegeben, liefert das Kommando zusätzlich das Listing aller Dateien, die gesichert würden. list jobs : zeigt alle angelegten Jobs an (Ausgabe wird aus der KatalogDatenbank generiert). run : fügt Jobs in den Zeitplan des Directors ein, die sofort ausgelöst werden. Diese Kommando sollte auf jeden Fall zum Testen der einzelnen Jobs verwendet werden. Sonstige Kommandos Seite 16

help : zeigt die Hilfe mit einer Kurzbeschreibung der Befehle an list clients : zeigt alle in der Konfiguration des Directors definierten BaculaClients an (Ausgabe wird aus der KatalogDatenbank generiert). show clients : liefert Informationen über alle in allen KatalogDatenbanken (falls vorhanden) definierten Clients. Zusätzlich zu den in list clients enthaltenen Informationen liefert er weitere Charakteristika der Clients, wie bspw. deren IPAdresse und den FDPort. status client : zeigt den Status aller in der Konfiguration des Directors definierten Clients an. Zudem wird eine Verbindung zu diesen aufgebaut und deren Erreichbarkeit quittiert. messages : viele Kommandos generieren Benachrichtigungen, die per Default nicht direkt ausgegeben, sondern in einem Puffer gespeichert werden. Dieses Kommandos gibt diese auf dem Bildschirm wieder und leert den Puffer. reload : läßt den Director dessen Konfiguration neu einlesen, bspw. wenn diese manuell geändert wurde. Da das Einlesen der Konfiguration sehr komplex ist, empfiehlt es sich anschließend den Director neu zu starten ( /etc/init.d/dir restart ) show filesets : zeigt alle in der Konfiguration des Directors festgelegten FileSets an. Diese beinhalten insbesondere Ein und Ausschlussdefinitionen der Dateien/Ordner, die gesichert werden sollen (Includes und Excludes). Verlassen von bconsole quit bzw. exit : schließt die Console, nachdem der Director dieses Kommando quittiert hat.quit bzw..exit : schließt die Console sofort. : bricht die aktuelle Eingabe ab und führt zum Hauptmenü Bedeutung der Statuscodes JobStatus C R B T E e f D A F S m M s Created, not yet running Running Blocked Completed successfully Terminated with errors Nonfatal error Fatal error Verify found differences Canceled by user Waiting for Client Waiting for Storage daemon Waiting for new media Waiting for media mount Waiting for storage resource Seite 17

j c d t p a i Waiting for job resource Waiting for client resource Waiting on maximum jobs Waiting on start time Waiting on higher priority jobs SD despooling attributes Doing batch insert file records Reinitialisierung des BaculaSetups Sollten wir mit Bacula zunächst viele Testläufe initiiert haben (bspw. das Anlegen und Löschen von Jobs), so wird jede Aktion in der KatalogDatenbank des Directors gespeichert. In vielen Fällen möchte man aber eine solche Historie vor der eigentlichen produktiven Inbetriebnahme des BackupServers vollständig löschen. Dazu bietet Bacula die Reinitialisierung der PostgreSQLDatenbank (und auch von MySQL bzw. SQLite, falls diese verwendet werden). Dazu fahren wir zunächst den Bacula FileDaemon, den StorageDaemon und den DirectorDaemon herunter und beenden die BaculaWeboberfläche bweb, falls wir diese, wie [4]hier beschrieben, installiert haben sollten: # /etc/init.d/fd stop # /etc/init.d/sd stop # /etc/init.d/dir stop # killall lighttpd Anschließend verwerfen wir alle bestehenden Datenbanktabellen (Achtung: hierbei gehen alle in dem Katalog enthaltenen Informationen verloren!) und säubern das System von vorhandenen Backupdateien, Log und PIDDateien etc.: # su postgres $ dropdb $ exit # rm rf /backup/* # rm rf /var/lib//* Anschließend generieren wir die Datenbank neu und initialisieren diese mittels: # su postgres $ cd /etc/ $./create database $./make tables $./grant privileges Sollten wir im Verlauf dieses Howtos die BaculaWeboberfläche bweb installiert haben (wie bereits in einem [5]anderen Howto von mir ausführlich beschrieben.), führen wir zudem die folgenden beiden Kommandos aus: $ psql < /var/www/gui/bweb/script/bwebpostgresql.sql $./extend_postgresql_privileges $ exit Anschließend starten wir die BaculaKomponenten neu mittels: # /etc/init.d/fd start # /etc/init.d/sd start # /etc/init.d/dir start Sollten wir an dieser Stelle bweb bereits installiert haben, starten wir die WebGUI mittels: # /var/www/gui/bweb/script/starthttp Da jede BaculaInstallation erahrungsgemäß eine Vielzahl von Testläufen mit sich bringt, verwenden wir ein einfaches ShellSkript _reinit.sh, das alle obigen Schritte automatisiert: #!/bin/sh /etc/init.d/fd stop && sleep 5 /etc/init.d/sd stop && sleep 5 /etc/init.d/dir stop && sleep 5 killall lighttpd su postgres c "dropdb " && sleep 5 rm rf /backup/* && sleep 5 rm rf /var/lib//backup* /var/lib//* && sleep 5 su postgres c "/etc//create database" && sleep 5 su postgres c "/etc//make tables" && sleep 5 su postgres c "/etc//grant privileges" && sleep 5 su postgres c "psql < /var/www/gui/bweb/script/bwebpostgresql.sql" && sleep 5 Seite 18

su postgres c "/etc//extend_postgresql_privileges" && sleep 5 /etc/init.d/fd start && sleep 5 /etc/init.d/sd start && sleep 5 /etc/init.d/dir start && sleep 5 /var/www/gui/bweb/script/starthttp [1] http://www.asconix.com/howtos/debian/rsyncbackupdebianhowto [2] http://www.asconix.com/howtos/debian/bwebinterfacedebianhowto [3] http://www.asconix.com/howtos/debian/postgresqldebianhowto [4] http://www.asconix.com/howtos/debian/bwebinterfacedebianhowto [5] http://www.asconix.com/howtos/debian/bwebinterfacedebianhowto Problem (öffentlich) Lösung (öffentlich) Seite 19