Welche Backuplösung für einfache Umgebung wählen?

Moin Moin,

wir nutzen demnächst einen UCS 4.01 produktiv und suchen für unsere darauf gespeicherten Daten (einige wenige Terabyte) noch eine Backuplösung.

Im App Center sind ein paar Backuplösungen angeboten, es ist aber unklar, welche für uns am geeignetsten ist bzw ob überhaupt eine geeignet ist, oder ob nicht alle davon überdimenioniert sind.

Derzeit nutzen wir rdiff-backup (auf einem Ubuntu-Server; ist via unmaintained Repositories auch beim UCS vorhanden) für Backups auf ein qnap-NAS im LAN. Uns wäre eine einigermaßen leicht zu beherrschende, aber kostenlose GUI-Lösung aber lieber. Haben Sie einen Tipp?

danke und viele Grüße,

Axel Voigt
Technische Leitung
Schul-Support-Service e.V.
Große Weidestraße 4-16, 28195 Bremen
Hotline: 0421-361-6600, Mo-Fr 7.30 - 15.30 Uhr
schul-support-service.de

Moin,

die drei Lösungen im AppStore (Bacula, Bareos und SEP Sesam) sind allesamt ausgesprochen große Lösungen.

Bacula ist eine hoch skalierbare, endlos flexible Backuplösung, die primär über Textdateien konfiguriert und über eine Textmodusconsole gesteuert wird. Es gibt zwar auch eine graphische Console, doch bleiben auch dort Textbefehle einzugeben.

Bareos kenne ich persönlich nicht, aber da es aus Bacula hervorgegangen ist, gehe ich davon aus, dass es sich ganz ähnlich verhält.

SEP Sesam ist in der Tat eine graphische Lösung, aber auch hier auf deutlich größere Umgebungen ausgelegt – und auch nicht Open Source geschweige denn kostenlos erhältlich.

An graphischen Backupprogrammen gibt es für Linux durchaus einige; z.B. Areca Backup oder Back In Time. Eine gute Übersicht liefert eine Liste aus dem Arch-Linux-Wiki. Wie gut die alle unter Univention laufen, kann ich nicht gut sagen; wir selber setzen auf dirvish (ein auf rsync basierendes Tool), das aber auch ein reines Textmodus-Programm ist.

Für eine einfache Lösung finde ich rdiff-backup ziemlich gut, ich würde mir daher durchaus überlegen, dabei zu bleiben.

Bareos und Bacula sind in der Tat noch sehr nah beieinander, so dass man, wenn man Bacula kennt, auch mit Bareos umgehen kann. Bareos ist aber die Software mit dem klareren Bekenntnis zu Freier Software, weswegen ich es bevorzuge.

Graphisch geht aber leider in der UMC ziemlich wenig: Eigentlich kann man nur die serverseitige Konfiguration für die Sicherung von Windows-Maschinen aus der UMC einfach erzeugen. Die Installation des Clients (so genannter File-Daemon) und dessen Konfiguration auf dem Windows-Rechner muss man aber dann auch manuell machen. Wenn man sich aber die (kleine) Mühe macht, die Einbindung eines zu sichernden Rechners zu verstehen und dafür die in /etc/bareos/… vorhandenen Schablonen hernimmt, ist das die “einzige” Arbeit. Der Rest ist nach der Installation aus dem App-Center heraus schon sehr brauchbar vorkonfiguriert.

Gruß, V. Mayer

1 Like

Welche Lösung wird seitens Univention für ein Bare Metal Recovery empfohlen?

Idealerweise soll der komplette Server (es gibt nur einen mit UCS, Zarafa, Files) woanders hin “gespiegelt” werden und im Falle eines physikalischen Defekts auf eine andere Hardware portiert werden können.

Hochverfügbar und dabei bezahlbar wäre super.

Hallo,

[quote=“lex”]Welche Lösung wird seitens Univention für ein Bare Metal Recovery empfohlen?
[/quote]

Keine echte “Empfehlung”, aber aufgrund der Anforderungsbeschreibung vermute ich du suchst nach etwas wie DRBD (verfügbar im App Center).

Viele Grüße,
Tim Petersen

Hallo Herr Petersen,

ja an DRBD dachte ich auch schon. Es wäre dann ja sogar ein richtiges HA wenn ich alles korrekt verstehe?
Sprich, eine 1 zu 1 Kopie des UCS Servers auf anderem Blech, welches im Falle des Falls übernimmt?
Oder gibt es irgendwelche Einschränkungen (Datenbanken, VMs, Zarafa)?

Für die Redundanz sicherlich ein prima Ding.

  • Aber ich kann es dann wohl schlecht “außer Haus” mit nehmen.
  • Ich benötige idealerweise einen zweiten Serverraum, möglichst in einem anderen Brandabschnitt.

Ziel ist es komplett auf UCS als AD Controller + File + Mail + Virtuallisierungsserver zu setzen.

