Eigene Erfahrung: Beschreibung eines kleinen heterogenen Office-Netzwerks inklusive Backup-Zeitmaschine

13 Kommentare Autor: Jürgen (jdo)

Tux tar find mtime backup GNU teaser 150x150Ich hatte kürzlich einen Tipp geschrieben, wie man einen Papierkorb auf dem Samba-Server einrichten kann. Darauf hin kam die Bitte, das ganze Netzwerk-Setup zu beschreiben, was ich für diesen spezielle Fall mal tun werde. Dazu muss ich ein klein wenig ausholen.

Das Netzwerk läuft in einem Tauchcenter am Roten Meer und die haben insgesamt 4 Clients. Die gesamten Daten lagen auf einer externen Festplatte, die an einen der Clients angschlossen war und dann via Netzwerk freigegeben: Backup – Fehlanzeige. Die können echt von Glück reden, dass bisher nichts schief gelaufen ist. Der Besitzer (auch ein Freund von mir) kam auf mich zu und fragte, wie man das besser lösen kann. Ich hab ihm zu einem Linux-Server geraten, worauf er zunächst einmal geschluckt hat. Für ihn war das Wort “Server” ein großer schwarzer Kasten, der tausende von Euro kostet.

Ich hab dann erst einmal aufgeklärt, dass dies nicht so ist. Er soll den derzeit billigsten Prozessor kaufen, 1 GByte RAM und diese mit 2×1 TByte Festplatten austatten lassen – das reicht für die 4 Clients locker. Der Server langweilt sich damit immer noch.

Ich habe natürlich auch hinterfragt, ob er seine XP-Rechner behalten möchte oder wir dort auch Linux einen Versuch geben sollen. Damit war er nicht so glücklich. Er benutzt Outlook und ist damit zufrieden, ebenso gibt es diverse andere gekaufte Software-Pakete, die er weiter einsetzen möchte. Ok – Clients bleiben Windows, Server wird Linux.

In diesem Fall wollte er also vorerst nur einen zentralen Datentresor haben, der automatische Backups macht. Ich hab ihm dennoch erklärt, dass sich der Server zum Beispiel auch um die E-Mails kümmern könnte und er mit seinem Outlook via IMAP auf die elektronischen Nachrichten zugreift. Er hatte schon öfter Probleme mit der Größe der PST-Datei Outlooks. Somit könnte er seine Kontakte weiter mit Outlook pflegen, aber muss sich nicht mehr so um die PST-Datei kümmern. Dennoch haben wir nun beim ersten Schritt angefangen: Datenserver. Ein Druckserver ist nicht notwenidig, weil es einen Netzwerk-fähigen Laserdrucker in dem Büro gibt.

Festplatten-Einteilung

Ich habe bewusst auf ein RAID verzichtet. Das Problem an diesem Ort ist, dass keiner mit einem Linux-Server umgehen kann. Es gibt allerdings einige Leute, die mit Linux hantieren. Sollte ich also nicht da sein, wo anders hinziehen oder sonst nicht abkömmlich sein, kommt man zumindest so an die Daten, indem man die Festplatte mittels USB-Adapter an einen Linux-Rechner steckt. Speziell bei diesem Server muss ich zwingend daran denken, wo ich mich befinde – das sollte auch in Deine Planung solcher Aktionen eingehen.

Dann haben wir uns zusammengesetzt und die Daten durchgesehen. Es gibt knapp unter 10 GByte absolut wichtige Daten, wie Abrechnungs-Tabellen, Mail-Achive und so weiter und so fort. Das sind die unternehmeskritischen Dateien, die sich in mehr als 10 Jahren angesammelt haben. Der Zuwachs hier ist recht gering. Weiterhin sind ungefähr 200 GByte weniger wichtige Daten vorhanden. Wenn diese weg wären ist das ägerlich, aber nicht kritisch.

