Backup/Server/Dokumentation

Aus Foxwiki
Subpages:

Projektumfeld

Dirk Wagner Berlin ist ein Unternehmen, welches sich um Websites verschiedener Kunden kümmert, diese laufen auf mehreren angemieteten virtualisierten Servern.

Zielstellung

  • Ein lokaler Backup-Server soll aufgebaut und eingerichtet werden, auf dem die Daten der Clients im LAN gesichert werden.
  • Zusätzlich soll externer Backup-Space angemietet werden, auf dem die Dateien des lokalen Servers verschlüsselt übertragen und in Archiven gesichert werden sollen.
  • Bestandteil der Lösung soll ein automatisierter regelmäßiger Backup-Turnus sein.

Technische Anforderungen

  • Lokaler Backup-Server:
    • Software-RAID
    • Betriebssystem: Debian Linux 10
    • 4 TB effektiver Datenspeicher
  • Online-Backup-Space:
    • 2 TB effektiver Datenspeicher
    • Die Backup-Dateien sollen verschlüsselt auf den externen Backup-Server übertragen werden.
  • Es soll auf Kundenwunsch bei der Realisierung des Projekts auschließlich Open-Source-Software zum Einsatz kommen.

Projektplanung

Projektauftrag

  • Zur weiteren Präzisierung der Realsierung der Zielstellung wurde ein ausführliches Gespräch mit dem Auftraggeber geführt. In dessen Verlauf der Projektauftrag dahingehend erweitert wurde, zusätzlich zu den drei geplanten Clients lincln01, lincln02, und debian02, die Server mx10, mx20 und mx50 in das Backup-System als Backup-Clients einzubinden.
  • Ein weiteres Ergebnis des Gesprächs war, dass der Auftraggeber in Erwägung zog den Backup-Server mit beim Auftraggeber vorhandener Hardware aufbauen zu lassen.
  • Der Auftraggeber wünschte trotzdem ein Angebot für den Backup-Server aus neuer Hardware als Wahlmöglichkeit.
  • Als maximales Budget für die Anschaffung neuer Hardware wurde durch den Auftraggeber 2000,00€ festgelegt.
  • Projektauftrag war es, zwei Angebote zu erstellen, eines für einen Backup-Server mit neuer Hardware und eines für das Anmieten von Backup-Space.
  • Nach der finalen Entscheidung des Auftraggebers den Backup-Server von Grund auf aus vorhandener Hardware oder neu angeschaffter aufbauen zu lassen und seiner Wahl des Anbieters für den Backup-Space, sollte mit der Projektdurchführung begonnen werden.
    • Dem Aufbau des Backup-Servers, dessen Installation, Konfiguration und Einbindung in das vorhandene LAN.
    • Dem Installieren und Konfigurieren geeigneter Backup-Software.
    • Dem Testen des Backup-Systems durch Funktionstests.
    • Dem Vorführen des funktionierenden Backup-Systems.
    • Und final der Einweisung des Auftraggebers zur selbstständigen Pflege und Überwachung des Backup-Systems nach Beendigung des Projektauftrags.

IST-Analyse

  • Um das Projekt durchführen zu können, wurde eine Ist-Analyse des vorhandenen LANs, den Clients lincln01, lincln02 und debian02 vor Ort und den Servern mx10, mx20 und mx50 erstellt.
  • Bisher war keine Infrastruktur für den Backup-Space vorhanden.
  • Das Backup wurde unregelmäßig direkt vom Client durchgeführt.
  • Es war kein Backup-Server im LAN vorhanden.
  • Das Datenvolumen der zu sichernden Daten betrug bisher ca. 1 TB, wird aber mit geringer Zuwachsrate sukzessive wachsen.

Vorhandene Infrastruktur

NEU: DOCSIS 3.1

  • Bei der Dirk Wagner Berlin war ein Internet-Zugang mit 1 Gbit/s Bandbreite via Koaxialnetz (DOCSIS 3.1) vorhanden.
  • Ein Router, auf dem das Betriebssystem OPNsense llief, diente als Gateway.
  • Die Clients lincln01, lincln02 waren in das LAN integriert.
  • Der Client debian02 war WLAN in das LAN integriert.
  • Die Clients mx10, mx20 und mx50 waren über das Internet erreichbar.

NEU: Bild

Backup-Clients Funktion Betriebssystem Ip-Adresse
linncln01.localdomain Workstation Debian Testing 192.168.1.100
lincln02.localdomain Workstation Debian Stable 192.168.1.200
debian02.localdomain Laptop Debian Testing 192.168.1.300
mx10.foxtom.de Webserver Debian Stable 116.202.118.50
mx20.foxtom.de Webserver Debian Stable 81.169.207.103
mx50.foxtom.de Webserver Debian Stable 95.216.156.241

NEU: Einträge

weitere Netzwerk/Hardwaren Funktion Betriebssystem Ip-Adresse
opnsense.localdomain Router, Firewall, DHCP, DNS OPNsense 192.168.1.1 / 91.66.18.81
TP-Link T2600G-18TS L2 managed Switch 192.168.1.254
TP-Link EAP330 WLAN-Access-Point 192.168.1.188

NEU: CAT 7 zu CAT 6

  • Alle Netzwerk/Hardwaren waren via CAT-6-Kabel mit dem Switch verbunden. Ausnahme war der Client debian02, dieser war über WLAN über einen WLAN-Access-Point mit dem LAN verbunden.

SOLL-Konzept

  • Mit dem Auftraggeber wurden verschiedene Backup-Strategien durchgesprochen. Mit dem Ergebnis, dass die 3-1-Strategie umgesetzt werden sollte.
  • Diese 3-1-Strategie wurde von der 3-2-1-Strategie abgeleitet, auf das Ausspielen des Backups auf Magnetband sollte auf Kundenwunsch verzichtet werden.
    • Die Daten sollten demnach dreifach gehalten werden. Auf den Backup-Clients lincln01.localdomain, lincln02.localdomain, debian02.localdomain, mx10.foxtom.de, mx20.foxtom.de und mx50.foxtom.de, dem Backup-Server linsrv01.localdomain und in einem Backup-Space.
    • Mindestens ein Backup sollte extern gelagert werden.
  • Dadurch sollte ein zweistufiges Backup-System realisiert werden.
  • Das Backup-System sollte eine Langzeitarchivierung von bis zu zwei Jahren ermöglichen.
  • Um das Verfügbarkeitslevel des Backup-Servers zu steigern, sollte dieser über eine Ausfallsicherheit verfügen.
  • Der Zugriff auf die Backup-Dateien auf dem lokalen Backup-Server sollte schnell und einfach möglich sein.
  • Die Geschwindigkeit und das Komplexitätslevel sollten in Bezug auf den Zugriff auf die extern gelagerten Backup-Dateien eine untergeordnete Rolle spielen.

