Alternative für BackupPC (Linux/Windows Clients)

[slu]

Hallo,

ich betreibe schon seit einigen Jahren einen BackupPC Server und suche eine Alternative.

Gründe hierfür sind:
* manchmal lässt er einzelne Dateien auf einem Windows Share aus
* da kein natives rsync fehlt die -z Option
* Backups dauern sehr viel länger als ein nativer rsync lauf

Ich muss einige Windows Freigaben und viele verschiedene Linux Systeme sichern.
Ohne Client auf den Systemen auszukommen wäre von grossem Vorteil (zumal ich nicht auf allen einen installieren könnte).
Weiterhin soll einmal die Woche ein Offsite Backup auf einer extern Festplatte erzeugt werden.

rsnapshot würde mir gut gefallen, allerdings müsste man sich was für die Windows Shares überlegen.
Leider finde ich hier aber keine Möglichkeit ein Offsite Backup zu machen.

Würde mich über Ideen freuen.

[r4pt0r]

Amanda

Habe mittlerweile alle rsync/skriptbasierten backup-setups abgeschafft und auf amanda umgestellt.
Der Denkansatz der dumpcycles ist zwar erstmal gewöhnungsbedürftig, dafür mittelt sich die tägliche backupgröße nach 2-3 durchgängen langsam aus und man hat jede nacht ca die selbe backupgröße. Das macht die Planung des Speicherbedarfs einfacher und die dauer der nächtlichen Backups leichter vorhersagbar - man hat nicht mehr ein "Monsterbackup" am Wochenende das hoffentlich bis Montag früh beendet ist bevor der normale Betrieb wieder losgeht.

Amanda nutzt nativ nur tar und dump - beides ist in praktisch jeder Linux/UNIX/BSD-Installation vorhanden. bzip,gzip usw kann beliebig je nach verfügbarkeit genutzt werden. Einfachstes setup am Client wäre per installation des amanda-clients, aber auch rein über ssh ist möglich. Da die Konfiguration am Client sich bei nutzung des amanda-clients auf die "amandahosts" und ggf exclude-dateien beschränkt, ist das deployment auch sehr gut per ansible, chef oder puppet möglich.

Windows-shares können direkt per CIFS bedient werden, für Windows-Clients gibts einen eigenen Clientdienst (nie ausprobiert, soll aber ganz gut funktionieren).

Target für Backups kann jeglicher lokaler speicher oder wechselmedien sein, tape-libraries oder externe speicher/systeme bzw cloud (S3, tarsnap....).

Da Amanda praktisch alles über scripte und standardwerkzeuge realisiert ist die Erweiterung und Anpassung an spezielle Setups sehr einfach bzw vieles gibts sowieso schon...

Das schöne an Amanda: Einfache setups sind in <5 minuten Konfiguriert aber es sind auch beliebig komplexe Setups und Backupstrategien möglich.

[MSfree]

Gründe hierfür sind:
* manchmal lässt er einzelne Dateien auf einem Windows Share aus

Das ist aber ein generelles Netzwerkproblem. Die Annahme, das Netzwerk ist verlässlich, gilt leider nicht.

Wir haben letztens auch so ein Problem gehabt, bei dem rund 6000 verschiedene Dateien während eines 3 tägigen Programmlaufs mehr oder weniger zufällig geöffnet, gelesen und wieder geschlossen werden. Bei einem von ca. einer Million Dateizugriffen kam es zu einem "Datei kann nicht geöffnet werden"-Fehler. Versucht man in so einem Fall, die betroffene Datei einfach eine Milisekunde später nochmal zu öffnen, funktioniert es. Auf lokalen Festplatten tritt so ein Fehler nie auf.

Wir konnten uns dabei, weil wir den Quellcode haben, damit helfen, Retries in die Software einzubauen, um dem Problem aus dem Weg zu gehen. Diese Retries fehlen aber in jeder anderen Software, egal ob via SMB, NFS oder rsync, man wird mit so einem Problem leben müssen, wenn man nicht die Möglichkeit hat, Retries in die Software einzubauen.

[Alternativende]

+1 für Amanda.