Ansonsten tendiere ich zu SEP. Soweit ich es richtig verstanden habe könnte ich damit auch die Clients (Windows) vom Server aus auf z.b. einen anderen Fileserver sichern? Wäre SEP Ihrer Meinung nach so eine Eierlegendewollmilchsau? Gibt es Einschränkungen (Datenbanken, VMs)?

Liebe/r lex,

eierlegende Wollmilchsäue gibt es leider nicht, auch nicht bei Freier Software. Ansonsten würde ich an Ihrer Stelle erstmal genau überlegen, was Sie wollen: Backup oder HA? Diese Bereiche haben zwar gewisse Schnittmengen, sind aber nun wirklich nicht identisch. Dann kann man auch Ihre Fragen etwas besser beantworten.

DBRD tut, was es sagt: Es bietet ein von physischen Devices hinterlegtes übers Netzwerk replizierendes Block-Device, also eine Art Netzwerk-RAID1. Welche Daten darauf liegen (Datenbanken, Zarafa, VMs) ist erstmal egal. Ob diese Daten auch konsistent sind, weiß DRBD aber nicht, es ist schließlich ein Block-Device. Darum müssen sich Dateisysteme oder höhere Schichten kümmern. Wenn das aber der Fall ist, kann man damit diverse HA-Szenarien abbilden. Aber nur noch mal zur Erinnerung: RAID1 war noch nie ein Ersatz für Backup :wink:

Gruß, V. Mayer

Hallo,

zum Thema HA versus Backup wollte ich auch gerade schreiben.

Somit kann ich mich auf SEP sesam konzentrieren. Der wesentliche Vorteil vom Sesam ist, dass er Sicherungsagenten für alle möglichen Dinge liefert. Einschränkungen gäbe es allerdings schon. Die konsistente Sicherung laufender VMs benötigt entsprechende Schnittstellen des Hypervisors. Da sieht es bei KVM nicht besonders gut aus. Hier müsste man über Pre/Postskripte dafür sorgen, dass die VMs angehalten werden. Empfohlen wird aber grundsätzlich auch, die Daten über Agents aus den VMs heraus zusätzlich zu sichern.
Zum BSR-Thema: SEP sesam nutzt für Linux-BSR REAR. Wer mag, kann sich das auch selbst zusammenbauen.

Viele Grüße,
Dirk Ahrnke

Hallo Herr Mayer,

Das steht doch im Titel: Welche Backuplösung für einfache Umgebung wählen.
HA wäre “nice to have” aber primär geht es um ein Backup des kompletten UCS Servers.

Genau das ist der Punkt weshalb ich hier versuche die richtige Lösung für mich zu finden mit dem Fokus auf UCS.

Ich habe keine GUI-Lösung, beschreibe hier mal meinen Weg:

Wir haben den UCS nicht auf „bare-metall“ installiert, sondern Proxmox als Virtualisierungsschicht zwischengeschoben.
Das hat den Charme, dass von der UCS -Installation snapshots (lokal oder auf einen entfernten Netzwerkspeicher) getätigt werden können.
Die Installation ist damit hardwareunabhängig und kann schnell wieder ans Rennen gebracht werden, wenn ein Hardwaredefekt/Austausch anliegt.

Für die eigentliche Datensicherung (ich gehe jetzt nur von /home aus), nutze ich rsnapshot. Dabei wird aber der Backupordner von mir wieder per Samba read-only im Netz freigegeben¹.
Damit kann $User seine Daten selbst ohne den Umweg über einen Admin zurückspielen. Denn das ist ja der eigentlich wichtige task:
Ganz getreu dem Motto: Niemand will Backups, alle wollen Restore .

Ich halte immer 6 Monate / 4 Wochen / 7 Tage = 17 Snapshotpunkte vor. rsnapshot nutzt hardlinks, sodaß ich idR. den Backupspace nur 1.5x so groß wie /home wählen muss und trotzdem in jedem Backupordner alle Dateien sehe. Gepaart mit der Sambaoption „hide unreadable = yes“ sehen die Benutzer nur die Ordner/Dateien, auf die sie auch Rechte haben.

[1]
Dieses Script sorgt bei unserem Schulserver dafür (wird im cmd_postexec hook in der /etc/rsnapshot.conf aufgerufen)

#!/bin/sh                                                                                                                                         

#
# Dieses Script sorgt dafür, dass die aktuellen backup-Stände über
# Samba zur Verfügung gestellt werden
#                              Thorsten Strusch <strusch@ksan.de>
#

# nur laufen, falls es mindestens ein Backup gibt:
[ -d /mnt/backup/rsnapshot/daily.0 ] || exit 0

# Löschen der alten links
[ -d /home/samba/Backup/ ] || mkdir /home/samba/Backup/
find -H  /home/samba/Backup/ -xdev -type l -delete