NEU:Änderung Satz

  • Vor allem sollten die extern zu speichernden Backup-Dateien sicher übertragen und verschlüsselt werden können.

Durchführung

  • Als erstes musste entschieden werden, welche Hardware verwendet werden sollte und welcher Backup-Space gemietet.

Auswahl Hardware und Backup-Space

NEU: Text bis

  • Dem Auftraggeber wurde ein Angebot für Hardware des Backup-Servers zugesendet (siehe AnhangNr) und ebenfalls eine Vergleichsübersicht mit der verhandenen Hardware (siehe AnhangNr.).NEU: hier
  • Um für die Auswahl eines passenden Angebots für den Backup-Server, sowie für den Backup-Space treffen zu können, wurden mit dem Auftraggeber verschiedene Kriterien und deren Gewichtung festgelegt, sowie eine Bewertungsskala.
  • Für die Auswahl der Hardware und des Backup-Space wurde der Einfachheit halber eine gemeinsame Bewertungs- und Gewichtungsskala definiert.
  • Ziel der Erarbeitung der verschiedenen Kriterien und deren Gewichtung war es, auf dieser Basis eine gewichtete Entscheidungsmatrix für die Hardwarezusammenstellung des Backup-Servers, sowie für das Anmieten des Backup-Space zu erstellen.

Gemeinsame Bewertungsskala

  • Die Tabelle zeigt die erarbeitete Bewertungsskala.
Multiplikator Bewertung Beschreibung
3 gut Kriterium voll erfüllt
2 mittel Kriterium teilweise erfüllt
1 schlecht Kriterium nicht erfüllt

Gemeinsame Gewichtungsskala

  • Diese Tabelle zeigt die erarbeitete Gewichtungsskala.
Multiplikator Beschreibung
100 Ist für den Auftraggeber extrem wichtig.
80 Ist für den Auftraggeber sehr wichtig.
60 Ist für den Auftraggeber wichtig.
40 Ist für den Auftraggeber unwichtig.
20 Ist für den Auftraggeber sehr unwichtig.
0 Ist für den Auftraggeber völlig irrelevant.

Hardware

  • Für das Angebot für neue Hardware wurde in Abstimmung mit dem Auftraggeber aus Kostengründen keine Server Tech, sondern Consumer Tech herangezogen.
  • Es wurde darauf geachtet, dass der evtuell neu zu beschaffende Prozessor über eine Grafikeinheit verfügt, da in den Backup-Server keine zusätzliche Grafik eingebaut werden sollte.
  • Zusätzlich zur Entscheidungsmatrix wurde eine vergleichende Übersicht der Hardware erstellt, um die Auswahl der Hardware für den Backup-Server für den Auftraggeber zu vereinfachen NEU (siehe AnhangNr.)NEU . TODO: Nr. des Anhangs angeben

NEU:In den Anhang von

Vergleich Hardware

NEU: 2x250GB

neu vorhanden
Prozessor AMD Ryzen 5 3400G AMD Phenom(tm) II X4 925 2,80GHz
Leistung 3,70GHz Leistung 2,80GHz
Kerne 8 Kerne 4
Mainboard ASUS PRIME X570-PRO ASUStek M4A87TD/USB3
Formfaktor ATX Formfaktor ATX
Arbeitsspeicher 2x Crucial CT2K16G4DFD8266 Kit 4x Kingston ValueRAM DIMM
Geschwindigkeit DDR4 2666MHz Geschwindigkeit DDR3 1333MHz
Kapazität 2x16GB Kapazität 4x4GB
Gesamt 32GB Gesamt 16GB
Netzteil be quiet! STRAIGHT POWER 11 Platinum Inter-Tech Combat Power plus Non-Modular
Leistung 750W Leisung 750W
Formfaktor ATX Formfaktor ATX
Gehäuse be quiet! DARK BASE 900 be quiet!

Pure Base 600 Midi-Tower

Formfaktor Mainboard E-ATX, XL-ATX, ATX, Micro-ATX und Mini-ITX Formfaktor Mainboard ATX, Micro-ATX und Mini-ITX
Datenträger Systemspeicher Samsung 860 EVO Western Digital WD10EARS Caviar Green
Kapazität 2x250GB Kapazität 1TB
Speichertechnik SSD Speichertechnik HDD
Samsung Spinpoint F3 HD103SJ
Kapazität 1TB
Speichertechnik HDD
Gesamt 0,50TB Gesamt 2TB
Datenträger Datenspeicher 4x Western Digital WD40EZRX Caviar Green Western Digital WD20EZRX
Kapazität 4x4TB Kapazität 2TB
Speichertechnik HDD Speichertechnik HDD
Samsung Spinpoint F3 HD103SJ
Kapazität 2TB
Speichertechnik HDD
HITACHI Deskstar
Kapazität 2TB
Speichertechnik HDD
TOSHIBA P300
Kapazität 2TB
Speichertechnik HDD
Gesamt 16TB Gesamt 8TB

NEU:In den Anhang bis hier.

Entscheidungsmatrix

TODO: aus Kriterien Tabelle machen

Kriterien
  • Folgende Kriterien wurden mit dem Auftraggeber erarbeitet:
    • Geschindigkeit CPU:
      • Sollte mindestens 2,4GHz und 4 bis 8 Kerne haben.
    • Kapazität Arbeitsspeicher:
      • Sollte mindestens 16GB an Kapazität aufweisen.
    • Geschwindigkeit Arbeitsspeicher:
      • Sollte mindestens eine Taktfrequenz von 1333MHz haben.
    • Kapazität Datenspeicher:
      • Sollte mindetstens 4TB effektiven Datenspeicher haben.
    • Zukunftssicherheit:
      • Sollte mindestens durch 2 weitere Datenträger für den Datenspeicher erweitert werden können.
    • Kosten:
      • Sollte so kostengünstig wie möglich sein. Höchstens waren 2000,00€ an Ausgaben durch den Auftraggeber angedacht, wenn die neue Hardware ausreichende Vorteile gegenüber der vorhandenen Hardware ausweist.
