Backup/Server/Dokumentation: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Zeile 654: Zeile 654:


==Datenflussdiagramm==
==Datenflussdiagramm==
[[Datei:Dfd4.jpg|700px|thumb|]]
[[Datei:Dfd4.jpg|700px|]]


==Fazit==
==Fazit==

Version vom 8. Dezember 2020, 07:25 Uhr

Projektplanung

Projektauftrag

  • Die Dirk Wagner Berlin ist ein Unternehmen, welches sich um Websites verschiedener Kunden kümmert, diese laufen auf mehreren angemieteten virtualisierten Servern.
  • Der Zugriff auf diese Server erfogt in der Regel über den Client lincln02 in den Räumen der Dirk Wagner Berlin.
  • Es soll ein Backup-Server in einem LAN für Backups des Clients lincln02 und der Server mx10, mx20 und mx50 lokal aufgebaut und eingerichtet werden, zusätzlich ein externer Backup-Space, um die Backups auch extern speichern zu können.

IST-Zustand

  • Bisher ist keine Infrastruktur für den Backup-Space vorhanden.
  • Das Backup wird unregelmäßig direkt vom Client durchgeführt.
  • Es ist kein Backup-Server im LAN vorhanden.
  • Das Datenvolumen der zu sichernden Daten beträgt bisher ca. 1 TB, wird aber sukzessive wachsen.

vorhandene Infrastruktur

  • Bei der Dirk Wagner Berlin ist ein Internet-Zugang mit 1 Gbit/s Bandbreite via Koaxialnetz vorhanden.
  • Ein Router, auf dem das Betriebssystem OPNsense läuft, dient als Gateway.
  • Der Client lincln02 ist in das LAN integriert.
  • Die Server mx10, mx20 und mx50 sind über das Internet erreichbar.

SOLL-Zustand

  • Um den Soll-Zustand zu eroieren, müssen verschiedenste Dinge genau abgeklärt werden.

Bestandsaufnahme

  • Mit dem Auftraggeber muss die RTO (Recovery time objektive) abgeklärt werden.
    • Welche Verfügbarkeitsanforderungen der Daten liegen vor?
    • Welche Reaktionszeiten im Desaster-Fall müssen berücksichtigt werden?
    • Welche Rekonstruktionszeiten für die Wiederherstellung der Daten sind noch akzeptabel?
  • Außerdem die RPO (Recovery point objective).
    • Wie häufig und zu welcher Zeit soll die Datensicherung durchgeführt werden?
    • Welche Backup-Fenster stehen zur Verfügung?
  • Der Vertraulichkeitsbedarf der Daten muss geklärt werden.
    • Müssen Daten gesondert gesichert werden?
    • Müssen Daten mit einem speziellen Passwort verschlüsselt werden?
    • Müssen bei der Auslagerung der Daten spezielle Regeln beachtet werden?
  • Klärung der Abhängigkeit des Unternehmens vom Datenbestand.
    • Daten, die bei Verlust zur Insolvenz führen könnten.
    • Daten, die gesetzlichen Aufbewahrungsbestimmungen unterliegen.
  • Klärung der Aufbewahrungsfristen.
    • Nach gesetzlichen Vorgaben.
    • Nach unternehmensinternen Vorgaben.

Backup-Strategie

  • Mit dem Auftraggeber wurden verschiedene Backupstratien durchgesprochen. Mit dem Ergebnis, dass die 3-1-Strategie angewendet werden soll.
  • Eigentlich 3-2-1-Strategie, aber auf das Ausspielen des Backups auf Magnetband soll auf Kundenwunsch verzichtet werden.
    • Die Daten sollen dreifach gehalten werden:
      • Auf den Clients (lincln02, mx10, mx20, mx50), dem Backup-Server (linsrv01) und im Backup-Space.
    • Mindestens ein Backup soll extern (Backup-Space) gelagert werden.
  • Dadurch soll zweistufiges Backup-System realisiert werden.


  • Ein lokaler Server sollte eingerichtet werden, auf dem die Daten der Clients im LAN gesichert werden.
  • Zusätzlich sollte externer Backup-Space angemietet werden, auf dem die Dateien des lokalen Servers verschlüsselt übertragen und in Archiven gesichert werden sollte.
  • Bestandteil der Lösung sollte ein automatisierter Backup-Turnus sein.
  • Die Hardware für den lokalen Backup-Server sollten neu angeschafft werden.
  • Lokaler Backup-Server:
    • Software-RAID
    • Betriebssystem: Debian Linux 10
    • 4 TB Datenspeicher
  • Online-Backup-Space:
    • 2 TB Datenspeicher
    • Bevorzugter Standort für Server: Deutschland, EU-Ausland
    • Bevorzugte Protokolle für die Dateiübertragung: FTPS (TLS), SFTP (SSH), SCP (SSH)
  • Die Backup-Dateien sollten verschlüsselt auf den externen Backup-Server übertragen werden.
  • Verwendung von Open-Source-Software.