Kein Client notwending für Windows da über SMB. Bei Linux installierst du einfach das Paket und musst nur eine Datei anpassen. Hinzu kommt das es sehr zuverlässig arbeitet, dir Mails schickt und ich seit nun fast 10 Jahren noch keine großen Probleme damit gehabt habe.

[slu]

Vielen Dank für eure Antworten.

Zumindest konnte ich inzwischen herrausfinden warum BackupPC einige Datei ignoriert hat.
Vollbackup von 2016 und dann wurden 2 Dateien mit Create Date von 2015 auf den Rechner kopiert.
Damit übersieht BackupPC diese Dateien bis zum nächsten Vollbackup was aber wohl eine schwäche von SMB darstellt.
Phuu das hat mich wirklich nicht in Ruhe gelassen.

Zum Amanda, hat jemand ein gutes HowTo zum Einstieg?

[Alternativende]

Ist bei mir schon so lange her das ich da kein Howto habe, gefunden habe ich dieses hier:

http://www.zmanda.com/quick-backup-setup.html

Ansonsten kann ich Dir gerne auch meine Configs zur Verfügung stellen, falls Du Fragen hast poste sie einfach.

[slu]

http://www.zmanda.com/quick-backup-setup.html

Das kannte ich schon, noch etwas unübersichtlich.

Irgendwie kommt da auch so gar kein Default mit:

Code: Alles auswählen

root@debian:/etc/amanda# ls -l
insgesamt 0
root@debian:/etc/amanda#

[r4pt0r]

Die Beispielconfigs liegen in /usr/share/doc/amanda-[common|client|server]/examples
Weiterer Anlaufpunkt wäre die Amanda Wiki: https://wiki.zmanda.com/index.php/Getti ... ith_Amanda

Die Howtos auf zmanda.com und in der wiki sind wirklich etwas "wild". Ich fand das Amanda-Kapitel in "Backup and Recovery" (W. Curtis Preston, 2007, O'Reilly) [1] sehr gut - dort wird auch zuerst der grundlegende Mechanismus und die Strategie von Amanda erklärt. Ansonsten kann man IMHO nicht viel mit beispielkonfigurationen von Amanda anfangen, da der Ansatz doch etwas anderst als bei aktuellen/kommerziellen Backuplösungen ist.

Amanda arbeitet grundsätzlich mit "Tapes" - egal was letztendlich wirklich als Speichermedium/Ziel genutzt wird, für Amanda landet alles auf tapes, das inventar wird als "tapelist" geführt usw.... vtapes (virtuelle Tapes) können aber auch Ordner auf einer lokalen Platte oder S3 buckets sein - das ist praktisch beliebig definierbar.

Backups werden in verschiedenen Leveln durchgeführt - 0 ist dabei "full". Über den gesamten Zyklus (i.d.R. 10 Tage) erstellt Amanda von jedem Ziel in der "disklist" (=Ordner auf entferntem Host, lokales dateisystem, VM, CIFS-share...) mindestens einmal ein Fullbackup und dazwischen inkrementelle backups in verschiedenen Stufen (kann ggf über verschiedene Parameter angepasst werden - default funktioniert meistens ganz gut). Ziel ist dabei, die Tägliche backupgröße konstant zu halten - ursprünglich um die Tapes optimal auszunutzen, heutzutage eher um die Netzwerk- und Speicherlast gleichmäßig zu verteilen (-> keine 20h-Backups am Sonntag mehr bei dem die Platten am NAS überlaufen...)

Backups werden parallel abgeholt - mit Amanda kann man problemlos einen 10GBit uplink zum LAN sättigen, wenn der lokale Storage und die Clients nachkommen. Skalierbarkeit ist somit eigentlich nur durch die Hardware begrenzt, nicht durch Amanda (bzw erst bei _sehr_ großen Setups).
Die Backups werden zuerst auf eine "holding disk" gesammelt, um dann mit maximaler Bandbreite ohne unterbrechungen an einen Streamer/Tape-Library gefüttert zu werden - zumindest ist das der eigentliche Sinn dieses Zwischenschrittes. Das finale Ziel kann aber wie gesagt auch eine lokale Ordnerstruktur oder ein entfernter Host sein - für fast alle erdenklichen Szenarien findet man da schon fertige und erprobte "tapetype"-definitionen bzw die examples und manpages liefern auch schon einige Beispiele.

Da für Amanda kein extra Serverdienst benötigt wird, legt man einfach cronjobs für die gewünschten Zeiten/Intervalle an.

Schau dir am besten mal die examples und "Getting Started" in der wiki an - bei Fragen gibts hier im Forum sicherlich einige die sich mit Amanda auskennen und helfen.


[1] http://shop.oreilly.com/product/9780596102463.do

[heisenberg]

Ich hänge mich da auch nochmal dran, da ich gerade exakt die gleiche Frage habe. Nur für den Fall, dass es da noch etwas gibt.

Ich habe zwei Backupserver mit BackupPC und frage mich ob es eine bessere Lösung gibt. Gründe der "Unzufriedenheit" sind zweierlei:

• Die Last, die Backuppc verursacht ist immens hoch. Die gemischte Schreib-/Leselast ist und das wöchentlich stattfindende Poolhashing zur Deduplikation belastet den Server sehr stark und drückt die Performance sehr nach unten, was die insgesamte Kapazität Backups aufzunehmen stark begrenzt.
• Wegen der hohen I/O-Last funktionieren Wiederherstellungen von Vollsicherungen nicht mehr über das Webinterface(Gestartet und wird nie fertig). Ich muss deswegen bei Bedarf zur Konsole greifen und über BackupPC_tarCreate | ssh tar -xf - ... die Wiederherstellung händisch anstossen), was bisher auch immer gut funktioniert hat.