Auswertung
Kriterien Gewichtung Hardware
neu vorhanden
Bewertung Wert Bewertung Wert
Geschindigkeit CPU 20 3 60 2 40
Kapazität Arbeitsspeicher 40 3 120 2 80
Geschwindigkeit Arbeitsspeicher 20 3 60 2 40
Zukunftssicherheit 20 3 60 1 20
Kapazität Datenspeicher 80 3 240 2 16
Kosten 100 1 100 3 300
Gesamtergebnis 16 640 11 640
  • Aufgrund der Auswertung der Entscheidungsmatrix entschied sich der Auftraggeber für den Aufbau des Backup-Servers aus vorhandener Hardware.
  • Der Auftraggeber wurde darauf hingewiesen, dass durch die Verwendung vorhandener Hardware das Fehlerpotential des Backup-Systems steigt und damit der zuerwartende Aufwand der Wartung.
  • Zudem ist davon auszugehen, dass das Verfügbarkeitslevel dadurch gesenkt wird.

Backup-Space

Vergleich Backup-Space

  • Zusätzlich zur Entscheidungsmatrix wurde eine vergleichende Übersicht der Anbieter für Backup-Space erstellt, um die Auswahl eines Anbieters für den Auftraggeber zu vereinfachen.
Leistungsmerkmale Strato HiDrive Business Basic S3 Hetzner BX40
Preis pro TB 13,33€ 5,74€
Mindestkapazität 3TB 2TB
Tarffic-Begrenzung Outbound/Monat 0,05 € pro GB/mtl. 10TB
Standort(e) Deutschland Deutschland, Finnland
Erweiterbarkeit jeder Zeit jeder Zeit
Mindestvertragslaufzeit 1 Monat keine
Kündigungsfrist 30 Tage zum Laufzeitende 30 Tage zum Monatsende
Zugriffsprotokolle SFTP, SCP, WebDAV, rsync via SSH, SMB/CIFS FTP, FTPS, SFTP, SCP, SMB/CIFS, BorgBackup, rsync via SSH, HTTPS, WebDAV

Entscheidungsmatrix

TODO: aus Kriterien Tabelle machen

Kriterien
  • Ein vorab festehendes Kriterium des Auftraggebers war, dass es keinerlei Begrenzung oder Berechnung für Inbound-Traffic beim Anbieter des Backup-Space gibt.
  • Folgende Kriterien wurden mit dem Auftraggeber für die Auswahl des Backup-Space erarbeitet.
    • Preis pro TB:
      • Bezugsgrenze war der mit dem Auftraggeber definierte Bereich 2TB an Datenspeicher.
    • Traffic-Begrenzung Outbound:
      • Drosselung der Upload- und Download-Geschwindigkeit, wenn ein bestimmtes Traffic-Volumen erreicht wurde. Der Auftraggeber bevorzugte es, wenn keine Traffic-Begrenzung vorliegt.
    • Standort(e) D und/oder EU:
      • Die Server sollten nach Präferenz des Auftraggebers zwingend in Deutschland oder im EU-Ausland stehen.
      • Wenn Server in mehreren Ländern stehen, bevorzugte der Auftraggeber, dass diese selbstständig festgelegt werden können.
    • Erweiterbarkeit:
      • Dem Auftraggeber war es wichtig, dass der Datenspeicher, wenn nötig, schnell nach oben skaliert werden kann.
    • Mindestvertragslaufzeit:
      • Der Auftraggeber wollte wissen, wie schnell und flexibel kann der Backspace, vetraglich an sich ändernde Anforderungen angepasst werden kann. Der Auftraggeber bevorzugte eine möglichst kurze bzw. gar keine Mindestvertragslaufzeit.
    • Zugriffsprotokolle:
      • Der Auftraggeber wollte, dass die Zugriffsprotokolle FTP, FTPS, TFTP und SFTP verwendet werden können.
    • Reputation:
      • Die Reputation wurde nach Erfahrungswerten definiert.
Auswertung
Kriterien Gewichtung Anbieter
Strato HiDrive Business Basic S3 Hetzner BX40
Bewertung Wert Bewertung Wert
Preis pro TB 80 2 160 3 240
Traffic-Begrenzung Outbound 60 1 60 2 120
Standort(e) D und/oder EU 100 2 200 3 300
Erweiterbarkeit 60 2 120 2 120
Mindestvertragslaufzeit 80 3 240 3 240
Zugriffsprotokolle 100 3 300 3 300
Reputation 100 1 100 3 300
Gesamtergebnis 14 1180 19 1620
  • Aufgrund der Auswertung der Entscheidungsmatrix entschied sich der Auftraggeber für das Angebot von Hetzner.

Vorbereitung der Realsierung der Ausfallsicherheit

  • Die Ausfallsicherheit des Backup-Servers sollte durch das Einrichten von RAID-Verbünden für den Systemspeicher und den Datenspeicher realisiert werden.

TODO: aus RAID-Rechnung Tabelle machen

Auswahl RAID-Verbund

  • Für den Systemspeicher kam mit den zwei dafür eingeplanten 1TB-Datenträgern nur RAID1 in Frage.
    • RAID 1 - (2 - 1) * 1 TB = 1 TB effektiver Speicherplatz; 1TB Parität.
  • Das RAID1 für den Systemspeicher sollte während der Installation des Betriebssystems eingerichtet werden.
  • Für den Datenspeicher mit vier dafür eingeplanten 2TB-Datenträgern kamen mehrere RAID-Level in Frage, RAID10, RAID5 und RAID6.
    • RAID 10 - (4 / 2) * 2 TB = 4 TB; Sub-RAID 1 mit jeweils 2TB Parität
      • Verfahren: Striped Mirrors
      • Komplexer als RAID5 oder RAID6 und damit höheren Zeiten bei Resynch und Rebuild.
    • RAID 5 - (4 - 1) * 2 TB = 6 TB; 2 TB Parität
      • Verfahren: Parität Stripped
      • leicht skalierbar
    • RAID 6 - (4 - 2) * 2 TB = 4 TB; 4 TB Parität
      • Verfahren: doppelte Parität Stripped
      • leicht skalierbar
  • Da bei RAID10 bei besserer Performance als RAID5 und RAID6 zwar zwei Datenträger ausfallen dürfen, allerdings nicht zwei des selben Sub-RAIDs und bei RAID5 im Vergleich zu RAID6 nur die halbe Parität vorliegt, wurde sich für RAID6 für den Datenspeicher entschieden.