Angebote

  1. Backup-Space
    1. 2 TB Datenspeicher, Vertrag soll flexibel in Bezug auf Laufzeit und Datenspeichererweiterung
  2. Hardware Consumer Tech
    1. Mainboard, Prozessor, RAM (ohne ECC), Datenträger (HDD)
  3. Hardware Server Tech
    1. Mainboard, Prozessor, RAM (ECC), Datenträger (SSD)


Entscheidungsmatrix

Bewertungsskala
Multiplikator Bewertung Beschreibung
3 gut Kriterium voll erfüllt
2 mittel Kriterium teilweise erfüllt
1 schlecht Kriterium nicht erfüllt
Backup-Server
Kriterien Gewichtung Anbieter
Hetzner Online-Backup-Storage IONOS Hidrive IONOS Cloud-Backup Strato Leitz
Preis pro TB 2
Reputation 3
Standort(e) 3
Erweiterbarkeit 2
Vertragslaufzeit 2
Zugriffsprotokolle 3
Ergebnis
Ergebnis gewichtet
Backup-Space
Kriterien Gewichtung Anbieter
Hetzner Online-Backup-Storage IONOS Hidrive IONOS Cloud-Backup Strato Leitz
Preis pro TB 2
Reputation 3
Standort(e) 3
Erweiterbarkeit 2
Vertragslaufzeit 2
Zugriffsprotokolle 3
Ergebnis
Ergebnis gewichtet

Durchführung

Hardware

Backup-Server

  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.


Einbindung in das Netzwerk
  • Der Netzwerkarte des Backup-Servers enp1s0 (MAC: bc:ae:c5:19:d0:f6) wurde via DHCP-Server unter anderem eine statische IP-Adresse zugewiesen.
  • IPv4:
    • Netzwerkadresse: 192.168.1.0/24
    • IP-Adresse: 192.168.1.110
    • Netzmaske: 255.255.255.0
    • Broadcast-Adresse: 192.168.1.255
    • Gateway: 192.168.1.1
    • DNS-Nameserver: 192.168.1.1
  • IPv6:
    • Netzwerkadresse: fe80::/64
    • IP-Adresse: fe80::beae:c5ff:fe19:d0f6
    • Netzmaske: /64
    • Broadcast-Adresse: fe80::ffff:ffff:ffff:ffff
    • Gateway:
    • DNS-Nameserver:

Betriebssystem

Debian 10.6.0 - "Buster" stable

  • Download der debian-10.6.0-amd64-netinst (ISO-Datei)
  • Die ISO-Datei wurde mit dem Programm dd auf USB-Stick gespeichert (bootfähiger USB-Stick).
  • Bootreihenfolge im BIOS wurde geändert, so dass zuerst vom USB-Stick gebootet wurde.
  • Installation von Debian 10.6.0 - "Buster" stable - ohne grafische Oberfläche (wird nicht benötigt und verlangsamt das System)
  • Während der Installation von Debian, Einrichtung des Software-RAIDs für den Systemspeicher (RAID-Level 1) zur Verfügbarkeitssteigerung durch Herstellung einer Ausfallsicherheit des Systemspeichers.
  • Danach wurde die Bootreihenfolge im BIOS erneut geändert, so dass vom erstellten RAID 1 gebootet wird.

Software-RAID

  • Einrichtung des Software-RAIDs(Redundant Array of Independent Disks) für den Datenspeicher des Backup-Servers.
  • Ebenfalls zur Verfügbarkeitssteigerung durch Herstellung einer Ausfallsicherheit des Datenspeichers.
  • Auswahlkriterien zu RAID-Leveln:
    • RAID 0 - 2 TB + 2 TB + 2 TB + 2 TB = 8 TB; keine Parität;
      • Verfahren: Striping
      • fiehl weg, da es keinerlei Ausfallsicherheit bietet.
    • RAID 1 - (4 - 3) * 2 TB = 2 TB; 6 TB Parität;
      • Verfahren: Mirroring
      • fiehl weg, es bietet zwar eine extrem hohe Ausfallsicherheit, aber die effektiv nutzbare Speicherkapazität fällt zu gering aus.
    • RAID 01 - (2 / 2) + (2 / 2) * 2 TB = 4 TB; Sub-RAID 0, jeweils 2 TB Parität
      • Verfahren: Mirrored Stripes
      • Komplexer als RAID 5 oder RAID => fehleranfälliger, höhere Zeiten bei Resynch und Rebuild
    • RAID 10 - (4 / 2) * 2 TB = 4 TB; Sub-RAID 1, jeweils 2 TB Parität
      • Verfahren: Striped Mirrors
      • Komplexer als RAID 5 oder RAID => fehleranfälliger, höhere Zeiten bei Resynch und Rebuild
    • RAID 5 - (4 - 1) * 2 TB = 6 TB; 2 TB Parität
      • Verfahren: Parität Stripped
    • RAID 6 - (4 - 2) * 2 TB = 4 TB; 4 TB Parität
      • Verfahren: doppelte Parität Stripped