Dank der TByte-Platten konnten wir nun großzügig planen. 20 GByte hat das eigentlich Betriebssystem bekommen und eine Swap-Datei von 4 GByte. Für den unternehmenskritischen Bereich haben wir eine Partition mit 65 GByte eingerichtet. Die weniger wichtigen Daten bekamen 400 GByte zugewiesen. Der Rest ist ein temporärer Datenplatz, der nicht gesichert wird. Da können die Leute ablegen, was sie wollen.

Die obige Aufteilung ist natürlich nicht reine Willkür. Die unternehmenskritischen Dateien werden nicht nur alle Stunde mit rsync abgeglichen, sondern haben auch eine kleine Zeitmaschine spendiert bekommen. Bis zu 7 Tage lassen sich Dateien wieder herstellen. Somit brauche ich auf der Backup-Platte 65 GByte (rsync) + 455 GByte (7×65 GByte) = 520 GByte Sicherungsplatz, um die Datensicherung garantieren zu können. Die 400 GByte für die “hätte ich gerne gesichert” passen nun auch drauf und werden auch alle Stunde mittels rsync abgeglichen.

Zugriffe

Das netzwerk liegt in einem abgeschotteten Bereich, der verkabelt ist. Es gibt kein WLAN und es soll auch keines bekommen. Für die Tauchcenter-Gäste ist zwar eine Internet-Möglichkeit gegeben, diese läuft allerdings über eine separate Telefonleitung in einem eigenen Netzwerk. Der Besitzer wollte es zumindest für den Anfang so einfach wie möglich machen und die Mitarbeiter nicht zusätzlich verwirren. Deswegen sind keine Zugriffsrechte in Samba gesetzt und es wird alles über das Gast-Konto geregelt. Heißt: Keine Passwörter. Ihm ist es nun erst einmal wichtig, dass sich die Mitarbeiter an das Arbeiten mit dem Server gewöhnen und es keine Umstellung gegenüber der Festplatte-Freigabe zu früher gibt.

Wir haben lange über die Risiken gesprochen und ihm ist absolut bewusst: Wenn sich jemand in das Netzwerk einsteckt, hat er Zugriff auf den Server. Das Risiko möchte er aber eingehen, weil die ganz wichtigen Dokmente mit einem Passwort versehen sind. Auch hier habe ich ihn aufgeklärt, dass es Passwort-Knacker gibt, die recht gut funktionieren.

Die erste Woche mit dem Server

Gestern bin ich zu dem Tauchcenter und habe überprüft, ob die Backups sauber funktionieren. Ich habe auch mit dem Besitzer gesprochen und alle Daten sind mittlerweile auf dem Server. In diesem Zuge wurde auch ein kleiner Frühjahrsputz durchgezogen und viele Altlasten gelöscht. Somit ist noch viel mehr Luft nach oben, als eigentlich angedacht war.

Der Server sollte einige Jahre gute Dienste leisten und die Festplattegrößen sind so kalkuliert, dass wahrscheinlich eher die Hardware aufgibt, bevor der Platz ausgeht. Das von ihm angestrebte Ziel “automatisches Backup aller Daten” wurde übertroffen, weil er nun sogar eine kleine Zeitmaschine hat.

Beispiel-Script einer Zeitmaschine

So eine kleine Zeitmaschine lässt sich mit Linux-Hausmitteln prima selbst basteln. Alles was Du dazu brauchst ist tar, find und mtime (optional gzip). Ich habe folgendes Script (backup.sh) auf dem Server eingesetzt und dieses läuft via Cronjob 1.30 Uhr morgens an.

#!/bin/bash
# Backup of, that are in backup.files
# Juergen Donauer 

DATE=`/bin/date +%Y%m%d`
HOSTNAME=`/bin/hostname` #Hostname
BACKUPAGE=7 #Zeitmaschinen-Tage

TARBASE=/media/backup/critical #Backup-Verzeichnis für unternehmeskritische Dateien -> 65 GByte
TARFILE=$TARBASE/backup.$HOSTNAME.full.$DATE.tar
FILESDIR=/root/

/usr/bin/find $TARBASE -name "backup.$HOSTNAME.*.tar*" -mtime +$BACKUPAGE -exec /bin/rm {} \; # Dateien älter als $BACKUPAGE löschen