Vorgezogene Sicht- und Funktionsprüfung der Datenträger

  • Es wurden keine offensichtlichen Defekte an den Datenträgern festgestellt.

TODO: SMART

  • SMART: smartctl, gsmartcontrol

Datenbereinigung - dd (disk dump)

  • Danach wurden mit dd die Datenträger vollständig bereinigt, um sicher zugehen, dass keine eventuell störenden Daten darauf vorhanden sind.
# dd if=/dev/zero of=/dev/sda status=progress
1132235649536 bytes (1,1 TB, 1,0 TiB) copied, 29019 s, 39,0 MB/s

Hardware

Backup-Server

TODO: mit GIMP kleineren Ausschnitt beschriftete Datenträger

TODO: Angabe mit Bezeichnung der Teile

  • Als erstes wurde eine Sichtprüfung aller Komponenten auf offensichtlichen Defekt durchgeführt.
  • Es wurden keine offsichtlichen Defekte festgestellt.
  • Im Anschluss konnte dann eine einfache Funktionsprüfung erfolgen.
  • Für eine bessere Wartbarkeit der RAID-Verbunde wurden alle sechs Datenträger vor ihrem Einbau mit ihren Seriennummern beschriftet.
  1. Installationshandbuch zu Mainboard konsultiert (Pinbelegung).
  2. Vor der Montage: Erdung, um die statische Aufladung abzuleiten, die ansonsten die sensiblen elektronischen Bauteile beschädigen könnte.
  3. Einbau der Gehäuselüfter im Servergehäuse.
  4. Blende des Motherboard-Herstellers an dem Gehäuse befestigt (da die Hauptplatine nicht zu der entsprechenden Blende auf dem Gehäuse passte).
  5. Hauptplatine:
    1. Prozessor: Wärmeleitpaste wurde auftragen.
      1. Gleichmäßige Schicht auf die Oberseite des Prozessors.
      2. Dünn, aber vollständig mit Paste bedeckt, damit eine optimale Verbindung zwischen Lüfter und Prozessor gewährleistet wird.
    2. Einbau des Prozessors mit dazugehörigem Lüfter.
    3. Die Lüfter wurden mit ihren Stromversorgungen auf der Hauptplatine verbunden.
    4. Einbau Arbeitsspeicher in die entsprechenden Steckplätze.
    5. Die Hauptplatine wurde in das Gehäuse eingebaut.
      1. Mitgelieferte Abstandshalter und Schrauben wurden verwendet.
      2. Die Schrauben wurde nicht zu fest angezogen, um Beschädigungen an der Platine zu vermeiden.
  6. Einbau der Datenträger.
    1. Als Vorplanung zur Einrichtung des RAIDs: Eindeutige Kennzeichnung der Datenträger mit den Seriennummern, um bei einem Ausfall eines Datenträgers, diesen eindeutig identifizieren zu können.
  1. Anschluss aller Stromkabel.
  2. Anschluss aller Datenkabel.
  3. Anschluss der Netzwerkkabel (CAT 7).
  4. Server testweise anschaltet.


Automatische Einbindung in das Netzwerk

  • Da im LAN des Auftraggebers ein DHCP-Server vorhanden war, wurde die Netzwerkkarte des geplanten Backup-Servers automatisch für dieses Netzwerk konfiguriert.

Betriebssystem

Debian Stable

  • Da die Netzwerkkarte des geplanten Backup-Servers via DHCP-Server konfiguriert wurde und der Internetzugang gegeben war, wurde am Client lincln02 das kleine Installationsimage zur Netzinstallation von Debian Stable von der Website https://www.debian.org/distrib/netinst heruntergeladen.
debian-10.6.0-amd64-netinst
  • Dieses ISO-Image wurde mit dem Programm dd auf einem USB-Stick bootfähig gespeichert.
  • Im BIOS des geplanten Backup-Servers wurde die Bootreihenfolge geändert, so dass zuerst vom USB-Stick gebootet wurde.
  • Das Betriebssystem Debian stable wurde ohne grafische Oberfläche installiert, da diese nicht benötigt wird und das System unnötigt verlangsamen würde.
  • Während des Installationsvorgangs des Betriebssystems wurde für den Systemspeicher das Software-RAID RAID1 eingerichtet.
  • Danach wurde die Bootreihenfolge im BIOS erneut geändert, so dass von einem der Datenträger im erstellten RAID1 gebootet wurde.

Einrichtung Ausfallsicherheit - Software-RAID

Vorbereitung

Partitionierung - fdisk (fixed disk)
  • Zuerst wurden die Bezeichnungen der Datenträger ausgelesen, /sda, sdb usw..
  • Danach konnte mit der Partitionierung begonnen werden.
  • Als erstes wurde GPT (GUID Partition Table) als das Disklabel der Partionstabelle angelegt.
  • Anschließend wurde die Partitionstabelle anlegt.
  • Am Anfang des Laufwerks wurden 2048 Sektoren bewußt ungenutzt gelassen, um ein optimales Alignment zu ermöglichen.
  • Ebenfalls wurden mindestens 8192 Sektoren am Ende der Festplatte ungenutzt gelassen, falls nach Jahren kein baugleicher Datenträger mehr beschafft werden kann, ermöglicht es der frei gelassene Platz auch Datenträger als Ersatz zu nehmen, die einige Sektoren weniger haben.
  • Zum Schluss wurde die Partition als Linux-RAID-Partion markiert.
  • Dieser Vorgang wurde für alle Datenträger durchgeführt.