Was mir natürlich an Backuppc sehr gut gefällt ist die Deduplikation. Wenn ich für 70 TB Backupdaten nur 7 TB auf der Platte brauche, dann ist das natürlich der Hammer. (Weniger Strom, Weniger Platten, Weniger Hitze)

[uname]

@heisenberg

BackupPC nutze ich nicht. Aber es verwendet wohl Hardlinks für Deduplikation und unterstützt wohl optional eine Datenkomprimierung. Ich nutze für meine Trivialsicherungen mein eigenes Script [1], welches Deduplikation jedoch nur für identische Dateinamen (also rein inkrementell) nutzt (--link-dest=$TARGET/$LAST). Auch verzichte ich auf eine Datenkomprimierung. Ich möchte mal behaupten das Script ist rattenschnell wenn auch vielleicht nicht hocheffizient.

Ich denke mal, dass die Datenkomprimierung dein System mehr belastet als die Deduplikation. Somit würde ich vielleicht einen neuen Test-BackupPC-Server aufsetzen und mal die Komprimierung deaktivieren sofern das überhaupt geht. Natürlich wird die Datenmenge damit ansteigen. Aber vielleicht verschwinden die Performanceprobleme. Erst wenn das nicht zielführend ist würde ich auf alternative Software setzen. Meine Lösung ist wohl eher eine Spiellösung bzw. wenn man mit "rsync" und optional "ssh" mal schnell was zusammenbauen will. Die aktuelle Version habe ich lange nicht mehr genutzt. Also am besten auf Testsystemen ausprobieren.

[1] https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC

[heisenberg]

Na also die CPU langweilt sich ziehmlich. Ich würde eher vermuten, dass in dem Fall zutrifft, dass die Kompression eher die I/O verringert. Je nachdem wie BackupPC das komprimieren durchführt. Wenn's den ganzen Kram erst einmal unkomprimiert auf die Platte klatscht, dann bringt's wohl was. Ok. Kann ich mal probieren, ob's besser wird, wenn ich das abschalte. Genug CPU-Power und RAM sind vorhanden.

Das Bild zeigt, dass der Server eine konstant hohe I/O Wait hat.



EDIT

Es gibt wohl mehrere Möglichkeiten wie man bei BackupPC die Kompression ($Conf{ArchiveComp} = 'none'; oder $Conf{CompressLevel} ='0';) ausschalten kann. Ich hatte mich schon gewundert, weil ich meinte ich hätte das schon ausgeschaltet. Also: Ja ich habe die Kompression bereits abgeschaltet und im ZFS darunter eingeschaltet. Der Gedanke dabei ist, dass die Kompression mit dieser Zwischenschicht besser arbeitet wie oben schon geschrieben.