Hallo Liste!
Ich habe ein Debian-Etch mit Xen am laufen. Darauf laufen 8 Xen-Domains, was dank Xen auch auf 1GB RAM recht performant ist. Als Backup-Lösung fahre (bzw. plane) ich ein gemischtes Konzept:
1. Die virtuellen Maschinen werden nachts heruntergefahren, deren Root-FS in in gzip-tes Tar geworfen und anschließend wieder gestartet. Anschließend zieht sich der Backup-Server die Images 2. Der Fileserver (selbst auch eine Xen-Domain) hat seine Daten auf einer "durchgeschleiften" physischen Partition. Dieses FS soll per Bacula auf einen abgesetzten (Backup-)Server gesichert werden. Ebenso werden Windoof-Clients per Bacula gesichert.
zu 1. Sicherlich gibt es bessere Konzepte, als die gesamte "VM" abzuziehen, aber auf diese Art hab ich wenigstens die Gewissheit, dass ich nur das FS zurücksichern muss und die "VM" läuft wieder auf dem alten Stand, was mir schon öfter den Hals gerettet hat. Nur hat diese Methode einen Nachteil: Es landen auch immer eigentlich schön gelöschte Blöcke des FS im Backup. Ein Workarround, den ich auch derzeit schon einsetze, ist, vor dem Backup innerhalb der "VM" per cronjob ausführen: dd if=/dev/zero of=/tmp/test;rm /tmp/test Dies "nullt" die unbelegten Blöcke. Allerdings wäre eine Lösung, die tatsächlich unbelegte Blöcke ohne den Umweg über eine Ballon-Datei entfernt, besser. Gibt's da irgendein Tool für? Was ich bislang gefunden habe, waren nur Lösungen, die unbelegte Blöcke (mehrfach) mit Zufallsdaten überschreiben - dass würde allerdings genau in die falsche Richtung schießen, da sich Zufallsdaten so gut wie gar nicht komprimieren lassen. zu 2. Ich habe mich nach OS-Backup-Lösungen umgesehen und mir erschien Bacula als hoffnungsvoll, u.a. deshalb, weil es auch Windoofs-Clients mit VSS abziehen kann. Ich habe eine Quelle für Etch-Backports von Bacula gefunden: deb http://packman.inode.at/debian/ etch addons updates aus denen man eine Version 2.2.5 installieren kann, Etch enthält nur 1.38. Leider klappt die Installation nicht so, wie sie soll, zumindest wenn man MySQL verwenden möchte statt SQLite. Hat jemand Erfahrung, wie man die Datenbanken nachträglich erzeugt? Das automatische Anlegen innerhalb der Pakete funktioniert jedenfalls nicht. Die Scripte, die die Datenbank anlegen sollten, laut einigen HowTos, sind nicht zu finden. *.SQL-Dateien hab ich auch keine gefunden, also woher die Struktur der Datenbank nehmen?!
Für Hilfe wäre ich sehr dankbar
Gruß Thomas
Hi Thomas,
- Die virtuellen Maschinen werden nachts heruntergefahren, deren
Root-FS in in gzip-tes Tar geworfen
Zur Uptimeerhöhung die VM stoppen, Daten kopieren, VM starten und erst nachher Daten komprimieren.
Achtung - das kann dauern! Soll das jeden Tag laufen? Wie groß sind die FS etwa? Ist Speicherplatz knapp? Falls es sehr viele Daten sein sollten lohnt es sich evtl. auf dem Bacula-Backup-Server die Daten auch nochmal auf HD vorrätig zu halten und neue Backups via rsync von dem Xen-Backup-Server zu holen (dann werden nur die Daten übertragen, die sich geändert haben. Ich sichere 60 GB über ein DSL-1000-Verbindung auf einen Athlon 1,4 GHz, dauert jede Woche ca. 3 h bei nicht allzuvielen Änderungen, davon allerdings welche in einem VMware-HD-Image von 20 GB)
gestartet. Anschließend zieht sich der Backup-Server die Images
HD-Images oder .tar.gz?
mfg, Fabian
Danke für deine Antwort!
Fabian Hänsel schrieb:
Zur Uptimeerhöhung die VM stoppen, Daten kopieren, VM starten und erst nachher Daten komprimieren.
Guter Tipp, muss ich probieren was schneller ist. Die beteiligten Platten hängen leider an einem IDE-Channel, daher tut es gut, wenn sie gelesen, komprimiert und dann geschrieben werden, weil dass den IDE-Bus weniger stark belastet, kommt also auf den Versuch an. Allerdings spielt Uptime keine so große Rolle, hätte für Sicherungen quasi die ganze Nacht Zeit (sagen wir 0-6 Uhr). Nach der bisherigern Methode dauert das Backup aller VM's ca. 1 Stunde.
Achtung - das kann dauern! Soll das jeden Tag laufen? Wie groß sind die FS etwa? Ist Speicherplatz knapp?
Die Root-FS der 8 VMs sind zusammen etwas 20 GB groß. Zum genauen Zeitplan habe ich mir erstmal keine Gedanken gemacht (um noch Optimierungspotential zu lassen ;-) ), wollte erstmal täglich die Root-FS abziehen und vom Fileserver täglich eine inkrementelle Sicherung. Der Fileserver hält ca. 250 GB Dateien, von denen sich am Tag geschätzt maximal 1 GB ändern. Zum Sichern habe ich ca. 400 MB, daher sollten sich auch einige Generationen aufbewahren lassen.
Falls es sehr viele Daten sein sollten lohnt es sich evtl. auf dem Bacula-Backup-Server die Daten auch nochmal auf HD vorrätig zu halten und neue Backups via rsync von dem Xen-Backup-Server zu holen (dann werden nur die Daten übertragen, die sich geändert haben. Ich sichere 60 GB über ein DSL-1000-Verbindung auf einen Athlon 1,4 GHz, dauert jede Woche ca. 3 h bei nicht allzuvielen Änderungen, davon allerdings welche in einem VMware-HD-Image von 20 GB)
Sorry, hatte ich nicht erwähnt: Die Daten sollen auf dem Backup-Server ausschließlich auf HD gesichert werden, nach dem Prinzip, dass zwei Platten an getrennten Orten nicht an einem Tag kaputt gehen. Natürlich ist das nicht perfekt, ist aber eine Budgetfrage, Bandlaufwerke sind nicht drin. Der Sicherungsspeed ist 100 MBit Ethernet, die beiden Standorte sind in einem Gebäude, aber andere "Brandschutzzelle". Allerdings ist die eine Kiste (Der Server) nur ein Dual P III mit 866 MHz und der Backup-Server nur ein 666MHZ Via-C3 (gefühlte Performance P II 350MHz), weshalb von den 100 MBit maximal 50 übrigbleiben. Die komprimierten Images sind ca. 10 GB groß. Sie landen auf einer extra Platte, daher kann sich der Sicherungsserver Zeit lassen, sie zu ziehen, selbst wenn das dann nach 6 Uhr sein sollte. Wenn du auch VMs als Image sicherst, dann kennst du doch bestimmt das Problem auch, dass sich die Sicherungen immer mehr aufblähen, obwohl die Belegung innerhalb der VM nicht zunimmt. Dabei spielt es ja keine Rolle, ob VMWare oder Xen. Was machst du dagegen?
gestartet. Anschließend zieht sich der Backup-Server die Images
HD-Images oder .tar.gz?
mit Images meinte ich die .tar.gz der Root-FS, die sind "bereinigt" zusammen kleiner als 10 GB
Hast du schon Erfahrungen mit Bacula? Welche Version setzt du ein? Hast du das Web-Frontend zum Laufen gebraucht?
Danke schonmal im Voraus
MfG Thomas
Hi Thomas,
Fabian Hänsel schrieb:
Zur Uptimeerhöhung die VM stoppen, Daten kopieren, VM starten und erst nachher Daten komprimieren.
Guter Tipp, muss ich probieren was schneller ist. Die beteiligten Platten hängen leider an einem IDE-Channel, daher tut es gut, wenn sie gelesen, komprimiert und dann geschrieben werden, weil dass den IDE-Bus weniger stark belastet, kommt also auf den Versuch an.
Komprimieren frisst eigentlich nicht viel Übertragungskapazität (zumindest solange die CPU nicht sehr, sehr schnell und die HDs sehr, sehr langsam sind) - kann aber störend sein, wenn die laufenden VMs oft auf die HD zugreifen und die HD dann ständig seekt statt hohe Datenraten zu liefern.
Allerdings spielt Uptime keine so große Rolle, hätte für Sicherungen quasi die ganze Nacht Zeit (sagen wir 0-6 Uhr). Nach der bisherigern Methode dauert das Backup aller VM's ca. 1 Stunde.
Achtung - das kann dauern! Soll das jeden Tag laufen? Wie groß sind die FS etwa? Ist Speicherplatz knapp?
Die Root-FS der 8 VMs sind zusammen etwas 20 GB groß. Zum genauen Zeitplan habe ich mir erstmal keine Gedanken gemacht (um noch Optimierungspotential zu lassen ;-) ), wollte erstmal täglich die Root-FS abziehen und vom Fileserver täglich eine inkrementelle Sicherung. Der Fileserver hält ca. 250 GB Dateien, von denen sich am Tag geschätzt maximal 1 GB ändern. Zum Sichern habe ich ca. 400 MB, daher sollten sich auch einige Generationen aufbewahren lassen.
Sorry, hatte ich nicht erwähnt: Die Daten sollen auf dem Backup-Server ausschließlich auf HD gesichert werden, nach dem Prinzip, dass zwei Platten an getrennten Orten nicht an einem Tag kaputt gehen.
Hab ich schon erlebt. Platte in Rechner A fängt an zu sterben. Besitzer von A schaufelt all seine Daten auf die HD von Freund B. Einen Tag später hatten sie beide keine Daten mehr. Ist statistisch unwahrscheinlich, aber möglich.
Sicherung. Der Fileserver hält ca. 250 GB Dateien, von denen sich am
Ok, da ist nix mehr mit DVDs. (ich hab bei mir ein 3-Stufen-System. S0: die Daten selbst auf dem Server, S1 (online): wöchentlich Backup via Internet auf einen anderen Rechner, S2: monatlich externe USB-HD, S3: halbjährlich DVD-Backup). Alle vier Sachen sind geografisch über Dresden verteilt ;-) Unter (unrealistischen) Optimalbedingungen (USB-HD + Admin ist im Büro, während der Server aussteigt) können wir binnen 3h (in der er 2,5h einfach vor sich hin kopiert) wieder online gehen (0,5h für Installation von VMware auf einer Ersatzkiste). Insgesamt alles sehr einfach gestrickt, aber angenehm leistungsfähig (aber andere Ansprüche/Größenordnungen erfordern andere Lösungen).
Je nach Wert der Daten solltet ihr wohl mal über ein Bandlaufwerk nachdenken - oder darüber ob es schlimmer ist, wenn jemand immer mal wieder den halben Tag mit DVDs brennen/wechseln zubringt, oder Datenverlust mit $Auswirkung. Es ist eine stupide Arbeit, aber wenn es doch einmal passiert wird man sich freuen, sie gemacht zu haben ;-)
andere "Brandschutzzelle". Allerdings ist die eine Kiste (Der Server) nur ein Dual P III mit 866 MHz und der Backup-Server nur ein 666MHZ Via-C3 (gefühlte Performance P II 350MHz), weshalb von den 100 MBit maximal 50 übrigbleiben.
Vom Prozessor her sollten beide Kisten _locker_ 100 MBit schaffen. Sowas ist eigentlich ein Zeichen für minderwertige Ethernetchipsätze (oft onboard, habe selbst Realtek als PCI-Karte, frisst viel CPU, z.B. Intelkarten sind zwar teurer, hier auch spürbar besser). Frage ist natürlich, ob eine Verbesserung d. Ethernetspeeds ggf. neue Karten überhaupt wert wäre. (Noch ein Gedanke: Miss mal mit "schnellen Rechnern", ob die Route 100 MBit überhaupt hergibt - ist evtl. ein Router noch mit anderen Sachen beschäftigt und daher klemmt es dort?)
Die komprimierten Images sind ca. 10 GB groß. Sie landen auf einer extra Platte, daher kann sich der Sicherungsserver Zeit lassen, sie zu ziehen, selbst wenn das dann nach 6 Uhr sein sollte. Wenn du auch VMs als Image sicherst, dann kennst du doch bestimmt das Problem auch, dass sich die Sicherungen immer mehr aufblähen, obwohl die Belegung innerhalb der VM nicht zunimmt. Dabei spielt es ja keine Rolle, ob VMWare oder Xen. Was machst du dagegen?
Da mir das komprimieren zu lange dauert und ich ausreichend große HDs habe mache ich es mir einfach und komprimiere sie gar nicht. Das macht auch das Onlinebackup via rsync erst sinnvoll möglich. (Außer halbjährlich fürs DVD-Backup, aber auch da unternehme ich bisher nichts gegen das "Wachstum durch Gelöschtes" - deinen Tipp zum "Vollnullen" werde ich dafür übernehmen, auf die Idee bin ich noch nicht gekommen, besten Dank)
Hast du schon Erfahrungen mit Bacula? Welche Version setzt du ein? Hast du das Web-Frontend zum Laufen gebraucht?
Bei mir laufen ein paar Skripte (10 Zeiler), die nur rsync in geeigneter Weise aufrufen. (Und andernorts ein NetVault, aber das ist eine andere Kategorie)
Als ich vor einigen Monaten mal nach einem OS-Backup-Tool für meinen Rechnerzoo geschaut habe erschien mir auch Bacula am geeignetsten für die Größenordnung von 10 Rechnern.
mfg, Fabian
Thomas Lindner schrieb:
Hallo Liste!
Hi,
Ich habe ein Debian-Etch mit Xen am laufen. Darauf laufen 8 Xen-Domains, was dank Xen auch auf 1GB RAM recht performant ist. Als Backup-Lösung
cool.
fahre (bzw. plane) ich ein gemischtes Konzept:
- Die virtuellen Maschinen werden nachts heruntergefahren, deren
Root-FS in in gzip-tes Tar geworfen und anschließend wieder gestartet. Anschließend zieht sich der Backup-Server die Images 2. Der Fileserver (selbst auch eine Xen-Domain) hat seine Daten auf einer "durchgeschleiften" physischen Partition. Dieses FS soll per Bacula auf einen abgesetzten (Backup-)Server gesichert werden. Ebenso werden Windoof-Clients per Bacula gesichert.
Wenn die Downtime keine Rolle spielt, ist das kein Problem. Ich mag diesen Ansatz aber nich :)
zu 1. Sicherlich gibt es bessere Konzepte, als die gesamte "VM" abzuziehen, aber auf diese Art hab ich wenigstens die Gewissheit, dass ich nur das FS zurücksichern muss und die "VM" läuft wieder auf dem alten Stand, was mir schon öfter den Hals gerettet hat. Nur hat diese Methode einen Nachteil: Es landen auch immer eigentlich schön gelöschte Blöcke des FS im Backup. Ein Workarround, den ich auch derzeit schon einsetze, ist, vor dem Backup innerhalb der "VM" per cronjob ausführen: dd if=/dev/zero of=/tmp/test;rm /tmp/test Dies "nullt" die unbelegten Blöcke. Allerdings wäre eine Lösung, die tatsächlich unbelegte Blöcke ohne den Umweg über eine Ballon-Datei entfernt, besser. Gibt's da irgendein Tool für? Was ich bislang gefunden habe, waren nur Lösungen, die unbelegte Blöcke (mehrfach) mit Zufallsdaten überschreiben - dass würde allerdings genau in die falsche Richtung schießen, da sich Zufallsdaten so gut wie gar nicht komprimieren lassen.
Das kann man doch sicher in den Sourcen umbiegen ;)
Ich verwende bacula-fd in den VMs. Es erlaubt mir auf dem Client im Backupprozess div Skripte auszufuehren (DB abziehen, File listen erstellen etc)
Die andere Variante waer LVM snapshotten und dann das Snapshot-device, mounted oder raw sichern. Wie sinnvoll das ist, haengt von vielen Faktoren ab. Das geht dann ohne Eingriffe in den Host.
zu 2. Ich habe mich nach OS-Backup-Lösungen umgesehen und mir erschien Bacula als hoffnungsvoll, u.a. deshalb, weil es auch Windoofs-Clients mit VSS abziehen kann. Ich habe eine Quelle für Etch-Backports von Bacula gefunden: deb http://packman.inode.at/debian/ etch addons updates aus denen man eine Version 2.2.5 installieren kann, Etch enthält nur 1.38. Leider klappt die Installation nicht so, wie sie soll, zumindest wenn man MySQL verwenden möchte statt SQLite.
Hat hier super funktioniert immer. Ich nehm allerdings nicht das metapaket "bacula" sondern installier die noetigen Sachen einzeln. Es wird glaub ich das dbconfig interface bei der Installation verwendet. Benutz ich jedoch nicht.
Hat jemand Erfahrung, wie man die Datenbanken nachträglich erzeugt? Das automatische Anlegen innerhalb der Pakete funktioniert jedenfalls nicht. Die Scripte, die die Datenbank anlegen sollten, laut einigen HowTos, sind nicht zu finden. *.SQL-Dateien hab ich auch keine gefunden, also woher die Struktur der Datenbank nehmen?!
Das Schema kannste mit /usr/share/bacula-director/make_mysql_tables (wenn man den passenden Director installiert hat, hier bacula-director-mysql) erzeugen.
Für Hilfe wäre ich sehr dankbar
Ich sichere die OS Daten der VMs auf Disk. Es sind 30 Diskfiles, taeglich eins im Backupsystem rotiert. Ich ziehe das OS immer komplett ab. Die anwendungsspezifischen Daten werden separat auf Tape gesichert. Als Tape Device geht hier eine HP DDS4 Tapelib mit 6 Slots. Die Tapes werden 1 Jahr lang aufbewahrt und dann im Backupsystem recycled. Die Sicherung erfolgt wie ueblich nach dem GFS Schema, also taeglich inkrementell, jeden Freitag differentiell und jeden 1. Freitag des Monats vollstaendig. So habe ich jeden Monat einen Abzug der Anwendungsdaten. Das OS ist eh nicht so wichtig, denn da aendert sich nicht allzu viel, es ist via FAI schnell wieder installiert, die letzte oder vorletzte Kopie des /etc Verzeichnisses reichte in den allermeisten Notfaellen bisher.
Gruß Thomas
MfG -Dimitri Puzin aka Tristan-777
Hallo Fabian!
Komprimieren frisst eigentlich nicht viel Übertragungskapazität (zumindest solange die CPU nicht sehr, sehr schnell und die HDs sehr, sehr langsam sind) - kann aber störend sein, wenn die laufenden VMs oft auf die HD zugreifen und die HD dann ständig seekt statt hohe Datenraten zu liefern.
Eigentlich ist Nachts alles im Leerlauf, solange keine Cronjobs dazwischenfunken sollten die Platten auschließlich mit dem Backup beschäftigt sein.
Hab ich schon erlebt. Platte in Rechner A fängt an zu sterben. Besitzer von A schaufelt all seine Daten auf die HD von Freund B. Einen Tag später hatten sie beide keine Daten mehr. Ist statistisch unwahrscheinlich, aber möglich.
Ja, soll vorkommen, zumal ja dann beide Platten ordentlich zu schuften haben. Ist gar nicht so selten, passiert öfter an RAID5: wenn die Hotspare einspringt, gibt manchmal auch noch eine zweite RAID-Platte während des Rebuild auf. Für ganz vorsichtige gibt's dann ja noch RAID6. ;-)
Vom Prozessor her sollten beide Kisten _locker_ 100 MBit schaffen. Sowas ist eigentlich ein Zeichen für minderwertige Ethernetchipsätze (oft onboard, habe selbst Realtek als PCI-Karte, frisst viel CPU, z.B. Intelkarten sind zwar teurer, hier auch spürbar besser). Frage ist natürlich, ob eine Verbesserung d. Ethernetspeeds ggf. neue Karten überhaupt wert wäre. (Noch ein Gedanke: Miss mal mit "schnellen Rechnern", ob die Route 100 MBit überhaupt hergibt - ist evtl. ein Router noch mit anderen Sachen beschäftigt und daher klemmt es dort?)
Hab's jetzt mal wissen wollen: Eine Seite: backup:~# nc -l -p 9000 | dd of=/dev/zero Andere Seite: root@xen:~ # dd if=/dev/zero bs=1M count=1024 | nc backup 9000 hat 91 Sekunden gedauert, was 11,25 MB/s "Rohdurchsatz" ergibt. Die Strippe ist also besser, als ich dachte. Auf der einen Seite (Host Xen) arbeitet ein e100 (onboard), auf der anderen (Host Backup) ein 8139cp (onboard). Allerdings habe ich auch schon die Erfahrung gemacht, dass Intel-Karten an schlechten Verkabelungen schwächeln (zyklische Meldung: "Netzwerkkabel wurde entfernt" unter Windoof und misester Durchsatz), ein schnöder nforce2-onboard Chip aber problemlos läuft. Die CPU-Belastung ist natürlich weit geringer mit Intel-Chipsatz, keine Frage. Werde mal bei Gelegenheit mit einem Intel-Chipsatz auf beiden Seiten probieren, aber der Aufwand ist immer doof: Rechner abbauen, hochtragen, anschließen, dann das ganze vice versa und vielleicht nochmal von vorn, weil was vergessen ;-). Das Ding läuft nämlich "Headless", da geht nur Strom und Ethernet rein.
Da mir das komprimieren zu lange dauert und ich ausreichend große HDs habe mache ich es mir einfach und komprimiere sie gar nicht. Das macht auch das Onlinebackup via rsync erst sinnvoll möglich. (Außer halbjährlich fürs DVD-Backup, aber auch da unternehme ich bisher nichts gegen das "Wachstum durch Gelöschtes" - deinen Tipp zum "Vollnullen" werde ich dafür übernehmen, auf die Idee bin ich noch nicht gekommen, besten Dank)
Wenn aber gerade in dem Moment, da dd die letzen Bytes belegt, von irgendeinem Prozess auch Speicherplatz angefordert wird, geht das in die Hose, daher gefällt mir das noch nicht so richtig. Ich probiere gerade, mein Backup-Script folgendermaßen umzuschreiben:
1. Ein neuer Container in der Größe des alten wird mittels dd aus /dev/zero neu angelegt 2. VM wird heruntergefahren 3. altes und neues FS werden gemountet 4. Daten werden mittels cpio von alt nach neu kopiert 5. altes und neues FS werden ausgehangen 6. VM wird wieder gestartet 7. Neues FS wird in tar.gz komprimiert
Allerdings finde ich das ziemlich mit heißer Nadel gestrickt, werde das mal vorsichtig antesten, eventuell für eine Übergangszeit alle Files mit md5sum prüfen, bzw. eine rekursives diff laufen lassen, mal sehen In dem Zusammenhang eine Script-Frage: wie bekomme ich die Größe der alten Container-Datei so raus, dass ich sie als "count="-Parameter an dd übergeben kann?
Danke schon im Voraus, jetzt aber erst mal:
Frohe Weihnachten!
MfG Thomas
Dimitri Puzin schrieb:
Hat hier super funktioniert immer. Ich nehm allerdings nicht das metapaket "bacula" sondern installier die noetigen Sachen einzeln. Es wird glaub ich das dbconfig interface bei der Installation verwendet. Benutz ich jedoch nicht.
Hab jetzt auch mal dbconfig weggelassen, aber trotzdem Fehlermeldungen, irgendwas mit "@archivdir@" ... Archive Device = @archivedir@ ... Muss ich da vor der Installation noch irgendwelche Environment-Variablen setzen? Ich denke ja eher, dass bei der Konfig der Parameter nicht abgefragt wird. Dadurch schlägt die automatische Konfiguration von den beiden Paketen bacula-sd-mysql und bacula-director-mysql fehl. .
Das Schema kannste mit /usr/share/bacula-director/make_mysql_tables (wenn man den passenden Director installiert hat, hier bacula-director-mysql) erzeugen.
Hat geklappt, danke für den Hinweis. Ist Damit auch bacula-sd-mysql erledigt?
Das Web-Frontend verwendest du nicht, oder?
Frohe Weihnachten wünsch ich!
MfG Thomas
Thomas Lindner schrieb:
Dimitri Puzin schrieb:
Hat hier super funktioniert immer. Ich nehm allerdings nicht das metapaket "bacula" sondern installier die noetigen Sachen einzeln. Es wird glaub ich das dbconfig interface bei der Installation verwendet. Benutz ich jedoch nicht.
Hab jetzt auch mal dbconfig weggelassen, aber trotzdem Fehlermeldungen, irgendwas mit "@archivdir@" ... Archive Device = @archivedir@ ... Muss ich da vor der Installation noch irgendwelche Environment-Variablen setzen? Ich denke ja eher, dass bei der Konfig der Parameter nicht abgefragt wird. Dadurch schlägt die automatische Konfiguration von den beiden Paketen bacula-sd-mysql und bacula-director-mysql fehl.
Ja, das muss man manuell konfigurieren, keine envvars. Ich glaub in /usr/share/doc/ Beispielconfigs gesehn zu haben. Ansonsten muss die config von dpkg nicht fehlschlagen, ansonsten poste mal den output.
Das Schema kannste mit /usr/share/bacula-director/make_mysql_tables (wenn man den passenden Director installiert hat, hier bacula-director-mysql) erzeugen.
Hat geklappt, danke für den Hinweis. Ist Damit auch bacula-sd-mysql erledigt?
Der SD muss natuerlich noch um die Config deiner Speichersysteme ergaenzt werden, aber ansonsten ja. Musstu aufpassen, auch bacula-director-mysql zu benutzen, damit auch alles glatt geht (falls es nicht als depends von dem sd bereits mitgekommen ist).
Das Web-Frontend verwendest du nicht, oder?
Welches der vielen? :D
Frohe Weihnachten wünsch ich!
Thx, dir ebenfalls :)
MfG Thomas
MfG -Dimitri Puzin aka Tristan-777
Hallo Tristan-777
Ja, das muss man manuell konfigurieren, keine envvars. Ich glaub in /usr/share/doc/ Beispielconfigs gesehn zu haben. Ansonsten muss die config von dpkg nicht fehlschlagen, ansonsten poste mal den output.
Hat super geklappt, einfach die Configs "bereinigt" und nochmal dpkg --configure -a drüberlaufen lassen, dann sind die Daemons gestartet.
Das Web-Frontend verwendest du nicht, oder?
Welches der vielen? :D
Das von Sourceforge, Projekt Bacula (bweb glaube ich). Hab das jetz in Verbindung mit MySQL auch zu laufen bekommen. Bin aber etwas enttäuscht (langsam, nicht unbedingt üppig an Funktionen) Kannst du einen besseren Tipp geben? (Sollte aber schon Web-basiert sein, da ich auf den Backup-Server möglichst keine GUI draufmachen will.
Angenehm überrascht bin ich vom Speed der Sicherung. Er zieht durchschnittlich 5,5 MB/s beim Sichern der Windoof-Kisten. Das ist mehr, als ich per NFS schaffe. Noch mehr brauchs gar nicht sein, denn da der Sicherungsserver selbst die Bremse darstellt, merkt man auf dem Client gar nicht (bis auf's Plattenklackern), dass gesichert wird. Und mit Windows-XP geht's dank VSS sogar ohne skipped Files. Leider geht das bei w2k nicht, da bekomme ich Fehler bzw. Warnungen. Gibt's da vielleicht noch einen Trick (VSS-Provider installieren oder sowas)? Ich weiß, ist eine Linux-Liste, sorry... ;-)
Auf jeden Fall schonmal Danke für deine Hilfe, bin schon erheblich weiter gekommen.
Gruß Thomas
PS: Guten Rutsch
Thomas Lindner schrieb:
Hallo Tristan-777
Ja, das muss man manuell konfigurieren, keine envvars. Ich glaub in /usr/share/doc/ Beispielconfigs gesehn zu haben. Ansonsten muss die config von dpkg nicht fehlschlagen, ansonsten poste mal den output.
Hat super geklappt, einfach die Configs "bereinigt" und nochmal dpkg --configure -a drüberlaufen lassen, dann sind die Daemons gestartet.
schoen.
Das Web-Frontend verwendest du nicht, oder?
Welches der vielen? :D
Das von Sourceforge, Projekt Bacula (bweb glaube ich). Hab das jetz in Verbindung mit MySQL auch zu laufen bekommen. Bin aber etwas enttäuscht (langsam, nicht unbedingt üppig an Funktionen) Kannst du einen besseren Tipp geben? (Sollte aber schon Web-basiert sein, da ich auf den Backup-Server möglichst keine GUI draufmachen will.
Das beste Frontend ist nachwievor noch die bconsole selbst. BWEB hab ich mir mal angesehn, jedoch fehlten dort einige Funktionen und Restore ging auch mit besonderen Anpassungen, Selektion von einzelnen zu wiederherstellenden Files glaub ich auch nur mit Postgres DB Backend.
Bacula-web ist glaub ich eingestellt, aber wenn man nur die Stats sehn will ist das ausreichend.
Dann gibt es noch wx- und qt- consolen. Die brauchen natuerlich einen XServer oder koennen zumindest auf einer Workstation installiert werden.
Angenehm überrascht bin ich vom Speed der Sicherung. Er zieht durchschnittlich 5,5 MB/s beim Sichern der Windoof-Kisten. Das ist mehr, als ich per NFS schaffe. Noch mehr brauchs gar nicht sein, denn da der Sicherungsserver selbst die Bremse darstellt, merkt man auf dem Client gar nicht (bis auf's Plattenklackern), dass gesichert wird.
Ja die Performance war auch hier mit allen moeglichen Laufwerken stets top. Im Endeffekt ist das ja nur durch die vorhandenen Hardwareressourcen begrenzt.
Und mit Windows-XP geht's dank VSS sogar ohne skipped Files. Leider geht das bei w2k nicht, da bekomme ich Fehler bzw. Warnungen. Gibt's da vielleicht noch einen Trick (VSS-Provider installieren oder sowas)? Ich weiß, ist eine Linux-Liste, sorry... ;-)
Hmm, hatte w2k ueberhaupt VSS Support?
Auf jeden Fall schonmal Danke für deine Hilfe, bin schon erheblich weiter gekommen.
Kein Problem.
Gruß Thomas
MfG -Dimitri Puzin aka Tristan-777
PS: Guten Rutsch
PPS: wuensch ich auch :)
lug-dd@mailman.schlittermann.de
-
Dimitri Puzin -
Fabian Hänsel -
Thomas Lindner