RAID-Verbund erstellen

  • Ein RAID 6 aus vier Datenträgern über die vier Partitionen sda1, sdb1, sdc1 und sdd1 wurde mit dem Programm mdadm (multiple disk administration) erstellt.
  • mdadm bildet die Schnittstelle zu den RAID-Funktionen des Kernels.
# mdadm --create /dev/md1 --auto md --level=6 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
Dateisystem und Alignment
  • Um eine bestmögliche Performance des RAID-Verbunds zu ermöglichen, wurde auf das optimale Alignment geachtet.
  • Als erstes wurde die Chunk-Size ermittelt, also die Größe eines RAID-Blocks.
# mdadm -D /dev/md1 | grep "Chunk Size" 
Chunk Size : 512K
  • Um das optimale Alignment festzulegen, musste noch die block-size, stride-size und stripe-width ermittelt werden.
  • Die block-size ist die Größe der Dateisystemblöcke in Bytes. Da heutzutage fast ausschließlich 4096 Byte (4 KiB) Blöcke verwendet werden, wurde diese Größe gewählt.
  • Die stride-size ist die Chunk Size umgerechnet in Dateisystemblöcke. Bei einer 512 KiB großen Chunk Size mit 4 KiB Blöcken ergab sich 512 KiB/ 4 KiB = 128.
  • Die stripe-width ist die Größe eines Datenstreifens, also die Menge an Blöcken, die geschrieben wird, wenn ein voller Chunk auf jedes Laufwerk geschrieben wird. Diese berechnet sich aus stride-size * Anzahl der effektiv nutzbaren Partitionen. Bei einem RAID 6 über 4 Partitionen ergab sich hier 128 * 2 = 256.
  • Als Dateisystem sollte ext4 verwendet werden.


# mkfs.ext4 -b 4096 -E stride=128,stripe-width=256 /dev/md1
RAID-Verbund mounten
  • Das RAID musste nun noch persistent in die Verzeichnisstruktur eingebunden werden.
  • Dies wurde über den entsprechenden Eintrag in der /etc/fstab realisiert.
  • Da es unter Umständen zu Problemen führen kann, wenn die aktuelle Bezeichnung des Datenträgers verwendet wird, z. B. md0. Diese kann sich systembedingt selbststänig beim nächsten Starten des Systems ändern, z. B. von md1 zu md127, wurde die UUID (Universally Unique Identifier) verwendet, da diese absolut eindeutig ist, da diese sich nicht ändert.
  • Als erstes wurde die UUID ausgelesen.
# ls -l /dev/disk/by-uuid
lrwxrwxrwx 1 root root 11 Dez  4 06:41 7207e28c-25ac-43cc-8ed5-f02d7b816463 -> ../../md1
  • Und diese in die /etc/fstab eingetragen.
# vi /etc/fstab
UUID=7207e28c-25ac-43cc-8ed5-f02d7b816463     /media/daten      ext4      defaults 0 2
  • Als Mountpoint wurde das Verzeichnis /media/daten festgelegt.
  • Desweiteren musste das Dateisystem des RAID-Verbunds (ext4) angegeben werden.

TODO: defaults 0 2 erläutern

Hetzner storagebox bx40 einrichten

NEU:gesamter Text

  • Es wurde die storagebox bx40 von Hetzner angemietet.
  • Nach Erhalt der Zugangsdaten, des Benutzernamens, wmusste der Backup-Space über die Website von Hetzner konfiguriert werden.
  • Es musste der SSH-Support und die externe Erreichbarkeit erlaubt werden, da bis zur aktiven Freigabe durch den Kunden, der externe Zugriff in der Standardkonfiguration deaktiviert war.

Backup-Software

  • rsnapshot: Backup kann nach Inhalten durchsucht werden, da es dateibasiert arbeitet.
  • Man kann u.a. den "find"-Befehl benutzen, auch grep, um gezielt nach Dateien im Backup zu suchen.
  • Außerdem kann den usern Zugriff auf das Backup mit Leserechten gewährt werden über eine Netzwerkfreigabe des Netzwerkprotokolls NFS, bei dem der user auf Dateien zugreifen kann, als ob sie auf ihrer lokalen Festplatte abgespeichert wären.
  • 1zu1-Backup => schneller Zugriff auf Backup-Dateien.
  • duply: Backup verschlüsselt und komprimiert => sicher, speicherplatzeffizient, langsamer Zugriff auf Backup-Dateien.

Rsnapshot konfigurieren

  • rsnapshot arbeitet nach dem Pull-Model.
    • Die Daten werden vom Backup-Server bei den Clients abgeholt.

NEU:Text streichen von...

  • Die Angabe der config_version musste auskommentiert bleiben, denn eine Version muss definiert sein, da rsnapshot sonst nicht funktioniert.

NEU:Text streichen bis hier.

  • Das Ziel für die Backup-Dateien wurde festgelegt.
snapshot_root   /media/daten/rsnapshot/
  • Die Verwendung von rsynch musste zwingend erlaubt sein. Da rsnapshot auf rsynch basiert.
cmd_rsync       /usr/bin/rsync
  • Die Anmeldung sollte per ssh erfolgen.
cmd_ssh /usr/bin/ssh
  • Es musste angegeben werden, über welchen Port die ssh-Verbindung aufgebaut werden soll. An der Firewall des Auftraggebers ist dafür der Port 2227 vorgesehen.
ssh_args        -p2227
  • Weiter wurde festgelegt, wie viele Snapshots aufbewahrt werden sollen.
retain  daily      7
retain  weekly     4
retain  monthly    3
retain  quartarly  4
retain  annual     2
  • Der Speicherort der Log-Datei von rsnapshot wurde festgelegt.
logfile /var/log/rsnapshot.log
  • Weiter war es sehr wichtig das Anlegen der Lockfile zu erlauben, denn diese verhindert, dass zwei Instanzen gleichzeitig ein Backup durchführen können.
lockfile        /var/run/rsnapshot.pid
  • Zum Abschluss wurden die zu sichernden Verzeichnisse auf den verschiedenen Clients festgelegt.
  • Syntax: Befehl Quelle Ziel
backup  root@lincln01:/etc/             lincln01/
backup  root@lincln02:/etc/             lincln02/
backup  root@debian02:/etc/             debian02/
backup  root@mx10.foxtom.de:/etc/       mx10/
backup  root@mx20.foxtom.de:/etc/       mx20/
backup  root@mx50.foxtom.de:/etc/       mx50/