Kriterien Gewichtung RAID-Level
RAID 01 RAID 10 RAID 5 RAID 6
Speicherkapazität 2 2 1 2
Ausfallsicherheit 1 1 3 2
Kosten für n Platten 2*n 2*n n+1 n+2
Schreib-Performance 1 1 2 3
Lese-Performance 1 1 3 3
Ergebnis

Vorbereitung

Beschriftung

beschriftete Datenträger

  • Datenträger wurden beim Einbau eindeutig beschriftet mit der Seriennummer, um die Wartung im Fehlerfall zu beschleunigen.
  • Seriennummer bestimmen - hdparm:
# hdparm -i /dev/sda | grep SerialNo
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
Partitionierung - fdisk (fixed disk)
  • Zuerst wurden die Bezeichnungen der Datenträger ausgelesen.
  • 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.

TODO: herausfinden, warum der Link nicht funktioniert.

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 optimale Leistung zu ermöglichen, wurde auf das das optimale Alignment geachtet.
  • Die Chunk-Size wurde ermittelt.
# mdadm -D /dev/md1 | grep "Chunk Size" 
Chunk Size : 512K
  • Als Dateisystem sollte ext4 verwendet werden.
  • Festlegen der block-size, stride-size und stripe-width.
  • block-size:
    • 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.
  • stride-size:
    • Die Chunk Size umgerechnet in Dateisystemblöcke. Bei 512 KiB Chunk Size mit 4 KiB Blöcken ergibt sich 512 KiB/ 4 KiB = 128.
  • stripe-width:
    • 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.


# 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.
# vi /etc/fstab
  • Eintrag für das RAID vornehmen.
  • DaBesser man verwendet die UUID, diese ist absolut eindeutig.
UUID=7207e28c-25ac-43cc-8ed5-f02d7b816463     /media/daten      ext4      defaults 0 2
UUID auslesen
# ls -l /dev/disk/by-uuid

lrwxrwxrwx 1 root root 11 Dez  4 06:41 7207e28c-25ac-43cc-8ed5-f02d7b816463 -> ../../md1

rsnapshot konfigurieren

  • Einrichtung nach dem Pull-Model
    • Daten sollen automatisch vom Backup-Server bei den Clients abgeholt werden.
  • Die Angabe der config_version musste auskommentiert sein. Standard ist 1.2.
config_version  1.2
 
# ROOT DIRECTORY - Ziel für die Backup-Dateien wurde festgelegt.
snapshot_root   /media/daten/rsnapshot/

# EXTERNAL PROGRAM DEPENDENCIES #

# Erhöht die Kompatibilität.
cmd_cp          /bin/cp

# rm-Programm anstatt der built-in perl-Routine sollte verwendet werden.
cmd_rm          /bin/rm

# Die Verwendung von rsynch musste zwingend erlaubt sein. rnsapshot basiert auf rsynch.
cmd_rsync       /usr/bin/rsync

# Anmeldung sollte per ssh erfolgen. 
cmd_ssh /usr/bin/ssh

# Angabe über welchen Port die ssh-Verbindung aufgebaut werden sollte.
ssh_args        -p2227

# syslog support
cmd_logger      /usr/bin/logger

# Festlegung wie viele Snapshots aufbewahrt werden sollten.
retain  daily      7
retain  weekly     4
retain  monthly    3
retain  quartarly  4
retain  annual     2

#GLOBALE OPTIONEN#
# Verbose-Level
verbose         5
# Log-Level
loglevel        4 
# Speicherort der Log-Datei
logfile /var/log/rsnapshot.log
# Lockfile, sollte verhindern, dass zwei Instanzen gleichzeitig ein Backup durchführen können.
lockfile        /var/run/rsnapshot.pid