cat $FILESDIR/backup.files | while read line #backup.files Zeile für Zeile durchgehen
do
 	/bin/tar rf "$TARFILE" "$line" # Dateien in das Archiv schieben
done

/bin/chmod 600 "$TARFILE" #nur root Rechte auf die Datei geben
/bin/gzip -9 "$TARFILE" #Datei maximal komprimieren

Die Datei backup.files nutze ich gleichzeitig, um die Samba-Konfiguration zu sichern. Die Datei ist ganz nützlich, wenn man in Zukunft das Backup erweitern möchte. backup.files:

/media/critical
/etc/samba

Die Autmatisierung erreichst Du, indem Du als root crontab -e aufrufst und dann folgende Zeile einfügst:

30 1 * * * /bin/sh /pfad/zu/backup.sh >> /dev/null 2>&1

Ich hatte dem Besitzer noch angeboten, ein automatisches Backup zu machen, wenn er eine externe Festplatte einsteckt. Das würde die Daten zusätzlich absichern und er könnte immer eine Kopie mit nach Hause nehmen. Das hielt er allerdings für unnötig. Wie man eine automatische Datensicherung beim Einstecken einer USB-Festplatte realisieren kann, habe ich schon einmal detailliert beschrieben.

Bisher sind alle glücklich und in der Server ist so konzipiert, dass er sich in Zukunft auch für weitere Aufgaben einsetzen lässt. Ich bin jedenfalls froh, dass die alte Grusel-Lösung der Vergangeheit angehört und auch mein Freund kann wesentlich ruhiger schlafen.

Mit wenigen Kniffen lässt sich also eine brauchbare Backup-Lösung mit Linux-Hausmitteln herstellen. Sollte etwas schief gehen, verlieren die Jungs maximal eine Stunde an Arbeitszeit (rsync). Sollte eine unternehmenskritische Datei komplett zerschosssen werden, durch einen Virus zerstört oder was auch immer – ist maximal ein Tag verloren und die Datei lässt sich bis zu sieben Tagen wieder herstellen.

Natürlich sind der Fantasie keine Grenzen gesetzt und dies ist ein sehr spezielles Beispiel. Aber dieser Beitrag ist vielleicht eine Anregung für den einen oder anderen, der sich dann seinen ganz eigenen Server bastelt und Teile von meinen Beschreibungen brauchen kann. Welche Distribution Du als Server einsetzt ist in diesem Fall völlig irrelevant. Die beschriebenen und benutzten Tools gehören eigentlich zum Inventar einer fast jeden Linux-Distribution. Für einen Server bietet sich jedoch an, ein Betriebssystem mit Langzeitunterstützung zu verwenden. CentOS oder Ubuntu bieten sich zum Beispiel an, wenn man es komplett kostenfrei haben möchte.




 Alle Kommentare als Feed abonnieren