Verbindung per ssh: rsnapshot zu Servern und Clients

  • Ziel: Sicherer Zugriff vom Backup-Server mit rsnapshot auf Server und Clients, um die zu sichernden Verzeichnisse und Dateien in das rsnapshot-Backup zu übertragen.
  • Die Authentifizierung sollte nicht durch ein Passwort erfolgen, sondern durch einen Schlüssel (asymmetrisch, ssh-key). Gilt als praktikabler und sicherer.

Schlüssel sicher übertragen

  • Auf die Clients lincln01, lincln02 und debian02.
  • Auf die Server mx10, mx20 und mx50.
root-Login per ssh zeitweise auf den Clients erlauben
  • Der root-Login wurde nur für die Schlüsselübetragung erlaubt, um das Zeitfenster für eine Brute-Force-Attacke zu klein wie möglich zu halten.
  • Als erstes wurde eine ssh-Verbindung als user über die Eingabe des user-Passworts aufgebaut.
$ ssh user@lincln02.localdomain
user@lincln02.localdomain's password:
  • Anschließend wurde mit dem root-Passwort in den root-Account gewechselt.
$ su -
Passwort:
  • Mit dem vi-Editor wurde die Datei sshd_config bearbeitet und der ssh-Login als root erlaubt.
# vi /etc/ssh/sshd_config
  • Ändern von no auf yes.
PermitRootLogin yes
  • Änderung wurde gespeichert und der Dienst neu gestartet.
# /etc/init.d/ssh restart
  • Lockout wurde durchgeführt, um wieder auf den Backup-Server zurückzuwechseln.
ssh-Schlüssel per root-Login mit Passwort übertragen
  • Mit dem Befehl ssh-copy-id und der Eingabe des root-Passworts wurden die Schlüssel auf alle Backup-Clients verteilt.
# ssh-copy-id -p Portnummer root@domain
password:
root-Login per ssh auf den Clients wieder verbieten
  • Anschließemd wurde eine ssh-Verbindung als root über die Eingabe des root-Passworts aufgebaut und der root-Login über Passworteingabe wieder untersagt.
# vi /etc/ssh/sshd_config
  • Indem der root-Login über die Passworteingabe mit der Option prohibit-password untersagt wurde.
PermitRootLogin prohibit-password
  • Die Änderung wurde gespeichert und der Dienst neu gestartet.
# /etc/init.d/ssh restart
  • Nun lief der root-Login über ssh mit Schlüsseln anstatt mit einer Passwortabfrage.
  • Dies war nötig, damit sich rsnapshot in Zukunft automatisch auf den Clients anmelden kann, da mit rsnapshot die automatisierte Passworteingabe nicht möglich ist.
Manuelles Testen der Verbindungen
  • Um sicher zugehen, dass das Login über ssh automatisiert funktioniert, wurden die Verbindungen manuell getestet.
# ssh -p2227 root@lincln01.localdomain

NEU:Text streichen von... 

# ssh -p2227 root@lincln02.localdomain

# ssh -p2227 root@debian02.localdomain

# ssh -p2227  root@mx10.foxtom.de

# ssh -p2227 root@mx20.foxtom.de

# ssh -p2227  root@mx50.foxtom.de

NEU:Text streichen bis hier.

  • Die Tests verliefen erfolgreich.

Kryptografie der duply-Archive einrichten

  • Das Backup-Programm duply verwendet gpg (GNU privacy guard), um die Backup-Dateien zu verschlüsseln.
  • Aus diesem Grund musste zuerst ein neues Schlüsselpaar erstellt werden.

GnuPG Key erstellen

  • Es standen zwei Wege zur Verfügung, um das neue Schlüsselpaar zu erstellen
gpg --gen-key

und 

gpg --full-generate-key
  • Bei der Verwendung der Option --gen-key werden automatisch vorgegebene Standardwerte zur Erstellung des Schlüsselpaares verwendet, z. B. als Schlüssellänge 3072 Bit.
  • Da der Auftraggeber großen Wert auf Sicherheit legte und dafür Performanceeinbußen in Kauf nimmt, wurde das Schlüsselpaar mit der Option --full-generate-key erstellt mit einer Schlüssellänge von 4096 Bit (siehe Anhang "Erstellung gpg-key").

NEU:In den Anhang von

Key-ID anzeigen lassen

Private-Key 

gpg --list-secret-keys --keyid-format LONG

Konsole 

root@linsrv01:~# gpg --list-secret-keys --keyid-format LONG
gpg: "Trust-DB" wird überprüft
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Tiefe: 0  gültig:   1  signiert:   0  Vertrauen: 0-, 0q, 0n, 0m,  0f, 1u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2021-11-04
/root/.gnupg/pubring.kbx
------------------------
sec   rsa4096/F47E1B7450082D11 2020-11-04 [SC] [verfällt: 2021-11-04]
      60E3D3C9ED78CE4A40322BBAF47E1B7450082D11
uid              [ ultimativ ] Robert Quies (Es grünt so grün, wenn  Spaniens Blüten blühn.) <raqju@web.de>
ssb   rsa4096/B2E20485FF7FC772 2020-11-04 [E] [verfällt: 2021-11-04]

Public-Key 

gpg --list-keys --keyid-format LONG

Konsole 

root@linsrv01:~# gpg --list-keys --keyid-format LONG
/root/.gnupg/pubring.kbx
------------------------
pub   rsa4096/F47E1B7450082D11 2020-11-04 [SC] [verfällt: 2021-11-04]
      60E3D3C9ED78CE4A40322BBAF47E1B7450082D11
uid              [ ultimativ ] Robert Quies (Es grünt so grün, wenn Spaniens Blüten blühn.) <raqju@web.de>
sub   rsa4096/B2E20485FF7FC772 2020-11-04 [E] [verfällt: 2021-11-04]

NEU:In den Anhang bis hier

Duply konfigurieren

  • duply arbeitet nach dem Push-Model
    • Die Daten sollten vom Backup-Server in den Backup-Space übermittelt werden.
  • Übertragung über eine durch Kryptografie gesicherte Verbindung, da Internet ein unsicheres Netz darstellt.
  • Kryptografie der Daten zur sicheren Lagerung auf einem unsicheren Medium, dem Backup-Space, da es sich dabei um eine Public Cloud handelt.