# Backup-Punkte wurden festgelegt (Quelle Ziel)
backup  root@lincln02:/etc/             lincln02/
backup  root@mx10.foxtom.de:/etc/       mx10/
backup  root@mx20.foxtom.de:/etc/       mx20/
backup  root@mx50.foxtom.de:/etc/       mx50/

Restore

  • 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

Verbindung per ssh: rsnapshot zu Servern und Client

  • 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.
  • 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 den Client lincln02.
  • Auf die Server mx10, mx20 und mx50.
root-Login per ssh zeitweise auf den Clients erlauben
  • Gefahr einer Brute-Force-Attacke, wenn der root-Login erlaubt bleibt.
  • 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 Clients verteilt.
# ssh-copy-id -p Portnummer root@domain
password:
root-Login per ssh auf den Clients wieder verbieten
  • Damit das Zeitfenster einer möglichen Brute-Force-Attacke so klein wie möglich bleibt, wurde eine ssh-Verbindung diesmal als root über die Eingabe des root-Passworts aufgebaut und der root-Login über Passworteingabe untersagt.
# vi /etc/ssh/sshd_config
  • Änderung von yes auf prohibit-password
PermitRootLogin prohibit-password
  • Änderung wurde gespeichert und der Dienst neu starten.
# /etc/init.d/ssh restart
  • Nun sollte der root-Login über ssh mit Schlüsseln anstatt mit einer Passwortabfrage ablaufen.
  • 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 -pPortnummer root@lincln02.foxtom.de

# ssh -pPortnummer  root@mx10.foxtom.de

# ssh -pPortnummer  root@mx20.foxtom.de

# ssh -pPortnummer  root@mx50.foxtom.de
  • Die Tests waren erfolgreich.

Verschlüsselung der duply-Archive einrichten

  • duply verwendet gpg (GNU privacy guard), um die Backup-Dateien zu verschlüsseln.

GPG Key erstellen

gpg --gen-key

oder 

gpg --full-generate-key

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]

duply konfigurieren

  • Einrichtung nach Push-Model
    • Daten sollen vom Backup-Server in den Backup-Space übermittelt werden.

Profil erstellen

duply <backupname> create

unter /root/.duply/backuptest/ werden die Dateien conf und exclude automatisch erstellt. 


Wichtig:
# 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 Verschlüsselung verwendet werden soll, indem die Key-ID und das dazugehörige Passwort eingetragen wurde.
GPG_KEY=' Key-ID des generierten Schlüsselsatzes'
GPG_PW='Festgelegtes Passwort des Schlüsselsatzes'
  • Kompression der duply-Archive:
    • Als Algorithmus zur Komprimierung wurde bzip2 festgelegt.
    • Da 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 Verschlüsselungsverfahren wurde AES256 (symmetrisch) festgelegt.
GPG_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= '/'
  • Umstellen von synchronem auf asynchrones Abarbeiten der Dateien, arbeitet Backupvorgang effizienter ab.
DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "
  • Eine Aufbewahrungszeit von zwei Jahren bis zum Überschreiben eines duply-Archives wurde festgelegt.
MAX_AGE=2Y
  • 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: Sicherer Zugriff vom Backup-Server mit duply auf den Backup-Space, um die zu sichernden Verzeichnisse und Dateien in den Backup-Space zu übertragen.

Neues SSH-Schlüsselpaar generieren

# 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]-----+
  • Wichtig: Damit das Einloggen später automatisch, d.h. hier ohne Passphrasenabfrage, funktioniert, einfach bei den Punkten
    • Enter passphrase (empty for no passphrase):
    • Enter same passphrase again:
  • nichts eingeben.
  • Das macht den Private-Key etwas unsicherer, ist aber in der Abwägung Praktikabilität zu Sicherheit zu verkraften.
  • Der erstellte Schlüsselsatz wird unter /root/.ssh/id_rsa abgelegt.

ssh-key in das PEM-Format umwandeln

duplicity benötigt den ssh-key im PEM-Format, wenn duplicity sich via ssh anmelden soll. 

# 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 crontab für rsnapshot und duply

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

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

# vi /etc/cron.d/backup
.---------------- 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


  • duply
#cat /etc/crontab >> /etc/cron.d/duply

0 0 2 */3 * root duply /root/.duply/duply_backup backup
0 0 * * 1 root duply /root/.duply/duply_backup backup
  • Option "backup":
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.

crontab im root-Account

# crontab -e

.---------------- 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
|  |  |  |  |
*  *  *  *  * command to be executed
  • 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

Datenflussdiagramm

Fazit

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

Quellen

Quellen allgemein zur Dokumentation

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