13 Kommentare zu “Eigene Erfahrung: Beschreibung eines kleinen heterogenen Office-Netzwerks inklusive Backup-Zeitmaschine”

  1. Johannes says:

    Danke für das Teilen deiner Lösung! 🙂

    Der Vorteil von Linux ist wie so oft seine Flexibilität und die große Menge von Vorarbeit, auf der man aufbauen kann (und darf!).

    Ich mag Tar-Files irgendwie nicht so, aus einem riesigen Archiv will ich ungerne einen Restore machen.
    Meine Alternative setzt daher auf SSH, rsync, rsnapshot und Python auf, zu finden hier: [url]https://github.com/jazzer/packup[/url]. Dank Hardlinks verbraucht ein Durchlauf von rsnapshot kaum Platz, dann rsync annehmbar viel Zeit (je nach Datenmenge natürlich). Alle Dateien sind einzeln per Nautilus zugreifbar, zurück für x Tage, x Wochen und x Monate.

    • jdo says:

      Die tar-Lösung ist echt nur für den absoluten Notfall. Die unternehmenskritischen Dateien werden auch via rsync gesichert und auf die kann ich sofort zugreifen.

      Das Gute an der Sache ist, wie Du schon sagst, dass ich es mir speziell auf meine Bedürfnisse anpassen kann. Einmal ein paar solche Scripte aufgesetzt und Du hast diese sehr schnell auf andere Szenarien angepasst.

      Ich mag tar deswegen, weil es einfach auf jedem Linux/Unix-System vorhanden ist. Ich kann also das Script nehmen und sofort einsetzen, ohne erst Dinge nachinstallieren zu müssen. Das ist eigentlich der Hauptgrund, warum ich es nehme. Sollte man das System einmal tauschen müssen, ist das Script sofort wieder einsatzbereit.

  2. knaftelpupaftel says:

    HOSTNAME=`/bin/hostname` #Hostname

    also mal von der sinnhaftigkeit des kommentars abgesehen, ist HOSTNAME nicht bereits eine umgebungsvariable die man nur noch abfragen muss?

    abgesehen davon würde ich erst das backup machen und dann altdaten löschen, falls der return code des backup = 0 ist.

    und drittens hast du auf zeile 15 ein useless use of cat. wenn du das file in die while redirectest kannst du zusätzlich die subshell vermeiden.

    • jdo says:

      Das Script ist schon uralt und ich hab es schon oft verwendet. Wie gesagt ist es nur ein Beispiel und bisher hat es immer funktioniert. Von daher "never change a running System" und wie ich schon öfter erwähnte führen viele Wege nach Rom.

      Das Backup muss ich vorher löschen, weil es sonst im "worst case" keinen Platz für das neue Backup gibt. Außerdem lösche ich ja nicht alle Backups, sondern nur immer das älteste.

      Wer das Script verwenden möchte, kann sich aber Deine Tipps zu Herzen nehmen und es ganz nach eigenen Bedürfnissen anpassen, verbessern oder was auch immer ...

  3. knaftelpupaftel says:

    filespace-gründe dacht ich mir schon. dann will ich direkt nochma ergänzen, dass du überhaupt keine while brauchst. mach einfach

    tar -czf backup.tgz -T include.txt

    das sollte funktionieren, ich habs allerdings nicht getestet ^^

    • jdo says:

      Meins ist getestet und läuft nicht nur auf einem Rechner 😉

    • jdo says:

      Was mir auch noch einfällt ... das Hostname braucht es in diesem Fall gar nicht. Das stammt noch aus einer zeit, wo wir bei einer Firma mehrere Server gesichert hatten und die gezippten tar-Archive dann via ssh auf einen separaten Backup-Server geschoben haben. Somit wussten wir, welches backup von welchem Server ist - in diesem Fall eigentlich obsolet ...

    • jdo says:

      Was mir auch noch einfällt ... das Hostname braucht es in diesem Fall gar nicht. Das stammt noch aus einer Zeit, wo wir bei einer Firma mehrere Server gesichert und die gezippten tar-Archive dann via ssh auf einen separaten Backup-Server geschoben haben. Somit wussten wir, welches Backup von welchem Server ist - in diesem Fall eigentlich obsolet ...

      • stefan says:

        danke, dass du dir die zeit genommen hast um den aufbau des netzwerkes genauer zu erklären. ich finde deine berichte über deine bekannten und freunde welche linux einsetzen immer wieder sehr interessant. weiter so.
        lg
        stefan

  4. Hey,

    klasse Artikel 🙂
    Werde das wohl mal meinem Arbeitsgeben vorschlagen, wir haben nämlich auch (noch) keine ordentliche Backuplösung :S

    LG
    Vincent

  5. Hey,

    ich nochmal.
    Kannst du mir erklären warum der Server 4 Gb Swap bekommt?
    Ich dachte die Swappartition soll max. so groß wie der Arbeitsspeicher sein.

    LG Vincent

    • jdo says:

      Weil wir mehr als genug Platz haben auf dem Rechner und er eventuell in der Zukunft mehr Aufgaben erledigen soll und vielleicht dann auch aufgerüstet. Ansonsten keinen speziellen Grund.

  6. Ikem says:

    > 20 GByte hat das _eigentliche_ Betriebssystem bekommen

    Typo.