Profil erstellen

  • Um duply konfigurieren zu können, musste als erstes ein Profil erstellt werden. Das Profil wurde mit dem Namen duply_backup benannt.
duply duply_backup create
  • Dadurch wurde unter /root/.duply/backuptest/ die Dateien conf und exclude automatisch erstellt.
# duply ersatzBU create

Congratulations. You just created the profile 'ersatzBU'.
The initial config file has been created as 
'/root/.duply/ersatzBU/conf'.
You should now adjust this config file to your needs.

IMPORTANT:
  Copy the _whole_ profile folder after the first backup to a safe place.
  It contains everything needed to restore your backups. You will need 
 it if you have to restore the backup from another system (e.g. after a 
 system crash). Keep access to these files restricted as they contain 
 _all_ informations (gpg data, ftp data) to access and modify your backups.

  Repeat this step after _all_ configuration changes. Some configuration options are crucial for restoration.

Konfiguration

vi /root/.duply/backuptest/conf
  • Es wurde festgelegt, welcher Schlüsselsatz zur Kryptografie verwendet werden soll, indem die Key-ID und das dazugehörige Passwort eingetragen wurde.
GnuPG_KEY=' Key-ID des generierten Schlüsselsatzes'
GnuPG_PW='Festgelegtes Passwort des Schlüsselsatzes'
  • Kompression der duply-Archive:
    • Als Algorithmus zur Komprimierung wurde bzip2 festgelegt.
    • Da dem Auftraggeber Speicherkapazität vor Geschwindigkeit geht, wurde das höchste Kompressionslevel 9 gewählt.
    • Das spart Speicherkapazität, erhöht aber die Recovery Time.
    • Als bevorzugtes Kryptografieverfahren wurde AES256 (symmetrisch) festgelegt.
GnuPG_OPTS='--compress-algo=bzip2 --bzip2-compress-level=9 --personal-cipher-preferences AES256 '
  • Als Ziel wurde die Adresse des Backup-Space eingetragen. Als Verbindungsprotokoll sollte sftp verwendet werden und die Verbindung über Port 23, anstatt Port 22 aufgebaut werden.
TARGET=' sftp://user@domain:23/Pfad_zum_Ordner'
  • Die Quelle der zu sichernden duply-Archive wurde festgelegt. Alles unter dem root-Wurzelverzeichnis. Genaueres wurde in der exclude-Datei festgelegt.
SOURCE= '/'
  • duply wurde vom synchronen auf asynchrones Abarbeiten der Dateien umgestellt, da dadurch Backup-Dateien effizienter abgearbeitet werden.
  • duply kann dadurch bereits verschlüsselte Backup-Dateien hochladen, während gleichzeitig andere Backup-Dateien gerade verschlüsselt werden.
  • Im synchronen Modus dagegen würde jede Backup-Datei nacheinander erst verschlüsselt und dann hochgeladen werden.
DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "
  • Eine Aufbewahrungszeit von sechs Monaten bis zum Überschreiben eines duply-Archives wurde festgelegt.
MAX_AGE=6M
  • Als Anzahl an aufbewahrten Full-Backups wurde vier festgelegt.
MAX_FULL_BACKUPS=4
  • Alle drei Monate soll ein Full-Backup erstellt werden. Dieser Befehl erzwingt eine vollständige Sicherung, wenn die letzte vollständige Sicherung ein bestimmtes Alter erreicht hat.
MAX_FULLBKP_AGE=3M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "
  • Paketgröße der übertragenen Pakete wurde auf 100 kb festgelegt.
VOLSIZE=100
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
  • Ausführlichkeit der log-Einträge wurde festgelegt.
VERBOSITY=8

Festlegen der zu sicherden Verzeichnisse - exclude

+ /etc
- **

Verbindung per ssh: lokaler Backup-Server zu Online-Backup-Space

  • Ziel war es dadurch einen sicheren Zugriff vom Backup-Server mit duply auf den Backup-Space zu gewährleisten, um die zu sichernden Verzeichnisse und Dateien in den Backup-Space zu übertragen.

Neues SSH-Schlüsselpaar generieren

  • Als erstes wurde ein neues Schlüsselpaar generiert.
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:3ZeuQsMoEyjbiFkgf+GsWabX7dugttaCoM1fZTySTao root@linsrv01
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|o   .            |
|.o o o  .        |
|  + B .* . .   . |
| + % .+oSo. . o  |
|o B o.++o.+  o   |
| + oE..=.. .  .  |
|. o ..+.oo.  .   |
|   ..ooo.....    |
+----[SHA256]-----+
  • Damit das Einloggen später automatisch, d.h. hier ohne Passphrasenabfrage, funktioniert, wurde bei den Punkten
    • Enter passphrase (empty for no passphrase):
    • Enter same passphrase again:
  • nichts eingeben.
  • Das macht den Private-Key zwar etwas unsicherer, aber da rsn in der Abwägung Praktikabilität zu Sicherheit zu verkraften.
  • Der erstellte Schlüsselsatz wurde unter /root/.ssh/id_rsa abgelegt.

ssh-key in das PEM-Format umwandeln

  • duplicity benötigt den ssh-key im PEM-Format (Privacy Enhanced Mail), wenn duplicity sich via ssh anmelden soll.
  • Deshalb wurde dieser in das PEM-Format umgewandelt.
# ssh-keygen -p -f /root/.ssh/id_rsa -m pem -P "" -N ""

authorized_keys-Datei erstellen

# cat /root/.ssh/id_rsa.pub >> /root/.ssh/storagebox_authorized_keys

authorized_keys-Datei hochladen

# echo -e "mkdir .ssh \n chmod 700 .ssh \n put /root/.ssh/storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp -P23 user@domain
user@domain's password: 
Connected to user@domain.
sftp> mkdir .ssh 
sftp>  chmod 700 .ssh 
Changing mode on /home/.ssh
sftp>  put /root/.ssh/storagebox_authorized_keys /home/.ssh/authorized_keys 
Uploading /root/.ssh/storagebox_authorized_keys to /home/.ssh/authorized_keys
/root/.ssh/storagebox_authorized_keys  100%  395    13.5KB/s   00:00    
sftp>  chmod 600 /home/.ssh/authorized_keys
Changing mode on /home/.ssh/authorized_keys
  • Testen der Verbindung auf Funktionstüchtigkeit durch manuelles Einloggen auf Backup-Space. Es ist nun keine Passworteingabe mehr nötig.