cd /home/samba/Backup/
# kreatives Erstellen der Ordner
for i in /mnt/backup/rsnapshot/* ; do stat -c "%n %y" $i; done | awk '{ print "ln -s",$1"/ksan/home",$2}' | sh

# Verstecken der Lernsoftwarefreigabe vor den Schülern:
chown lehrer.lehrer /mnt/backup/rsnapshot/*/ksan/home/samba/Lernsoftware/
chmod o-rx /mnt/backup/rsnapshot/*/ksan/home/samba/Lernsoftware/

Das Share zeigt dann diese Ordner:

lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2014-10-30 -> /mnt/backup/rsnapshot/monthly.5/ksan/home lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2014-11-27 -> /mnt/backup/rsnapshot/monthly.4/ksan/home lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2014-12-25 -> /mnt/backup/rsnapshot/monthly.3/ksan/home lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2015-01-22 -> /mnt/backup/rsnapshot/monthly.2/ksan/home lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2015-02-26 -> /mnt/backup/rsnapshot/monthly.1/ksan/home lrwxrwxrwx 1 root root 41 2015-05-20 22:00 2015-03-26 -> /mnt/backup/rsnapshot/monthly.0/ksan/home lrwxrwxrwx 1 root root 40 2015-05-20 22:00 2015-04-16 -> /mnt/backup/rsnapshot/weekly.3/ksan/home lrwxrwxrwx 1 root root 40 2015-05-20 22:00 2015-04-23 -> /mnt/backup/rsnapshot/weekly.2/ksan/home lrwxrwxrwx 1 root root 40 2015-05-20 22:00 2015-04-30 -> /mnt/backup/rsnapshot/weekly.1/ksan/home lrwxrwxrwx 1 root root 40 2015-05-20 22:00 2015-05-07 -> /mnt/backup/rsnapshot/weekly.0/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-12 -> /mnt/backup/rsnapshot/daily.6/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-13 -> /mnt/backup/rsnapshot/daily.5/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-14 -> /mnt/backup/rsnapshot/daily.4/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-15 -> /mnt/backup/rsnapshot/daily.3/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-18 -> /mnt/backup/rsnapshot/daily.2/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-19 -> /mnt/backup/rsnapshot/daily.1/ksan/home lrwxrwxrwx 1 root root 39 2015-05-20 22:00 2015-05-20 -> /mnt/backup/rsnapshot/daily.0/ksan/home

[quote=“lex”]Hallo Herr Mayer,

Das steht doch im Titel: Welche Backuplösung für einfache Umgebung wählen.
HA wäre “nice to have” aber primär geht es um ein Backup des kompletten UCS Servers.
[/quote]

Gut, dann würde ich Bareos empfehlen, erfordert zwar etwas Einarbeitungsaufwand, funktioniert dann aber auch so gut, dass man es quasi “vergessen” kann.

Genau das ist der Punkt weshalb ich hier versuche die richtige Lösung für mich zu finden mit dem Fokus auf UCS.[/quote]

Die Idee von ThorstenS mit rsnapshot ist auch noch ein feiner Vorschlag. Das habe ich in ganz ähnlicher Weise auch schon mehr als einmal implementiert und ermöglicht ein einfaches Wiederherstellen von Dateien per Selbstbedienung. Unter Backup im engeren Sinne würde ich es aber nicht zählen, sondern eher als erster Anlaufpunkt bei Wiederherstellungswünschen. Dahinter würde ich immer noch ein “richtiges” Backup laufen lassen, also z.B. rdiff-backup oder Bareos.

Gruß, V. Mayer

Das sehe ich etwas anders. KVM kann schon ganz gut konsistente Snapshots erzeugen wenn man die Maschinen richtig aufbaut:

qemu-snapshot + qcow2 für das VM-Volume + den Guest-Agent (für Windows Gäste)

Bei der Ausführung von qemu-snapshot wird ein FS-Freeze vorgenommen der immerhin das FS in einen konsistenten Zustand versetzt.
http://wiki.qemu.org/Features/Snapshots#Guest_Agent

Allerdings erkunde ich auch gerade die Möglichkeiten von ZFS on Linux als Datenspeicher für die VM’s.

Ich baue die UCS Systeme eigentlich immer auf ein “normales Ubuntu” als Hypervisor auf so das man alle Server inkl des DC sauber sichern kann.

Meine Aussage bezog sich auf die Unterstützung durch SEP Sesam, inklusive der Möglichkeit, ein Restore aus der GUI durchzuführen.

Viele Grüße,
Dirk Ahrnke

Moin Moin,

danke für die Vielzahl von Beiträgen.

In unserer Situation (Daten von einem UCS via LAN auf NAS sichern; Backups müssen nicht von usern selbst zurückgespielt werden können; kostenlose Lösung bevorzugt; kein System-Backup) wollen wir nun doch beim rdiff-backup bleiben, dass ja hier auch als Lösung von einigen positiv bewertet wird. Insgesamt ist es für uns wohl auch zukünftig die einfachste Lösung.

danke und viele Grüße,

Axel Voigt
Technische Leitung
Schul-Support-Service e.V.
Große Weidestraße 4-16, 28195 Bremen
Hotline: 0421-361-6600, Mo-Fr 7.30 - 15.30 Uhr
schul-support-service.de

Mastodon