# sftp -P23 user@domain
Connected to user@domain.
sftp>
  • Der Test war erfolgreich.

Automatisierung Backup: cronjob einrichten

Systemweite cron-Tabelle für rsnapshot und duply

TODO: Klärung Vorteil systemweit als Datei zu im root-Account

  • Die cronjobs sollten mit speziellen Rechten (root) ausgeführt werden, deshalb wurden die cronjobs in systemweite Cron-Tabellen eingetragen, um zu verhindern, dass sich Änderungen im root-Account versehentlich auf das Ausführen der cronjobs auswirken können.
  • In der systemweiten cron-Tabelle gibt es eine zusätzliche Spalte, in der der Benutzer mit dessen Rechten der cronjob ausgeführt werden soll, eingetragen wird.
  • Zuerst wurde die cron-Tabelle aus dem root-Account als in das Verzeichnis /etc/cron.d/ kopiert.
  • Neben der /etc/crontab werden nämlich auch alle Dateien im Verzeichnis /etc/cron.d/ von Cron gelesen.
  • Um für eine klare Trennung der cronjobs zu sorgen, wurde eine systemweite cron-Tabelle für rsnapshot und eine für duply erstellt.


rsnapshot
# cat /etc/crontab >> /etc/cron.d/rsnapshot

# vi /etc/cron.d/rsnapshot
.---------------- minute (0 - 59)
|  .------------- hour (0 - 23)
|  |  .---------- day of month (1 - 31)
|  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
|  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
|  |  |  |  |
*  *  *  *  * user-name command to be executed
0 18 * * * root rsnapshot daily
0 19 * * 1 root rsnapshot weekly
0 20 1 * * root rsnapshot monthly
0 22 1 */3 * root rsnapshot quartarly
59 23 1 1 * root rsnapshot annual
  • Es wurde festgelegt, dass rsnapshot
    • sein tägliches Backup an jedem Tag der Woche um 18:00 Uhr durchführen soll.
    • sein wöchentliches Backup an jedem Montag um 19:00 Uhr durchführen soll.
    • sein monatliches Backup am ersten jeden Monats um 20 Uhr durchführen soll.
    • sein vierteljährliches Backup jeden dritten Monat am ersten dieses Monats um 22:00 Uhr durchführen soll.
    • sein jährliches Backup dann am 1. Januar um 23:59 Uhr durchführen soll.
duply
# vi /etc/cron.d/duply

0 0 * * 1 root duply /root/.duply/duply_backup backup
0 0 2 */3 * root duply /root/.duply/duply_backup backup
  • Es wurde festgelegt, dass duply
  • Mit der Option "backup" wurde bestimmt, dass ein Full-Backup erstellt wird, wenn kein bereits vorhandenes Full-Backup im Zielordner vorhanden ist oder wenn die vorhandenen Fullbackups:
Sicherung mit Ausführung vor / nach dem Skript (Stapel: pre_bkp_post).
Vollständig, wenn full_if_older übereinstimmt oder keine frühere Sicherung gefunden wird. 
Inkrementell, in allen anderen Fällen.

TODO: Klärung, ob daraus folgt, dass alles in der conf festgelegt wird.

Rsnapshot

0 16 * * * rsnapshot daily
0 18 * * 1 rsnapshot weekly
0 20 1 * * rsnapshot monthly
0 22 1 */3 * rsnapshot quartarly
59 23 1 1 * rsnapshot annual

duply

0 0 2 */3 * duply /root/.duply/Name_des_Profils backup
0 0 * * 1 duply /root/.duply/Name_des_Profils backup

Restore

rsnapshot

  • Nach der ersten manuellen Backup-Erstellung wurden mit rsync testweise einige Dateien und Verzeichnisse wiederherhestellt.
  • allgemein:
# rsync -avr Quelle_rsnapshot-Archivs Zielordner_für_Dateien
  • Beispiel
# rsync -avr /media/daten/rsnapshot/daily.0/lincln02/media/daten/ebooks /home/user/Dokumente
  • Der Test verlief erfolgreich.

duply

Monitoring

RAID

Manuelle Statusabfrage

# cat /proc/mdstat
mdadm -D /dev/md1

mdadm.conf erstellen

  • Über Ausfälle sollten die Benutzer per E-Mail benachrichtigt werden.
  • Dafür musste für mdadm eine Konfigurationsdatei erstellt werden.
# su -c "/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf"

mdadm.conf editieren

  • In der mdadm.conf muss dafür in der Zeile...
MAILADDR root
  • ...root durch die gewünschte E-Mail-Adresse ersetzt werden.
MAILADDR xzy@abc.org
  • Dafür muss der E-Mail-Versand durch das System eingerichtet sein, z. B. via Postfix als Satellitensystem.

rsnapshot

duply

Qualitätssicherung

  • RAID/Platten i.O.?
  • Dateisystem i.O.
  • Software aktuell
  • Werden cronjobs abgearbeitet?
-- Backup durchführen -- Restore durchführen -- Vergleich der Daten durchführen (sha, diff)

Übergabe

Protokoll

  • Was wird wie, wann und wohin gesichert?
  • Besondere Aufbewahrungregeln existent?
  • Bestätigung, dass das Backup zum Zeitpunkt der Übergabe läuft.
  • Vorgehensweise bei Ausfällen.
  • Klärung der Verantwortlichkeiten
    • Wer ist für was verantwortlich?
    • Monitoring
  • Vorgehensweise bei der Wiederherstellung

Fazit

  • Reflexion
    • Abweichungen SOLL-Zustand zu IST-Zustand
    • Verbesserungpotential aufzeigen
    • Ergebnisse darstellen

Abbildungsverzeichnis

Tabellenverzeichnis

Glossar

Quellen

TODO: Originaldokumentationen als Quellen angeben

Quellen allgemein zur Dokumentation

Abgerufen von „https://wiki.foxtom.de/index.php?title=Backup/Server/Dokumentation&oldid=103975“