Backup/Server/Dokumentation: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Robertquies (Diskussion | Beiträge)
4.396 Bearbeitungen
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(859 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Projektplanung=
=Projektumfeld=
== Projektauftrag ==
Dirk Wagner Berlin ist ein Unternehmen, welches sich um Websites verschiedener Kunden kümmert, diese laufen auf mehreren angemieteten  virtualisierten Servern.
*Es sollte ein Backup-Server in einem LAN für Client-Backups  aufgebaut und eingerichtet werden und zusätzlich ein externer Backup-Space.
 
=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.


==SOLL-Zustand==
==Technische Anforderungen==
*Ein zweistufiges Backup-System sollte eingerichtet 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:
*Lokaler Backup-Server:
**Software-RAID
**Software-RAID
**Betriebssystem: Debian Linux 10
**Betriebssystem: Debian Linux 10
**4 TB Datenspeicher
**4 TB effektiver Datenspeicher
*Online-Backup-Space:
*Online-Backup-Space:
**2 TB Datenspeicher
**2 TB effektiver Datenspeicher
**Bevorzugter Standort für Server: Deutschland, EU-Ausland
**Die Backup-Dateien sollen verschlüsselt auf den externen Backup-Server übertragen werden.
**Bevorzugte Protokolle für die Dateiübertragung:  FTPS (TLS), SFTP (SSH), SCP (SSH)
*Es soll auf Kundenwunsch bei der Realisierung des Projekts auschließlich Open-Source-Software zum Einsatz kommen.
*Die Backup-Dateien sollten verschlüsselt auf den externen Backup-Server übertragen werden.
*Verwendung von Open-Source-Software.


=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.


=== Angebote ===
== IST-Analyse ==
# Backup-Space
*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.
# Hardware Consumer Tech
*Bisher war keine Infrastruktur für den Backup-Space vorhanden.
# Hardware Server Tech
*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'''
[[Datei:NetzwerkplanIst105.jpg|700px|thumb|center]]


==== Entscheidungsmatrix ====
===== Bewertungsskala=====
{| class="wikitable"
{| class="wikitable"
|+
|-
|-
! Zahl !! Note !! Beschreibung
! Backup-Clients !! Funktion !!Betriebssystem !! Ip-Adresse
|-
|- style="text-align:center"
| 1 || gut  || Wenn die Leistung den Kriterien voll entspricht.
| linncln01.localdomain || Workstation || Debian Testing || 192.168.1.100
|-
|- style="text-align:center"
| 2 || mittel || Wenn die Leistung im Allgemeinen den Kriterien entspricht.
| lincln02.localdomain || Workstation || Debian Stable || 192.168.1.200
|-
|- style="text-align:center"
| 3 || schlecht || Wenn die Leistung den Kriterien weniger entspricht.
| debian02.localdomain || Laptop || Debian Testing || 192.168.1.300
|- style="text-align:center"
| mx10.foxtom.de || Webserver || Debian Stable || 116.202.118.50
|- style="text-align:center"
| mx20.foxtom.de || Webserver || Debian Stable || 81.169.207.103
|- style="text-align:center"
| mx50.foxtom.de || Webserver || Debian Stable || 95.216.156.241
|}
|}


===== Kriterien =====
'''NEU: Einträge'''
*Preis pro TB:  
{| class="wikitable"
**Bezugsgrenze war der Bereich zwischen 2 und 4 TB an Datenspeicher.
|+
|- style="text-align:center"
! weitere Netzwerk/Hardwaren !! Funktion !!Betriebssystem !! Ip-Adresse
|- style="text-align:center"
|  opnsense.localdomain || Router, Firewall, DHCP, DNS || OPNsense || 192.168.1.1 / 91.66.18.81
|- style="text-align:center"
| TP-Link T2600G-18TS L2 managed || Switch ||  || 192.168.1.254
|- style="text-align:center"
| TP-Link EAP330 || WLAN-Access-Point ||  || 192.168.1.188
|}


*Standort(e):  
'''NEU: CAT 7 zu CAT 6'''
**Wo genau stehen die Server?
*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.
**Wenn Server in mehreren Ländern stehen, kann man den Standort selbst wählen?


*Erweiterbarkeit:
==SOLL-Konzept==
**Wie schnell kann der Datenspeicher nach oben (bzw. unten) skaliert werden?
[[Datei:NetzwerkplanSoll105.jpg|700px|thumb|center]]
**Was verändert sich an den Kosten?
*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.


*Vertragslaufzeit:
=Durchführung=
**Wie schnell und flexibel kann der Backspace an sich ändernde Anforderungen angepasst werden?
*Als erstes musste entschieden werden, welche Hardware verwendet werden sollte und welcher Backup-Space gemietet.


*Zugriffsprotokolle:
==Auswahl Hardware und Backup-Space==
**Anzahl und Art der verwendbaren Protkolle ausreichend?
'''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.


*Reputation:
===Gemeinsame Bewertungsskala===
**Nach Erfahrungswerten des Kunden/Online-Recherche
*Die Tabelle zeigt die erarbeitete Bewertungsskala.
{| class="wikitable"
|-
! Multiplikator !! Bewertung !! Beschreibung
|-
| 3 || gut  || Kriterium voll erfüllt
|-
| 2 || mittel ||  Kriterium teilweise erfüllt
|-
| 1 || schlecht ||  Kriterium nicht erfüllt
|}


===== Gewichtung =====
===Gemeinsame Gewichtungsskala===
===== Anbieter =====
*Diese Tabelle zeigt die erarbeitete Gewichtungsskala.
======  ======
{| class="wikitable"
*Link:
|-
**https:
! scope="row" text-align:center | Multiplikator !! Beschreibung
|- style="text-align:center"
| 100 || Ist für den Auftraggeber extrem wichtig.
|- style="text-align:center"
| 80 || Ist für den Auftraggeber sehr wichtig.
|- style="text-align:center"
| 60 || Ist für den Auftraggeber wichtig.
|- style="text-align:center"
| 40 || Ist für den Auftraggeber unwichtig.
|- style="text-align:center"
| 20 || Ist für den Auftraggeber sehr unwichtig.
|- style="text-align:center"
| 0 || Ist für den Auftraggeber völlig irrelevant.
|}


*Preis pro TB:  
===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'''
{| class="wikitable"
|+
|-
!  !! colspan="2" | neu !! colspan="2"| vorhanden
|-
| Prozessor || ! colspan="2"| AMD Ryzen 5 3400G ||  ! colspan="2"|AMD Phenom(tm) II X4 925 2,80GHz
|-
| || Leistung || '''3,70GHz''' || Leistung || '''2,80GHz'''
|-
| || Kerne || '''8''' || Kerne ||'''4'''
|-
| Mainboard || ! colspan="2" |ASUS PRIME X570-PRO || ! colspan="2" |ASUStek M4A87TD/USB3
|-
| || Formfaktor || '''ATX'''|| Formfaktor || '''ATX'''
|-
| Arbeitsspeicher || ! colspan="2"|2x Crucial CT2K16G4DFD8266 Kit || ! colspan="2"| 4x Kingston ValueRAM DIMM
|-
| || Geschwindigkeit || '''DDR4 2666MHz''' || Geschwindigkeit || '''DDR3 1333MHz'''
|-
| || Kapazität || 2x16GB || Kapazität || 4x4GB
|-
|  ||Gesamt || '''32GB'''  || Gesamt|| '''16GB'''
|-
| Netzteil || ! colspan="2"|be quiet! STRAIGHT POWER 11 Platinum || ! colspan="2"|Inter-Tech Combat Power plus Non-Modular
|-
| || Leistung || '''750W''' || Leisung || '''750W'''
|-
| || Formfaktor || '''ATX''' || Formfaktor || '''ATX'''
|-
| Gehäuse || ! colspan="2" |be quiet! DARK BASE 900 || ! colspan="2" | 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 ||  colspan="2"| Samsung 860 EVO ||  colspan="2"|Western Digital WD10EARS Caviar Green
|-
| || Kapazität || 2x250GB || Kapazität || 1TB
|-
| || Speichertechnik || SSD || Speichertechnik || HDD
|-
|  ||  colspan="2"| ||  colspan="2"|Samsung Spinpoint F3 HD103SJ
|-
| ||  colspan="2"|  || Kapazität || 1TB
|-
| || colspan="2"|    || Speichertechnik || HDD
|-
|  ||Gesamt || '''0,50TB'''  || Gesamt|| '''2TB'''
|-
| Datenträger Datenspeicher ||  colspan="2"| 4x Western Digital WD40EZRX Caviar Green ||  colspan="2"|Western Digital WD20EZRX
|-
| || Kapazität || 4x4TB || Kapazität || 2TB
|-
| || Speichertechnik || HDD || Speichertechnik || HDD
|-
|  ||  colspan="2"| ||  colspan="2"|Samsung Spinpoint F3 HD103SJ
|-
| ||  colspan="2"|  || Kapazität || 2TB
|-
| || colspan="2"|    || Speichertechnik || HDD
|-
|  ||  colspan="2"| ||  colspan="2"|HITACHI Deskstar
|-
| ||  colspan="2"|  || Kapazität || 2TB
|-
| || colspan="2"|    || Speichertechnik || HDD
|-
|  ||  colspan="2"| ||  colspan="2"|TOSHIBA P300
|-
| ||  colspan="2"|  || Kapazität || 2TB
|-
| || colspan="2"|    || 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.


*Standort(e):
=====Auswertung=====


*Erweiterbarkeit:  
{|class="wikitable"
! scope="row" rowspan="3" text-align:center|Kriterien !! rowspan="3"|Gewichtung !! colspan="4"|Hardware
|-
! scope="row" colspan="2" |  neu||! scope="row" colspan="2"|vorhanden
|-
!! | Bewertung || Wert !! | Bewertung || Wert
|- style="text-align:center"
| Geschindigkeit CPU || 20 ||3||60 || 2 ||40
|- style="text-align:center"
| Kapazität Arbeitsspeicher || 40 || 3 ||120 || 2 || 80
|- style="text-align:center"
| Geschwindigkeit Arbeitsspeicher || 20 ||3 ||60 || 2||40
|- style="text-align:center"
| Zukunftssicherheit || 20 || 3 || 60|| 1||20
|- style="text-align:center"
| Kapazität Datenspeicher || 80 || 3|| 240 || 2||16
|- style="text-align:center"
| Kosten || 100 ||1 ||100 || 3|| 300
|- style="text-align:center"
! scope="row" colspan="2"| Gesamtergebnis  || !|16 || !| 640||!|11 || !|640
|}


*Vertragslaufzeit:
*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.


*Zugriffsprotokolle:
===Backup-Space===


======Hetzner======
====Vergleich Backup-Space====
*Link:
*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.
**https://www.hetzner.com/de/storage/storage-box
{| class="wikitable"
**https://www.hetzner.com/de/storage/storage-box/bx40
|+
 
|- style="text-align:center"
*Preis pro TB: 5,74€/Mon. (2TB) - keine Einrichtungsgebühr
! Leistungsmerkmale !!  Strato HiDrive Business Basic S3 !! Hetzner BX40
 
|- style="text-align:center"
*Standort(e): D, FIN
| Preis pro TB || 13,33€ || 5,74€
 
|- style="text-align:center"
*Erweiterbarkeit: Up- oder Downgrade jeder Zeit möglich
| Mindestkapazität|| 3TB ||  2TB
 
|- style="text-align:center"
*Vertragslaufzeit: keine
| Tarffic-Begrenzung Outbound/Monat || 0,05 € pro GB/mtl. || 10TB
 
|- style="text-align:center"
*Zugriffsprotokolle: FTP, FTPS, SFTP, SCP, HTTPS, WebDAV
| Standort(e) || Deutschland|| Deutschland, Finnland
|- style="text-align:center"
| Erweiterbarkeit ||  jeder Zeit || jeder Zeit
|- style="text-align:center"
| Mindestvertragslaufzeit || 1 Monat || keine
|- style="text-align:center"
| Kündigungsfrist || 30 Tage zum Laufzeitende ||30 Tage zum Monatsende
|- style="text-align:center"
| Zugriffsprotokolle || SFTP, SCP, WebDAV, rsync via SSH, SMB/CIFS ||FTP, FTPS, SFTP, SCP, SMB/CIFS, BorgBackup, rsync via SSH, HTTPS, WebDAV  
|}


======Online-backup-storage======
====Entscheidungsmatrix====
*Link:
'''TODO: aus Kriterien Tabelle machen'''
**http://www.online-backup-storage.de/
=====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.


*Preis pro TB: 35,70€ plus Einrichtungsgebühr
=====Auswertung=====


*Standort(e): D (Stuttgart)
*Erweiterbarkeit: bis 8 TB
*Vertragslaufzeit: keine Angabe
*Zugriffsprotokolle: SMB Encryption
======Ionos 1======
*Link:
**https://www.ionos.de/office-loesungen/hidrive-cloud-speicher
*Preis pro TB: 5,00€ (erste 12 Monate), danach 10,00€
*Standort(e): D
*Erweiterbarkeit: max 2 TB
*Vertragslaufzeit: 1 Monat
*Zugriffsprotokolle: Smartphone App, WebDAV, SMB, Git
======IONOS Cloud Backup Flex======
*Link:
**https://www.ionos.de/cloud/cloud-backup
*Preis pro TB: 120,00€ (Startguthaben 325,00€, Abrechnung monatlich 0,12Cent/GB, Zahlen nach Verbrauch)
*Standort(e): keine Angabe
*Erweiterbarkeit: keine Angabe
*Vertragslaufzeit: 1 Monat
*Zugriffsprotokolle: keine Angabe - Verschlüsselung SSL, AES-256
======Strato HiDrive======
*Link:
**https://www.strato.de/cloud-speicher/
*Preis pro TB: 6,00€, keine Einrichtungsgebühr
*Standort(e): D
*Erweiterbarkeit: direkt 3 TB
*Vertragslaufzeit: 12 Monate
*Zugriffsprotokolle: SFTP, FTPS, WebDAV, SMB/CIFS, rsynch, SCP, Git
======LeitzCloud======
*Link:
**https://leitz-cloud.com/
*Preis pro TB: 16,00€
*Standort(e): D
*Erweiterbarkeit: 12,5 TB
*Vertragslaufzeit: keine Angaben
*Zugriffsprotokolle: keien Angaben
===== Auswertung =====
{|class="wikitable"
{|class="wikitable"
! rowspan="2" text-align:center|Kriterien !! rowspan="2"|Gewichtung !! colspan="6"|Anbieter  
! scope="row" rowspan="3" text-align:center|Kriterien !! rowspan="3"|Gewichtung !! colspan="4"|Anbieter
|-
|-
| Hetzner || Online-Backup-Storage || IONOS Hidrive || IONOS Cloud-Backup || Strato || Leitz
! scope="row" colspan="2"|Strato HiDrive Business Basic S3 || ! scope="row" colspan="2"|Hetzner BX40
|-
!! | Bewertung || Wert !! | Bewertung || Wert
|- style="text-align:center"
|- style="text-align:center"
| Preis pro TB || 2 || || || || || ||  
| Preis pro TB || 80 ||2||160 || 3 ||240
|- style="text-align:center"
|- style="text-align:center"
| Reputation || 3 || || || || || ||
| Traffic-Begrenzung Outbound|| 60 || 1 ||60 || 2 || 120
|- style="text-align:center"
|- style="text-align:center"
| Standort(e) || 3 || || || || || ||
| Standort(e) D und/oder EU || 100 ||2 ||200 || 3||300
|- style="text-align:center"
|- style="text-align:center"
| Erweiterbarkeit || 2 || || || || || ||
| Erweiterbarkeit || 60 || 2 || 120|| 2||120
|- style="text-align:center"
|- style="text-align:center"
| Vertragslaufzeit || 2 || || || || || ||
| Mindestvertragslaufzeit || 80 || 3|| 240 || 3||240
|- style="text-align:center"
|- style="text-align:center"
| Zugriffsprotokolle || 3 || || || || || ||
| Zugriffsprotokolle || 100 ||3 ||300 || 3|| 300
|- style="text-align:center"
|- style="text-align:center"
| Ergebnis ohne
| Reputation|| 100 ||1 ||100 || 3|| 300
|- style="text-align:center"
|- style="text-align:center"
| Ergebnis gewichtet
! scope="row" colspan="2"| Gesamtergebnis  || !|14 || !| 1180|| !|19 || !| 1620
|}
|}


== IST-Zustand ==
*Aufgrund der Auswertung der Entscheidungsmatrix entschied sich der Auftraggeber für das Angebot von Hetzner.
*Es war keine Infrastruktur für den Backup-Space vorhanden.
*Das Backup wurde bisher unregelmäßig direkt vom Client durchgeführt.
*Kein Backup-Server war im LAN vorhanden.
*Das Datenvolumen der zu sichernden Daten betrug bisher ca. 1 TB, wird aber sukzessive wachsen.


===vorhandene Infrastruktur===
==Vorbereitung der Realsierung der Ausfallsicherheit==
*Internet-Zugang mit 1 Gbit/s
*Die Ausfallsicherheit des Backup-Servers sollte durch das Einrichten von RAID-Verbünden für den Systemspeicher und den Datenspeicher realisiert werden.
*Router: Betriebssystem: OPNsense
*Drei Clients: Betriebssystem: Debian GNU/Linux


=Durchführung=
'''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 ('''d'''isk '''d'''ump)====
*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'''
[[Datei:PlattenBeschriftet C2scharf.jpg|500px|beschriftete Datenträger]]


=== Hardware ===
'''TODO: Angabe mit Bezeichnung der Teile'''
====Backup-Server====
*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.
#Installationshandbuch zu Mainboard konsultiert (Pinbelegung).
#Installationshandbuch zu Mainboard konsultiert (Pinbelegung).
#Vor der Montage: Erdung, um die statische Aufladung abzuleiten, die ansonsten die sensiblen elektronischen Bauteile beschädigen könnte.
#Vor der Montage: Erdung, um die statische Aufladung abzuleiten, die ansonsten die sensiblen elektronischen Bauteile beschädigen könnte.
Zeile 215: Zeile 397:
###Die Schrauben wurde nicht zu fest angezogen, um Beschädigungen an der Platine zu vermeiden.
###Die Schrauben wurde nicht zu fest angezogen, um Beschädigungen an der Platine zu vermeiden.
#Einbau der Datenträger.
#Einbau der Datenträger.
##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.
#Anschluss aller Stromkabel.
#Anschluss aller Datenkabel.
#Anschluss aller Datenkabel.
#Anschluss aller Stromkabel.
#Anschluss der Netzwerkkabel (CAT 7).
#Server testweise anschaltet.
#Server testweise anschaltet.


*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.


=====Einbindung in das Netzwerk=====
====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 ===
=== Betriebssystem ===
*Download der debian-10.6.0-amd64-netinst (ISO-Datei)
====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.
*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, 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.
debian-10.6.0-amd64-netinst
 
=== Software-RAID ===
*Einrichtung des Software-RAIDs('''R'''edundant '''A'''rray of '''I'''ndependent '''D'''isks).
*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


*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.


{|class="wikitable"
=== Einrichtung Ausfallsicherheit - Software-RAID ===
! rowspan="2" text-align:center|Kriterien !! rowspan="2"|Gewichtung !! colspan="6"|RAID-Level
|-
| RAID 01 || RAID 10 || RAID 5 || RAID 6 
|- style="text-align:center"
| Speicherkapazität ||  || 2 || 2||1 ||2
|- style="text-align:center"
| Ausfallsicherheit ||  || 1 || 1|| 3 || 2
|- style="text-align:center"
| Kosten für n Platten || || 2*n || 2*n || n+1 || n+2
|- style="text-align:center"
| Schreib-Performance ||  || 1 || 1|| 2 ||3
|- style="text-align:center"
| Lese-Performance ||  || 1 ||1 || 3 ||3
|- style="text-align:center"
|  ||  || || || ||
|}


====Vorbereitung====
====Vorbereitung====
=====Beschriftung=====
*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 ('''d'''isk '''d'''ump)=====
*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 ('''f'''ixed '''disk''')=====
=====Partitionierung - fdisk ('''f'''ixed '''disk''')=====
*Zuerst wurden die Bezeichnungen der Datenträger ausgelesen.
*Zuerst wurden die Bezeichnungen der Datenträger ausgelesen, /sda, sdb usw..
*Danach konnte mit der Partitionierung begonnen werden.
*Danach konnte mit der Partitionierung begonnen werden.
*Als erstes wurde GPT (GUID Partition Table) als das Disklabel der Partionstabelle angelegt.
*Als erstes wurde GPT (GUID Partition Table) als das Disklabel der Partionstabelle angelegt.
*Anschließend wurde die Partitionstabelle anlegt.
*Anschließend wurde die Partitionstabelle anlegt.
*Am Anfang des Laufwerks wurden 2048 Sektoren bewußt ungenutzt gelassen, um ein optimales Alignment zu ermöglichen.
*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 fiehl ungenutzt gelassen, falls nach Jahren keine baugleiche Festplatte mehr beschafft werden kann, ermöglicht es der frei gelassene Platz auch Laufwerke als Ersatz zu nehmen, die einige Sektoren weniger haben.
*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.
*Zum Schluss wurde die Partition als Linux-RAID-Partion markiert.
*Dieser Vorgang wurde für alle Datenträger durchgeführt.
*Dieser Vorgang wurde für alle Datenträger durchgeführt.


TODO: herausfinden, warum der Link nicht funktioniert.
====RAID-Verbund erstellen====
*siehe [[Projekt:Backup-Server:Dokumentation#Anhang#Anhang 11 - Partitionierung - fdisk | Anhang 11]]
 
====RAID einrichten====
*Ein RAID 6 aus vier Datenträgern über die vier Partitionen sda1, sdb1, sdc1 und sdd1 wurde mit dem Programm mdadm ('''m'''ultiple '''d'''isk '''adm'''inistration) erstellt.
*Ein RAID 6 aus vier Datenträgern über die vier Partitionen sda1, sdb1, sdc1 und sdd1 wurde mit dem Programm mdadm ('''m'''ultiple '''d'''isk '''adm'''inistration) erstellt.
*mdadm bildet die Schnittstelle zu den RAID-Funktionen des Kernels.
*mdadm bildet die Schnittstelle zu den RAID-Funktionen des Kernels.
Zeile 306: Zeile 440:
  # mdadm --create /dev/md1 --auto md --level=6 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
  # mdadm --create /dev/md1 --auto md --level=6 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1


=====Alignment=====
=====Dateisystem und Alignment=====
*Um eine optimale Leistung zu ermöglichen, wurde auf das das optimale Alignment geachtet.
*Um eine bestmögliche Performance des RAID-Verbunds zu ermöglichen, wurde auf das optimale Alignment geachtet.
*Die Chunk-Size wurde ermittelt.
*Als erstes wurde die Chunk-Size ermittelt, also die Größe eines RAID-Blocks.


  # mdadm -D /dev/md0 | grep "Chunk Size"  
  # mdadm -D /dev/md1 | grep "Chunk Size"  
  Chunk Size : '''512K'''
  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.
*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 5 über 4 Partitionen ergab sich hier 128 * 3 = 384.




  # mkfs.ext4 -b '''4096''' -E stride='''128''',stripe-width='''384''' /dev/md1
  # mkfs.'''ext4''' -b '''4096''' -E stride='''128''',stripe-width='''256''' /dev/md1


===rsnapshot===
=====RAID-Verbund mounten=====
*Einrichtung Pull-Verfahren
 
**Daten sollten automatisch abgeholt werden.
*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.


*Die Angabe der config_version musste auskommentiert sein. Standard ist 1.2
'''NEU:Text streichen von...'''
'''config_version  1.2'''
*Die Angabe der config_version musste auskommentiert bleiben, denn eine Version muss definiert sein, da rsnapshot sonst nicht funktioniert.
 
'''NEU:Text streichen bis hier.'''  
# ROOT DIRECTORY - Ziel für die Backup-Dateien wurde festgelegt.
*Das Ziel für die Backup-Dateien wurde festgelegt.
  '''snapshot_root  /media/daten/rsnapshot/'''
  '''snapshot_root  /media/daten/rsnapshot/'''
*Die Verwendung von rsynch musste zwingend erlaubt sein. Da rsnapshot auf rsynch basiert.
# 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'''
  '''cmd_rsync      /usr/bin/rsync'''
*Die Anmeldung sollte per ssh erfolgen.  
# Anmeldung sollte per ssh erfolgen.  
  '''cmd_ssh /usr/bin/ssh'''
  '''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.
# Angabe über welchen Port die ssh-Verbindung aufgebaut werden sollte.
  '''ssh_args        -p2227'''  
  '''ssh_args        -p2227'''
*Weiter wurde festgelegt, wie viele Snapshots aufbewahrt werden sollen.
# syslog support
'''cmd_logger      /usr/bin/logger'''
# Festlegung wie viele Snapshots aufbewahrt werden sollten.
  '''retain  daily      7'''
  '''retain  daily      7'''
  '''retain  weekly    4'''
  '''retain  weekly    4'''
Zeile 361: Zeile 512:
  '''retain  quartarly  4'''
  '''retain  quartarly  4'''
  '''retain  annual    2'''
  '''retain  annual    2'''
*Der Speicherort der Log-Datei von rsnapshot wurde festgelegt.
#GLOBALE OPTIONEN#
# Verbose-Level
'''verbose        5'''
# Log-Level
'''loglevel        4'''
# Speicherort der Log-Datei
  '''logfile /var/log/rsnapshot.log'''
  '''logfile /var/log/rsnapshot.log'''
# Lockfile, sollte verhindern, dass zwei Instanzen gleichzeitig ein Backup durchführen können.
*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'''
  '''lockfile        /var/run/rsnapshot.pid'''
   
   
# Backup-Punkte wurden festgelegt (Quelle Ziel)
*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@lincln02:/etc/            lincln02/'''
'''backup  root@debian02:/etc/            debian02/'''
  '''backup  root@mx10.foxtom.de:/etc/      mx10/'''
  '''backup  root@mx10.foxtom.de:/etc/      mx10/'''
  '''backup  root@mx20.foxtom.de:/etc/      mx20/'''
  '''backup  root@mx20.foxtom.de:/etc/      mx20/'''
  '''backup  root@mx50.foxtom.de:/etc/      mx50/'''
  '''backup  root@mx50.foxtom.de:/etc/      mx50/'''


===Verbindung per ssh: rsnapshot zu Servern und Client===
===Verbindung per ssh: rsnapshot zu Servern und Clients===
*Ziel: Sicherer Zugriff vom Backup-Server mit rsnapshot auf Server und Clients sollte möglich sein, um die zu sichernden Verzeichnisse und Dateien in das rsnapshot-Backup zu übertragen.
*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.
*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====
====Schlüssel sicher übertragen====
*Auf den Client lincln02.
*Auf die Clients lincln01, lincln02 und debian02.
*Auf die Server mx10, mx20 und mx50.
*Auf die Server mx10, mx20 und mx50.


=====root-Login per ssh zeitweise auf den Clients erlauben=====
=====root-Login per ssh zeitweise auf den Clients erlauben=====
*Gefahr einer Brute-Force-Attacke, wenn der root-Login erlaubt bleibt.
*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.
*Als erstes wurde eine ssh-Verbindung als user über die Eingabe des user-Passworts aufgebaut.


  $ ssh user@lincln02.localdomain
  $ ssh '''user'''@lincln02.localdomain
  user@lincln02.localdomain's password:
  user@lincln02.localdomain's password:


Zeile 407: Zeile 555:


=====ssh-Schlüssel per root-Login mit Passwort übertragen=====
=====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.
*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
  # ssh-copy-id -p Portnummer root@domain
Zeile 413: Zeile 561:


=====root-Login per ssh auf den Clients wieder verbieten=====
=====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.
*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
  # vi /etc/ssh/sshd_config


*Änderung von yes auf '''prohibit-password'''
*Indem der root-Login über die Passworteingabe mit der Option '''prohibit-password''' untersagt wurde.
  PermitRootLogin '''prohibit-password'''
  PermitRootLogin '''prohibit-password'''
*Änderung wurde gespeichert und der Dienst neu starten.
*Die Änderung wurde gespeichert und der Dienst neu gestartet.
  # /etc/init.d/ssh restart
  # /etc/init.d/ssh restart


*Nun sollte der root-Login über ssh mit Schlüsseln anstatt mit einer Passwortabfrage ablaufen.
*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.
*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=====
=====Manuelles Testen der Verbindungen=====
*Um sicher zugehen, dass das Login über ssh automatisiert funktioniert, wurden die Verbindungen manuell getestet.
*Um sicher zugehen, dass das Login über ssh automatisiert funktioniert, wurden die Verbindungen manuell getestet.
  # ssh -pPortnummer root@lincln02.foxtom.de
  # ssh -p2227 root@lincln01.localdomain


  # ssh -pPortnummer  root@mx10.foxtom.de
'''NEU:Text streichen von...'''
  # ssh -p2227 root@lincln02.localdomain


  # ssh -pPortnummer  root@mx20.foxtom.de
  # ssh -p2227 root@debian02.localdomain


  # ssh -pPortnummer root@mx50.foxtom.de
  # ssh -p2227 root@mx10.foxtom.de


*Die Tests waren erfolgreich.
# ssh -p2227 root@mx20.foxtom.de


===Verschlüsselung der duply-Archive einrichten===
# ssh -p2227  root@mx50.foxtom.de
*duply verwendet gpg ('''G'''NU '''p'''rivacy '''g'''uard), um die Backup-Dateien zu verschlüsseln.
'''NEU:Text streichen bis hier.'''


====GPG Key erstellen====
*Die Tests verliefen erfolgreich.
 
===Kryptografie der duply-Archive einrichten===
*Das Backup-Programm duply verwendet gpg ('''G'''NU '''p'''rivacy '''g'''uard), 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
  gpg --gen-key


oder
und


  gpg --full-generate-key
  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====
====Key-ID anzeigen lassen====


Zeile 477: Zeile 638:
  uid              [ ultimativ ] Robert Quies (Es grünt so grün, wenn Spaniens Blüten blühn.) <raqju@web.de>
  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]
  sub  rsa4096/B2E20485FF7FC772 2020-11-04 [E] [verfällt: 2021-11-04]
'''NEU:In den Anhang bis hier'''


===duply===
===Duply konfigurieren===
*Einrichtung Push-Verfahren
*duply arbeitet nach dem Push-Model
**Daten sollen vom Backup-Server übermittelt werden.
**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====
====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 <backupname> create
  duply duply_backup create
 
unter /root/.duply/backuptest/ werden die Dateien conf und exclude automatisch erstellt.


*Dadurch wurde unter /root/.duply/backuptest/ die Dateien conf und exclude automatisch erstellt.


Wichtig:
  # duply ersatzBU create
  # duply ersatzBU create


Zeile 509: Zeile 672:
  vi /root/.duply/backuptest/conf
  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.
*Es wurde festgelegt, welcher Schlüsselsatz zur Kryptografie verwendet werden soll, indem die  '''Key-ID''' und das dazugehörige '''Passwort''' eingetragen wurde.
  GPG_KEY='Key-ID des generierten Schlüsselsatzes'
  GnuPG_KEY=' '''Key-ID''' des generierten Schlüsselsatzes'
  GPG_PW='Festgelegtes Passwort des Schlüsselsatzes'
  GnuPG_PW='Festgelegtes '''Passwort''' des Schlüsselsatzes'
*Kompression der duply-Archive:  
*Kompression der duply-Archive:  
**Als Algorithmus zur Komprimierung wurde bzip2 festgelegt.
**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.
**Da dem Auftraggeber Speicherkapazität vor Geschwindigkeit geht, wurde das höchste Kompressionslevel '''9''' gewählt.  
** Angabe des bevorzugten Verschlüsselungsverfahren - AES256 (symmetrisch)
**Das spart Speicherkapazität, erhöht aber die Recovery Time.
  GPG_OPTS='--compress-algo=bzip2 --bzip2-compress-level=9 --personal-cipher-preferences AES256''
**Als bevorzugtes Kryptografieverfahren wurde '''AES256''' (symmetrisch) festgelegt.
*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.
  GnuPG_OPTS='--compress-algo='''bzip2''' --bzip2-compress-level='''9''' --personal-cipher-preferences '''AES256''' '
  TARGET='sftp://user@domain:23/Pfad_zum_Ordner'
*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.
*Quelle der zu sichernden duply-Archive festlegen. Hier alles unter root-Wurzelverzeichnis. Genaueres wurde in der exclude-Datei festgelegt.
  TARGET=' '''sftp'''://user@domain:'''23'''/Pfad_zum_Ordner' '''
  SOURCE='/'
*Die Quelle der zu sichernden duply-Archive wurde festgelegt. Alles unter dem '''root-Wurzelverzeichnis'''. Genaueres wurde in der exclude-Datei festgelegt.
*Aufbewahrungszeit bis zum Überschreiben eines duply-Archives festlegen
  SOURCE=''' '/' '''
  MAX_AGE=1M
*duply wurde vom synchronen auf asynchrones Abarbeiten der Dateien umgestellt, da dadurch Backup-Dateien effizienter abgearbeitet werden.
*Anzahl an aufbewahrten Full-Backups festlegen.
*duply kann dadurch bereits verschlüsselte Backup-Dateien hochladen, während gleichzeitig andere Backup-Dateien gerade verschlüsselt werden.
  MAX_FULL_BACKUPS=1
*Im synchronen Modus dagegen würde jede Backup-Datei nacheinander erst verschlüsselt und dann hochgeladen werden.
*Erzwingt eine vollständige Sicherung, wenn die letzte vollständige Sicherung ein bestimmtes Alter erreicht. Hier drei Monate.
DUPL_PARAMS="$DUPL_PARAMS '''--asynchronous-upload''' "
  MAX_FULLBKP_AGE=3M
*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 "  
  DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "  
*Paketgröße der übertragenen Pakete festlegen.
*Paketgröße der übertragenen Pakete wurde auf '''100 kb''' festgelegt.
  VOLSIZE=100
  VOLSIZE='''100'''
  DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
  DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
*Ausführlichkeit der log-Einträge festelegen.
*Ausführlichkeit der log-Einträge wurde festgelegt.
  VERBOSITY=8
  VERBOSITY='''8'''


====Festlegen der zu sicherden Verzeichnisse - exclude====
====Festlegen der zu sicherden Verzeichnisse - exclude====
Zeile 540: Zeile 708:


===Verbindung per ssh: lokaler Backup-Server zu Online-Backup-Space===
===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====
====Neues SSH-Schlüsselpaar generieren====
*Als erstes wurde ein neues Schlüsselpaar generiert.


  # ssh-keygen
  # ssh-keygen
Zeile 565: Zeile 735:
  +----[SHA256]-----+
  +----[SHA256]-----+


Wichtig: Damit das Einloggen später automatisch, d.h. hier ohne Passphrasenabfrage, funktioniert, einfach bei den Punkten
*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.


-Enter passphrase (empty for no passphrase):
*Das macht den Private-Key zwar etwas unsicherer, aber da rsn in der Abwägung Praktikabilität zu Sicherheit zu verkraften.


-Enter same passphrase again:
*Der erstellte Schlüsselsatz wurde unter '''/root/.ssh/id_rsa''' abgelegt.


nichts eingeben.
====ssh-key in das PEM-Format umwandeln====


Das macht den Private-Key etwas unsicherer, ist aber in der Abwägung Praktikabilität zu Sicherheit zu verkraften.
*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====
====authorized_keys-Datei erstellen====
Zeile 603: Zeile 779:
===Automatisierung Backup: cronjob einrichten===
===Automatisierung Backup: cronjob einrichten===


====Systemweite crontab für rsnapshot und duply====
====Systemweite cron-Tabelle für rsnapshot und duply====


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


*rsnapshot
*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.
#cat /etc/crontab >> /etc/cron.d/rsnapshot
*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.
 


  # vi /etc/cron.d/backup
=====rsnapshot=====
# '''cat /etc/crontab >> /etc/cron.d/rsnapshot'''
 
  # vi /etc/cron.d/rsnapshot
  .---------------- minute (0 - 59)
  .---------------- minute (0 - 59)
  |  .------------- hour (0 - 23)
  |  .------------- hour (0 - 23)
Zeile 624: Zeile 807:
  59 23 1 1 * root rsnapshot annual
  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
=====duply=====


  #cat /etc/crontab >> /etc/cron.d/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
  0 0 2 */3 * root duply /root/.duply/duply_backup backup
0 0 * * 1 root duply /root/.duply/duply_backup backup


*Option "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).
  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.  
  '''Vollständig''', wenn full_if_older übereinstimmt oder keine frühere Sicherung gefunden wird.  
  '''Inkrementell''', in allen anderen Fällen.
  '''Inkrementell''', in allen anderen Fällen.


TODO: Klärung, ob daraus folgt, dass alles in der conf festgelegt wird.
'''TODO: Klärung, ob daraus folgt, dass alles in der conf festgelegt wird.'''
 
====crontab im root-Account====
 
# crontab -e


.---------------- minute (0 - 59)
==== Rsnapshot====
|  .------------- 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 16 * * * rsnapshot daily
  0 18 * * 1 rsnapshot weekly
  0 18 * * 1 rsnapshot weekly
Zeile 657: Zeile 837:
  0 22 1 */3 * rsnapshot quartarly
  0 22 1 */3 * rsnapshot quartarly
  59 23 1 1 * rsnapshot annual
  59 23 1 1 * rsnapshot annual
*duply
==== duply ====
  0 0 2 */3 * duply /root/.duply/Name_des_Profils backup
  0 0 2 */3 * duply /root/.duply/Name_des_Profils backup
  0 0 * * 1 duply /root/.duply/Name_des_Profils backup
  0 0 * * 1 duply /root/.duply/Name_des_Profils backup


==Fazit==
==Restore==
*Reflexion
**Abweichungen SOLL-Zustand zu IST-Zustand
**Verbesserungpotential aufzeigen
**Ergebnisse darstellen


==Quellen==
===rsnapshot===
*[https://wiki.ubuntuusers.de/rsnapshot/ https://wiki.ubuntuusers.de/rsnapshot/]
*Nach der ersten manuellen Backup-Erstellung wurden mit rsync testweise einige Dateien und Verzeichnisse wiederherhestellt.  
*[https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_duply https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_duply]
*allgemein:
*[https://wiki.ubuntuusers.de/GnuPG/ https://wiki.ubuntuusers.de/GnuPG/]
# rsync -avr Quelle_rsnapshot-Archivs Zielordner_für_Dateien


=Anhang=
*Beispiel
#Angebot interner Backup-Server
# rsync -avr /media/daten/rsnapshot/daily.0/lincln02/media/daten/ebooks /home/user/Dokumente
#Angebot externer Backup-Server
#Kundenauftrag
#Raumplan
#Netzwerkplan
#Skizzen
#Schaltplan?
#Config-Datei rsnapshot
#Config-Datei duply
#Ablauf GPG: Schlüsselerstellung
#Fotos
#Messprotokolle


==Anhang 01 - rsnapshot.conf komplett==
*Der Test verlief erfolgreich.


#################################################
===duply===
# rsnapshot.conf - rsnapshot configuration file #
#################################################
#                                              #
# PLEASE BE AWARE OF THE FOLLOWING RULE:        #
#                                              #
# This file requires tabs between elements      #
#                                              #
#################################################
#######################
# CONFIG FILE VERSION #
#######################
'''config_version  1.2'''
###########################
# SNAPSHOT ROOT DIRECTORY #
###########################
# All snapshots will be stored under this root directory.
#
'''snapshot_root  /media/daten/rsnapshot/'''
# If no_create_root is enabled, rsnapshot will not automatically create the
# snapshot_root directory. This is particularly useful if you are backing
# up to removable media, such as a FireWire or USB drive.
#
#no_create_root 1
#################################
# EXTERNAL PROGRAM DEPENDENCIES #
#################################
# LINUX USERS:  Be sure to uncomment "cmd_cp". This gives you extra features.
# EVERYONE ELSE: Leave "cmd_cp" commented out for compatibility.
#
# See the README file or the man page for more details.
#
'''cmd_cp          /bin/cp '''
# uncomment this to use the rm program instead of the built-in perl routine.
#
'''cmd_rm          /bin/rm'''
# rsync must be enabled for anything to work. This is the only command that
# must be enabled.
#
'''cmd_rsync      /usr/bin/rsync'''
'''cmd_ssh /usr/bin/ssh'''
'''ssh_args        -p2227'''
 
# Uncomment this to enable remote ssh backups over rsync.
#
#cmd_ssh        /usr/bin/ssh
# Comment this out to disable syslog support.
#
'''cmd_logger      /usr/bin/logger'''
# Uncomment this to specify the path to "du" for disk usage checks.
# If you have an older version of "du", you may also want to check the
# "du_args" parameter below.
#
#cmd_du        /usr/bin/du
# Uncomment this to specify the path to rsnapshot-diff.
#
#cmd_rsnapshot_diff    /usr/bin/rsnapshot-diff
# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
#cmd_preexec    /path/to/preexec/script
# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
#cmd_postexec  /path/to/postexec/script
# Paths to lvcreate, lvremove, mount and umount commands, for use with
# Linux LVMs.
#
#linux_lvm_cmd_lvcreate /sbin/lvcreate
#linux_lvm_cmd_lvremove /sbin/lvremove
#linux_lvm_cmd_mount    /bin/mount
#linux_lvm_cmd_umount  /bin/umount
#########################################
#    BACKUP LEVELS / INTERVALS        #
# Must be unique and in ascending order #
# e.g. alpha, beta, gamma, etc.        #
#########################################
'''retain  daily  7'''
'''retain  weekly  4'''
'''retain  monthly 3'''
'''retain  quartarly      4'''
'''retain  annual  2'''
############################################
#              GLOBAL OPTIONS              #
# All are optional, with sensible defaults #
############################################
# Verbose level, 1 through 5.
# 1    Quiet          Print fatal errors only
# 2    Default        Print errors and warnings only
# 3    Verbose        Show equivalent shell commands being executed
# 4    Extra Verbose  Show extra verbose information
# 5    Debug mode      Everything
#
'''verbose        5'''
# Same as "verbose" above, but controls the amount of data sent to the
# logfile, if one is being used. The default is 3.
# If you want the rsync output, you have to set it to 4
#
'''loglevel        4'''
# If you enable this, data will be written to the file you specify. The
# amount of data written is controlled by the "loglevel" parameter.
#
'''logfile /var/log/rsnapshot.log'''
# If enabled, rsnapshot will write a lockfile to prevent two instances
# from running simultaneously (and messing up the snapshot_root).
# If you enable this, make sure the lockfile directory is not world
# writable. Otherwise anyone can prevent the program from running.
#
'''lockfile        /var/run/rsnapshot.pid'''
# By default, rsnapshot check lockfile, check if PID is running
# and if not, consider lockfile as stale, then start
# Enabling this stop rsnapshot if PID in lockfile is not running
#
#stop_on_stale_lockfile        0
# Default rsync args. All rsync commands have at least these options set.
#
#rsync_short_args      -a
#rsync_long_args        --delete --numeric-ids --relative --delete- excluded
# ssh has no args passed by default, but you can specify some here.
#
#ssh_args      -p 22
# Default arguments for the "du" program (for disk space reporting).
# The GNU version of "du" is preferred. See the man page for more details.
# If your version of "du" doesn't support the -h flag, try -k flag instead.
#
#du_args        -csh
# If this is enabled, rsync won't span filesystem partitions within a
# backup point. This essentially passes the -x option to rsync.
# The default is 0 (off).
#
#one_fs        0
# The include and exclude parameters, if enabled, simply get passed directly
# to rsync. If you have multiple include/exclude patterns, put each one on a
# separate line. Please look up the --include and --exclude options in the
# rsync man page for more details on how to specify file name patterns.
#
#include        ???
#include        ???
#exclude        ???
#exclude        ???
# The include_file and exclude_file parameters, if enabled, simply get
# passed directly to rsync. Please look up the --include-from and
# --exclude-from options in the rsync man page for more details.
#
#include_file  /path/to/include/file
#exclude_file  /path/to/exclude/file
# If your version of rsync supports --link-dest, consider enabling  this.
# This is the best way to support special files (FIFOs, etc) cross-platform.
# The default is 0 (off).
#
#link_dest      0
# When sync_first is enabled, it changes the default behaviour of rsnapshot.
# Normally, when rsnapshot is called with its lowest interval
# (i.e.: "rsnapshot alpha"), it will sync files AND rotate the lowest
# intervals. With sync_first enabled, "rsnapshot sync" handles the file sync,
# and all interval calls simply rotate files. See the man page for more
# details. The default is 0 (off).
#
#sync_first    0
# If enabled, rsnapshot will move the oldest directory for each interval
# to [interval_name].delete, then it will remove the lockfile and delete
# that directory just before it exits. The default is 0 (off).
#
#use_lazy_deletes      0
# Number of rsync re-tries. If you experience any network problems or
# network card issues that tend to cause ssh to fail with errors like
# "Corrupted MAC on input", for example, set this to a non-zero value
# to have the rsync operation re-tried.
#
#rsync_numtries 0
# LVM parameters. Used to backup with creating lvm snapshot before backup
# and removing it after. This should ensure consistency of data in some  special
# cases
#
# LVM snapshot(s) size (lvcreate --size option).
#
#linux_lvm_snapshotsize 100M
# Name to be used when creating the LVM logical volume snapshot(s).
#
#linux_lvm_snapshotname rsnapshot
# Path to the LVM Volume Groups.
#
#linux_lvm_vgpath      /dev
# Mount point to use to temporarily mount the snapshot(s).
#
#linux_lvm_mountpath    /path/to/mount/lvm/snapshot/during/backup
###############################
### BACKUP POINTS / SCRIPTS ###
###############################
# LOCALHOST
'''backup  root@lincln02:/etc/            media/daten/rsnapshot/'''
'''backup  root@mx10.foxtom.de:/etc/      media/daten/rsnapshot/'''
'''backup  root@mx20.foxtom.de:/etc/      media/daten/rsnapshot/'''
'''backup  root@mx50.foxtom.de:/etc/      media/daten/rsnapshot/'''
#backup /usr/local/    localhost/
#backup /var/log/rsnapshot              localhost/
#backup /etc/passwd    localhost/
#backup /home/foo/My Documents/        localhost/
#backup /foo/bar/      localhost/      one_fs=1, rsync_short_args=-urltvpog
#backup_script  /usr/local/bin/backup_pgsql.sh  localhost/postgres/
# You must set linux_lvm_* parameters below before using lvm snapshots
#backup lvm://vg0/xen-home/    lvm-vg0/xen-home/
# EXAMPLE.COM
#backup_exec    /bin/date "+ backup of example.com started at %c"
#backup root@example.com:/home/ example.com/    +rsync_long_args=-- bwlimit=16,exclude=core
#backup root@example.com:/etc/  example.com/    exclude=mtab,exclude=core
#backup_exec    ssh root@example.com "mysqldump -A > /var/db/dump/mysql.sql"
#backup root@example.com:/var/db/dump/  example.com/
#backup_exec    /bin/date "+ backup of example.com ended at %c"
# CVS.SOURCEFORGE.NET
#backup_script  /usr/local/bin/backup_rsnapshot_cvsroot.sh      rsnapshot.cvs.sourceforge.net/
# RSYNC.SAMBA.ORG
#backup rsync://rsync.samba.org/rsyncftp/      rsync.samba.org/rsyncftp/


==Anhang 02 - duply.conf komplett==
==Monitoring==


# gpg encryption settings, simple settings:
===RAID===
#  GPG_KEY='disabled' - disables encryption alltogether
#  GPG_KEY='<key1>[,<key2>]'; GPG_PW='pass' - encrypt with keys,
#  sign if secret key of key1 is available use GPG_PW for sign & decrypt
#  Note: you can specify keys via all methods described in gpg manpage,
#        section "How to specify a user ID", escape commas (,) via backslash (\)
#        e.g. 'Mueller, Horst', 'Bernd' -> 'Mueller\, Horst, Bernd'
#        as they are used to separate the entries
#  GPG_PW='passphrase' - symmetric encryption using passphrase only
'''GPG_KEY='B2E20485FF7FC772 ' '''
'''GPG_PW='roottutgut' '''
# gpg encryption settings in detail (extended settings)
#  the above settings translate to the following more specific settings
#  GPG_KEYS_ENC='<keyid1>[,<keyid2>,...]' - list of pubkeys to encrypt to
#  GPG_KEY_SIGN='<keyid1>|disabled' - a secret key for signing
#  GPG_PW='<passphrase>' - needed for signing, decryption and symmetric
#  encryption. If you want to deliver different passphrases for e.g.
#  several keys or symmetric encryption plus key signing you can use
#  gpg-agent. Simply make sure that GPG_AGENT_INFO is set in environment.
#  also see "A NOTE ON SYMMETRIC ENCRYPTION AND SIGNING" in duplicity manpage
# notes on en/decryption
#  private key and passphrase will only be needed for decryption or signing.
#  decryption happens on restore and incrementals (compare archdir contents).
#  for security reasons it makes sense to separate the signing key from the
#  encryption keys. https://answers.launchpad.net/duplicity/+question/107216
#GPG_KEYS_ENC='<pubkey1>,<pubkey2>,...'
#GPG_KEY_SIGN='<prvkey>'
# set if signing key passphrase differs from encryption (key) passphrase
# NOTE: available since duplicity 0.6.14, translates to SIGN_PASSPHRASE
#GPG_PW_SIGN='<signpass>'
# uncomment and set a file path or name force duply to use this gpg executable
# available in duplicity 0.7.04 and above (currently unreleased 06/2015)
#GPG='/usr/local/gpg-2.1/bin/gpg'
# gpg options passed from duplicity to gpg process (default='')
# e.g. "--trust-model pgp|classic|direct|always"
#  or "--compress-algo=bzip2 --bzip2-compress-level=9"
#  or "--personal-cipher-preferences AES256,AES192,AES..."
#  or "--homedir ~/.duply" - keep keyring and gpg settings duply specific
#  or "--pinentry-mode loopback" - needed for GPG 2.1+ _and_
#      also enable allow-loopback-pinentry in your .gnupg/gpg-agent.conf
'''GPG_OPTS='--compress-algo=bzip2 --bzip2-compress-level=9 --personal- cipher-preferences AES256' '''
# disable preliminary tests with the following setting
#GPG_TEST='disabled'
# backend, credentials & location of the backup target (URL-Format)
# generic syntax is
#  scheme://[user[:password]@]host[:port]/[/]path
# eg.
#  sftp://bob:secret@backupserver.com//home/bob/dupbkp
# for details and available backends see duplicity manpage, section URL Format
#  http://duplicity.nongnu.org/duplicity.1.html#sect7
# BE AWARE:
#  some backends (cloudfiles, S3 etc.) need additional env vars to be set to
#  work properly, read after the TARGET definition for more details.
# ATTENTION:
#  characters other than A-Za-z0-9.-_.~ in the URL have to be
#  replaced by their url encoded pendants, see
#    http://en.wikipedia.org/wiki/Url_encoding
#  if you define the credentials as TARGET_USER, TARGET_PASS below duply
#  will try to url_encode them for you if the need arises.
'''TARGET='file:///home/user/zielbackup' '''
# optionally the username/password can be defined as extra variables
# setting them here _and_ in TARGET results in an error
# ATTENTION:
#  there are backends that do not support the user/pass auth scheme.
#  prominent examples are S3, Azure, Cloudfiles. when in doubt consult the
#  duplicity manpage. usually there is a NOTE section explaining if and which
#  env vars should be set.
#TARGET_USER='_backend_username_'
#TARGET_PASS='_backend_password_'
# eg. for cloud files backend it might look like this (uncomment for use!)
#export CLOUDFILES_USERNAME='someuser'
#export CLOUDFILES_APIKEY='somekey'
#export CLOUDFILES_AUTHURL ='someurl'
# the following is an incomplete list (<backend>: comma separated env vars list)
# Azure: AZURE_ACCOUNT_NAME, AZURE_ACCOUNT_KEY
# Cloudfiles: CLOUDFILES_USERNAME, CLOUDFILES_APIKEY, CLOUDFILES_AUTHURL
# Google Cloud Storage: GS_ACCESS_KEY_ID, GS_SECRET_ACCESS_KEY
# Pydrive: GOOGLE_DRIVE_ACCOUNT_KEY, GOOGLE_DRIVE_SETTINGS
# S3: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
# Swift: SWIFT_USERNAME, SWIFT_PASSWORD, SWIFT_AUTHURL,
#        SWIFT_TENANTNAME OR SWIFT_PREAUTHURL, SWIFT_PREAUTHTOKEN
# base directory to backup
'''SOURCE='/' '''
# a command that runs duplicity e.g.
#  shape bandwidth use via trickle
#  "trickle -s -u 640 -d 5120" # 5Mb up, 40Mb down"
#DUPL_PRECMD=""
# override the used python interpreter, defaults to
#  - parsed result of duplicity's shebang or 'python2'
#  e.g. "python2" or "/usr/bin/python2.7"
#PYTHON="python"
# exclude folders containing exclusion file (since duplicity 0.5.14)
# Uncomment the following two lines to enable this setting.
#FILENAME='.duplicity-ignore'
#DUPL_PARAMS="$DUPL_PARAMS --exclude-if-present '$FILENAME'"
# Time frame for old backups to keep, Used for the "purge" command. 
# see duplicity man page, chapter TIME_FORMATS)
'''MAX_AGE=1M'''
# Number of full backups to keep. Used for the "purgeFull" command.
# See duplicity man page, action "remove-all-but-n-full".
'''MAX_FULL_BACKUPS=1'''
# Number of full backups for which incrementals will be kept for.
# Used for the "purgeIncr" command.
# See duplicity man page, action "remove-all-inc-of-but-n-full".
#MAX_FULLS_WITH_INCRS=1
# activates duplicity --full-if-older-than option (since duplicity v0.4.4.RC3)
# forces a full backup if last full backup reaches a specified age, for the
# format of MAX_FULLBKP_AGE see duplicity man page, chapter TIME_FORMATS
# Uncomment the following two lines to enable this setting.
#MAX_FULLBKP_AGE=1M
#DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "
# sets duplicity --volsize option (available since v0.4.3.RC7)
# set the size of backup chunks to VOLSIZE MB instead of the default 25MB.
# VOLSIZE must be number of MB's to set the volume size to.
# Uncomment the following two lines to enable this setting.
'''VOLSIZE=100'''
'''DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE " '''
# verbosity of output (error 0, warning 1-2, notice 3-4, info 5-8, debug 9)
# default is 4, if not set
'''VERBOSITY=8'''
# temporary file space. at least the size of the biggest file in backup
# for a successful restoration process. (default is '/tmp', if not set)
#TEMP_DIR=/tmp
# Modifies archive-dir option (since 0.6.0) Defines a folder that holds
# unencrypted meta data of the backup, enabling new incrementals without the
# need to decrypt backend metadata first. If empty or deleted somehow, the
# private key and it's password are needed.
# NOTE: This is confidential data. Put it somewhere safe. It can grow  quite
#      big over time so you might want to put it not in the home dir.
# default '~/.cache/duplicity/duply_<profile>/'
# if set  '${ARCH_DIR}/<profile>'
#ARCH_DIR=/some/space/safe/.duply-cache
# DEPRECATED setting
# sets duplicity --time-separator option (since v0.4.4.RC2) to allow users
# to change the time separator from ':' to another character that will work
# on their system.  HINT: For Windows SMB shares, use --time-separator='_'.
# NOTE: '-' is not valid as it conflicts with date separator.
# ATTENTION: only use this with duplicity < 0.5.10, since then default file
#            naming is compatible and this option is pending depreciation
#DUPL_PARAMS="$DUPL_PARAMS --time-separator _ "
# DEPRECATED setting
# activates duplicity --short-filenames option, when uploading to a file
# system that can't have filenames longer than 30 characters (e.g. Mac OS 8)
# or have problems with ':' as part of the filename (e.g. Microsoft Windows)
# ATTENTION: only use this with duplicity < 0.5.10, later versions default file
#            naming is compatible and this option is pending depreciation
#DUPL_PARAMS="$DUPL_PARAMS --short-filenames "
# more duplicity command line options can be added in the following way
# don't forget to leave a separating space char at the end
#DUPL_PARAMS="$DUPL_PARAMS --put_your_options_here "


====Anhang 03 - Konfiguration exclude-Datei====


# vi /root/.duply/backuptest/exclude


# although called exclude, this file is actually a globbing file list
====Manuelle Statusabfrage====
# duplicity accepts some globbing patterns, even including ones here
# here is an example, this incl. only 'dir/bar' except it's subfolder 'foo'
# - dir/bar/foo
# + dir/bar
# - **
# for more details see duplicity manpage, section File Selection
# http://duplicity.nongnu.org/duplicity.1.html#sect9
   
   
  '''+ /etc'''
  # '''cat /proc/mdstat'''
  '''- **'''
  mdadm -D /dev/md1


===Anhang 04 - Erstellung ssh-keys===
====mdadm.conf erstellen====
# gpg --full-generate-key
*Über Ausfälle sollten die Benutzer per E-Mail benachrichtigt werden.
gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
*Dafür musste für mdadm eine Konfigurationsdatei erstellt werden.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
    (1) RSA und RSA (voreingestellt)
    (2) DSA und Elgamal
    (3) DSA (nur signieren/beglaubigen)
    (4) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (3072) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
          0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am Do 04 Nov 2021 18:26:30 CET
Ist dies richtig? (j/N) j
GnuPG erstellt eine User-ID, um Ihren Schlüssel identifizierbar zu  machen.
Ihr Name ("Vorname Nachname"): Robert Quies
Email-Adresse: raqju@web.de
Kommentar: Es grünt so grün, wenn Spaniens Blüten blühn.
Sie benutzen den Zeichensatz `utf-8'
Sie haben diese User-ID gewählt:
    "Robert Quies (Es grünt so grün, wenn Spaniens Blüten blühn.)  <raqju@web.de>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? F
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole  irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole  irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel F47E1B7450082D11 ist als ultimativ vertrauenswürdig gekennzeichnet
gpg: Verzeichnis `/root/.gnupg/openpgp-revocs.d' erzeugt
gpg: Widerrufzertifikat wurde als '/root/.gnupg/openpgp-revocs.d /60E3D3C9ED78CE4A40322BBAF47E1B7450082D11.rev' gespeichert.
Öffentlichen und geheimen Schlüssel erzeugt und signiert.
pub  rsa4096 2020-11-04 [SC] [verfällt: 2021-11-04]
      60E3D3C9ED78CE4A40322BBAF47E1B7450082D11
uid                      Robert Quies (Es grünt so grün, wenn Spaniens  Blüten blühn.) <raqju@web.de>
sub  rsa4096 2020-11-04 [E] [verfällt: 2021-11-04]


<!-- HINFÄLLIG
# su -c "/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf"


-beim Versuch Backup manuell zu erestellen
====mdadm.conf editieren====
Befehl
*In der mdadm.conf muss dafür in der Zeile...
  # duply .duply/backup007 full_verify_purge --force
'''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.&nbsp;B.&nbsp;via Postfix als Satellitensystem.


neuer Fehler
===rsnapshot===
# duply .duply/backuptest  full_verify_purge --force
Start duply v2.1, time is 2020-11-04 19:52:32.
.duply/backuptest/conf: Zeile 96: shebang: Kommando nicht gefunden.
Using profile '/root/.duply/backuptest'.
Sorry. A fatal ERROR occured:
Source Path (setting SOURCE) not set or still default value in conf file
'/root/.duply/backuptest/conf'.
HINFÄLLIG


===duply===


--------------------------- -->
==Qualitätssicherung==
===Anhang 05 - Passphrase kann nicht abgefragt werden===
*RAID/Platten i.O.?
Befehl
*Dateisystem i.O.
# duply /root/.duply/Name_Backup_Profil full
*Software aktuell
*Werden cronjobs abgearbeitet?


Meldung
  -- Backup durchführen -- Restore durchführen -- Vergleich der Daten durchführen (sha, diff)
  [GNUPG:] PINENTRY_LAUNCHED 23758 curses 1.1.0 - linux -
gpg: Beglaubigung fehlgeschlagen: Unpassender IOCTL (I/O-Control) für das Gerät
[GNUPG:] BEGIN_ENCRYPTION 2 9
[GNUPG:] FAILURE sign-encrypt 83918950
gpg: /usr/bin/duply: sign+encrypt failed: Unpassender IOCTL (I/O-Control) für das Gerät


Lösung
==Übergabe==
echo use-agent >> ~/.gnupg/gpg.conf
echo "pinentry-mode loopback" >> ~/.gnupg/gpg.conf
echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf


Hintergrund
===Protokoll===
Es kommt zu dieser Fehlermeldung, weil gpg die Passphrase nicht automatisch abfragen konnte.
*Was wird wie, wann und wohin gesichert?
Die erledigt der gpg-agent, der wiederum [[Sicherheit:pinentry-curses|pinentry-curses]] zur sicheren Übertragung der Passphrase vewendet.
*Besondere Aufbewahrungregeln existent?
In der gpg.conf muss angegeben werden, dass der gpg-agent verwendet werden soll (use-agent).
*Bestätigung, dass das Backup zum Zeitpunkt der Übergabe läuft.
Und in welchem Modus dieser verwendet werden soll (pinentry-mode loopback).
*Vorgehensweise bei Ausfällen.
In der gpg-agent.conf muss dem gpg-agent erlaubt werden den loop-back-pinentry durchzuführen (allow-loopback-pinentry).
*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==
=====Anhang 05.2 - Fehler: Schreibfehler=====


Befehl
==Glossar==
# duply /root/.duply/ersatzBU/ full                         
Start duply v2.1, time is 2020-11-10 11:55:58.
Ausgabe
INFO:
 
duplicity version check failed (please report, this is a bug)
the command
  duplicity --version 2>&1
resulted in
  gpg: /root/.gnupg/gpg.conf:2: '''invalid option'''
duplicity 0.7.18.2
Using profile '/root/.duply/ersatzBU'.
Using installed duplicity version INVALID, python 2.7.16 (/usr/bin/python2), gpg 2.2.12 (Home: /root/.gnupg), awk 'GNU Awk 4.2.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)', grep 'grep (GNU grep) 3.3', bash '5.0.3(1)-release (x86_64-pc-linux-gnu)'.
Encryption public key '1A955E6287B8E312' not found.
WARNING:
'''No keyfile for '1A955E6287B8E312' found in profile '/root/.duply/ersatzBU'.'''
Autoset trust of key '1A955E6287B8E312' to ultimate (FAILED)
For duply to work you have to set the trust level
with the command "trust" to "ultimate" (5) now.
Exit the edit mode of gpg with "quit".
Running gpg to manually edit key '1A955E6287B8E312' (FAILED)
 
Sorry. A fatal ERROR occured:
Public gpg key '1A955E6287B8E312' cannot be found.
 
Hints:
   
  Doublecheck if the above key is listed by 'gpg --list-keys' or available
  as gpg key file 'gpgkey.1A955E6287B8E312.asc' in the profile folder.
  If not you can put it there and duply will autoimport it on the next run.
  Alternatively import it manually as the user you plan to run duply with.
  Maybe you have not created a gpg key yet (e.g. gpg --gen-key)?
  Don't forget the used _password_ as you will need it.
  When done enter the 8 digit id & the password in the profile conf file.
  The key id can be found doing a 'gpg --list-keys'. In the  example output
  below the key id would be FFFFFFFF for the public key.
  pub  1024D/FFFFFFFF 2007-12-17
  uid                  duplicity
  sub  2048g/899FE27F 2007-12-17


Lösung
==Quellen==
War mein Fehler.
TODO: Originaldokumentationen als Quellen angeben
Hatte echo "pin'''t'''entry-mode loopback" >> ~/.gnupg/gpg.conf eingetragen
und nicht echo "pinentry-mode loopback" >> ~/.gnupg/gpg.conf.
 
----------------------------- -->
 
===Anhang 06 - Privater ssh-key (RSA) nicht valide===
 
Befehl
# duply /root/.duply/Name_Backup_Profil full
 
Meldung
# duply /root/.duply/ersatzBU/ full 
Start duply v2.1, time is 2020-11-10 12:17:27.
Using profile '/root/.duply/ersatzBU'.
Using installed duplicity version 0.7.18.2, python 2.7.16 (/usr/bin/python2), gpg 2.2.12 (Home: /root/.gnupg), awk 'GNU Awk 4.2.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)', grep 'grep (GNU grep) 3.3', bash '5.0.3(1)-release (x86_64-pc-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry '1A955E6287B8E312' for signing.
Checking TEMP_DIR '/tmp' is a folder and writable (OK)
Test - Encrypt to '1A955E6287B8E312' & Sign with '1A955E6287B8E312' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.3187.1605007047_*'(OK)
'''Backup PUB key '1A955E6287B8E312' to profile. (OK)'''
'''Write file 'gpgkey.1A955E6287B8E312.pub.asc' (OK)'''
'''Backup SEC key '1A955E6287B8E312' to profile. (OK)'''
'''Write file 'gpgkey.1A955E6287B8E312.sec.asc' (OK)'''
INFO:
'''duply exported new keys to your profile.'''
'''You should backup your changed profile folder now and store it in a safe place.'''
--- Start running command FULL at 12:17:30.512 ---
Using archive dir: /root/.cache/duplicity/duply_ersatzBU
Using backup name: duply_ersatzBU
Import of duplicity.backends.acdclibackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
/usr/lib/python2.7/dist-packages/paramiko/ecdsakey.py:164: CryptographyDeprecationWarning: Support for unsafe construction of public numbers from encoded data will be removed in a future version. Please use EllipticCurvePublicKey.from_encoded_point
  self.ecdsa_curve.curve_class(), pointinfo
ssh: Connected (version 2.0, client OpenSSH_7.5)
Using temporary directory /tmp/duplicity-IXHreI-tempdir
Backend error detail: Traceback (innermost last):
  File "/usr/bin/duplicity", line 1567, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1553, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1392, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1135, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1010, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in get_backend_object
    return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/ssh_paramiko_backend.py", line 235, in __init__
    self.config['port'], e))
  '''BackendException: ssh connection to u153662-sub1@u153662.your-storagebox.de:23 failed: not a valid RSA private key file'''
 
'''BackendException: ssh connection to u153662-sub1@u153662.your-storagebox.de:23 failed: not a valid RSA private key file'''
12:17:31.728 Task 'FULL' failed with exit code '23'.
--- Finished state FAILED 'code 23' at 12:17:31.728 - Runtime 00:00:01.216 ---
 
Lösung
 
Benötigt duplicity den ssh-key im PEM-Format, wenn duplicity sich via ssh anmelden soll. - Verifiziert durch Duplizierung des Fehlers.
 
# ssh-keygen -p -f /root/.ssh/id_rsa -m pem -P "" -N ""
 
Änderung des Formats des ssh-Keys von OPENSSH zu PEM ([https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail Privacy-Enhanced Mail])
 
ssh-keygen
{|class="wikitable"
!Option !! Beschreibung
|-
| -p  || Fordert die Änderung der Passphrase einer privaten Schlüsseldatei zu ändern, anstatt einen neuen privaten Schlüssel zu erstellen. Das Programm fordert Sie auf, die Datei mit dem privaten Schlüssel, die alte Passphrase und zweimal die neue Passphrase einzugeben.
|-
| -f  || Dateiname. Gibt den Dateinamen der Schlüsseldatei an. Hier der Pfad /root/.ssh/id_rsa
|-
| -m || Geben Sie ein Schlüsselformat für die Konvertierungsoptionen -i (Import) oder -e (Export) an. Die unterstützten Schlüsselformate sind: "RFC4716" (öffentlicher oder privater RFC 4716 / SSH2-Schlüssel), "PKCS8" (öffentlicher PEM PKCS8-Schlüssel) oder "PEM" (öffentlicher PEM-Schlüssel). Das Standardkonvertierungsformat ist "RFC4716". Wenn Sie beim Generieren oder Aktualisieren eines unterstützten privaten Schlüsseltyps das Format "PEM" festlegen, wird der Schlüssel im alten privaten PEM-Schlüsselformat gespeichert. Hier soll der ssh-key in das PEM-Format konvertiert werden also: -m PEM.
 
in engl.: Specify a key format for the -i (import) or -e (export) conversion options. The supported key formats are: "RFC4716" (RFC 4716/SSH2 public or private key), "PKCS8" (PEM PKCS8 public key) or "PEM" (PEM public key). The default conversion format is "RFC4716". Setting a format of "PEM" when generating or updating a supported private key type will cause the key to be stored in the legacy PEM private key format.
|-
| -P || passphrase
Stellt die (alte) Passphrase bereit.
|-
| -N || new_passphrase
Stellt die neue Passphrase bereit.
|-
|"Passphrase"|| Da hier weder im alten noch im neuen Format für den ssh-key eine Passphrase verwendet wurde bzw. werden soll, wird zwischen den beiden " nichts eingetragen: ""
|}
 
 
Danach klappt es:
 
# duply /root/.duply/ersatzBU/ full                   
Start duply v2.1, time is 2020-11-10 12:39:16.
Using profile '/root/.duply/ersatzBU'.
Using installed duplicity version 0.7.18.2, python 2.7.16 (/usr/bin/python2), gpg 2.2.12 (Home: /root/.gnupg), awk 'GNU Awk 4.2.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)', grep 'grep (GNU grep) 3.3', bash '5.0.3(1)-release (x86_64-pc-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry '1A955E6287B8E312' for signing.
Checking TEMP_DIR '/tmp' is a folder and writable (OK)
Test - Encrypt to '1A955E6287B8E312' & Sign with '1A955E6287B8E312' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.3711.1605008357_*'(OK)
--- Start running command FULL at 12:39:18.553 ---
Using archive dir: /root/.cache/duplicity/duply_ersatzBU
Using backup name: duply_ersatzBU
Import of duplicity.backends.acdclibackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
/usr/lib/python2.7/dist-packages/paramiko/ecdsakey.py:164: CryptographyDeprecationWarning: Support for unsafe construction of public numbers from encoded data will be removed in a future version. Please use EllipticCurvePublicKey.from_encoded_point
  self.ecdsa_curve.curve_class(), pointinfo
ssh: Connected (version 2.0, client OpenSSH_7.5)
ssh: Authentication (publickey) successful!
ssh: [chan 0] Opened sftp connection (server version 3)
Reading globbing filelist /root/.duply/ersatzBU/exclude
Main action: full
================================================================================
duplicity 0.7.18.2 (October 17, 2018)
Args: /usr/bin/duplicity full --name duply_ersatzBU --encrypt-key 1A955E6287B8E312 --sign-key 1A955E6287B8E312 --verbosity 8 --gpg-options --compress-algo=bzip2 --bzip2-compress-level=9 --volsize 100 --exclude-filelist /root/.duply/ersatzBU/exclude / sftp://u153662-sub1@u153662.your-storagebox.de:23/backup
Linux debian1 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64
/usr/bin/python2 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0]
================================================================================
Using temporary directory /tmp/duplicity-isr25J-tempdir
Temp has 606838784 available, backup will use approx 136314880.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Collection Status
-----------------
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/duply_ersatzBU
Found 0 secondary backup chains.
No backup chains with active signatures found
No orphaned or incomplete backup sets found.
Reuse configured PASSPHRASE as SIGN_PASSPHRASE
Using temporary directory /root/.cache/duplicity/duply_ersatzBU/duplicity-CWEaS8-tempdir
Using temporary directory /root/.cache/duplicity/duply_ersatzBU/duplicity-6dFeup-tempdir
AsyncScheduler: instantiating at concurrency 0
A .
A var
A var/cache
A var/cache/rsnapshot
AsyncScheduler: running task synchronously (asynchronicity disabled)
Writing duplicity-full.20201110T113919Z.vol1.difftar.gpg
Deleting /tmp/duplicity-isr25J-tempdir/mktemp-iyc8sL-2
AsyncScheduler: task completed successfully
Processed volume 1
Writing duplicity-full-signatures.20201110T113919Z.sigtar.gpg
Deleting /root/.cache/duplicity/duply_ersatzBU/duplicity-full-signatures.20201110T113919Z.sigtar.gpg
Writing duplicity-full.20201110T113919Z.manifest.gpg
Deleting /root/.cache/duplicity/duply_ersatzBU/duplicity-full.20201110T113919Z.manifest.gpg
--------------[ Backup Statistics ]--------------
StartTime 1605008359.92 (Tue Nov 10 12:39:19 2020)
EndTime 1605008359.97 (Tue Nov 10 12:39:19 2020)
ElapsedTime 0.04 (0.04 seconds)
SourceFiles 4
SourceFileSize 16384 (16.0 KB)
NewFiles 4
NewFileSize 16384 (16.0 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 4
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 1582 (1.54 KB)
Errors 0
-------------------------------------------------
--- Finished state OK at 12:39:21.932 - Runtime 00:00:03.379 ---
 
===Anhang 07 - Von synchronen auf asynchronen Modus umstellen===
*Arbeitet Backupvorgang effizienter ab.
 
'''AsyncScheduler: running task synchronously (asynchronicity disabled)'''
 
bei duplicity
Option:
--asynchronous-upload
 
Diese Option in der .duply/conf eintragen unter:
 
# more duplicity command line options can be added in the following way
# don't forget to leave a seperating space char at the end
DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "
 
Danach
# duply /root/.duply/ersatzBU/ full               
Start duply v2.1, time is 2020-11-10 13:27:40.
Using profile '/root/.duply/ersatzBU'.
Using installed duplicity version 0.7.18.2, python 2.7.16 (/usr/bin/python2), gpg 2.2.12 (Home: /root/.gnupg), awk 'GNU Awk 4.2.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)', grep 'grep (GNU grep) 3.3', bash '5.0.3(1)-release (x86_64-pc-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry '1A955E6287B8E312' for signing.
Checking TEMP_DIR '/tmp' is a folder and writable (OK)
Test - Encrypt to '1A955E6287B8E312' & Sign with '1A955E6287B8E312' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.4565.1605011260_*'(OK)
--- Start running command FULL at 13:27:41.716 ---
Using archive dir: /root/.cache/duplicity/duply_ersatzBU
Using backup name: duply_ersatzBU
Import of duplicity.backends.acdclibackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
/usr/lib/python2.7/dist-packages/paramiko/ecdsakey.py:164: CryptographyDeprecationWarning: Support for unsafe construction of public numbers from encoded data will be removed in a future version. Please use EllipticCurvePublicKey.from_encoded_point
  self.ecdsa_curve.curve_class(), pointinfo
ssh: Connected (version 2.0, client OpenSSH_7.5)
ssh: Authentication (publickey) successful!
ssh: [chan 0] Opened sftp connection (server version 3)
Reading globbing filelist /root/.duply/ersatzBU/exclude
Main action: full
================================================================================
duplicity 0.7.18.2 (October 17, 2018)
Args: /usr/bin/duplicity full --name duply_ersatzBU --encrypt-key 1A955E6287B8E312 --sign-key 1A955E6287B8E312 --verbosity 8 --gpg-options --compress-algo=bzip2 --bzip2-compress-level=9 --volsize 100 '''--asynchronous-upload''' --exclude-filelist /root/.duply/ersatzBU/exclude / sftp://u153662-sub1@u153662.your-storagebox.de:23/backup
Linux debian1 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64
/usr/bin/python2 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0]
================================================================================
Using temporary directory /tmp/duplicity-lFN02I-tempdir
Temp has 606838784 available, backup will use approx 241172480.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Tue Nov 10 12:39:19 2020
Collection Status
-----------------
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/duply_ersatzBU
Found 0 secondary backup chains.
Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Tue Nov 10 12:39:19 2020
Chain end time: Tue Nov 10 12:39:19 2020
Number of contained backup sets: 1
Total number of contained volumes: 1
  Type of backup set:                            Time:      Num volumes:
                Full        Tue Nov 10 12:39:19 2020                1
-------------------------
No orphaned or incomplete backup sets found.
Reuse configured PASSPHRASE as SIGN_PASSPHRASE
Using temporary directory /root/.cache/duplicity/duply_ersatzBU/duplicity-h7ERXb-tempdir
Using temporary directory /root/.cache/duplicity/duply_ersatzBU/duplicity-sHK2KZ-tempdir
'''AsyncScheduler: instantiating at concurrency 1'''
A .
A var
A var/cache
A var/cache/rsnapshot
'''AsyncScheduler: scheduling task for asynchronous execution'''
Processed volume 1
Writing duplicity-full.20201110T122742Z.vol1.difftar.gpg
Deleting /tmp/duplicity-lFN02I-tempdir/mktemp-6T80j7-2
'''AsyncScheduler: task execution done (success: True)'''
Writing duplicity-full-signatures.20201110T122742Z.sigtar.gpg
Deleting /root/.cache/duplicity/duply_ersatzBU/duplicity-full-signatures.20201110T122742Z.sigtar.gpg
Writing duplicity-full.20201110T122742Z.manifest.gpg
Deleting /root/.cache/duplicity/duply_ersatzBU/duplicity-full.20201110T122742Z.manifest.gpg
--------------[ Backup Statistics ]--------------
StartTime 1605011263.12 (Tue Nov 10 13:27:43 2020)
EndTime 1605011263.14 (Tue Nov 10 13:27:43 2020)
ElapsedTime 0.02 (0.02 seconds)
SourceFiles 4
SourceFileSize 16384 (16.0 KB)
NewFiles 4
NewFileSize 16384 (16.0 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 4
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 1593 (1.56 KB)
Errors 0
-------------------------------------------------
--- Finished state OK at 13:27:45.045 - Runtime 00:00:03.329 ---
 
==Anhang 08 - gpg: Algorithmus pigz anstatt bzip2 verwenden, schlägt fehl==
*'''p'''arallel '''i'''mplementation of '''gz'''ip
*Nutzt alle CPU-Kerne zum Komprimieren der Archive.
 
*Resultat pigz wird weder von gpg noch gpg2 unterstützt.
 
# gpg --version
gpg (GnuPG) 2.2.12
libgcrypt 1.8.4
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /root/.gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
 
# gpg2 --version
gpg (GnuPG) 2.2.12
libgcrypt 1.8.4
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /root/.gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
 
==Anhang 09 - Oberflächenanalyse /dev/sdd==
# smartctl -l selftest /dev/sdd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-12-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining LifeTime(hours)  LBA_of_first_error
'''# 1  Extended offline    Completed without error      00%    14712        -'''
# 2  Short offline      Completed without error      00%    14464        -
# 3  Extended offline    Completed without error      00%    14454        -
# 4  Short offline      Completed without error      00%    14443        -
# 5  Extended offline    Aborted by host              40%    14292        -
# 6  Extended offline    Completed without error      00%    14214        -
# 7  Short offline      Completed without error      00%    14212        -
# 8  Extended offline    Completed without error      00%    12438        -
# 9  Short offline      Completed without error      00%      8832        -
#10  Short offline      Completed without error      00%      3498        -
 
===Anhang 10 - Werte aller Attribute /dev/sdd===
 
# smartctl -A /dev/sdd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-12-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG    VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate    0x002f  100  100  051    Pre-fail  Always      -      96
  2 Throughput_Performance  0x0026  055  055  000    Old_age  Always      -      8674
  3 Spin_Up_Time            0x0023  070  068  025    Pre-fail  Always      -      9391
  4 Start_Stop_Count        0x0032  098  098  000    Old_age  Always      -      2093
  5 Reallocated_Sector_Ct  0x0033  252  252  010    Pre-fail  Always      -      0
  7 Seek_Error_Rate        0x002e  252  252  051    Old_age  Always      -      0
  8 Seek_Time_Performance  0x0024  252  252  015    Old_age  Offline      -      0
  9 Power_On_Hours          0x0032  100  100  000    Old_age  Always      -      14714
  10 Spin_Retry_Count        0x0032  252  252  051    Old_age  Always      -      0
  11 Calibration_Retry_Count 0x0032  252  252  000    Old_age  Always      -      0
  12 Power_Cycle_Count      0x0032  098  098  000    Old_age  Always      -      2114
191 G-Sense_Error_Rate      0x0022  100  100  000    Old_age  Always      -      1
192 Power-Off_Retract_Count 0x0022  252  252  000    Old_age  Always      -      0
194 Temperature_Celsius    0x0002  064  052  000    Old_age  Always      -      35 (Min/Max 9/48)
195 Hardware_ECC_Recovered  0x003a  100  100  000    Old_age  Always      -      0
196 Reallocated_Event_Count 0x0032  252  252  000    Old_age  Always      -      0
197 Current_Pending_Sector  0x0032  252  252  000    Old_age  Always      -      0
198 Offline_Uncorrectable  0x0030  252  252  000    Old_age  Offline      -      0
199 UDMA_CRC_Error_Count    0x0036  100  100  000    Old_age  Always      -      1
200 Multi_Zone_Error_Rate  0x002a  100  100  000    Old_age  Always      -      12783
223 Load_Retry_Count        0x0032  252  252  000    Old_age  Always      -      0
225 Load_Cycle_Count        0x0032  100  100  000    Old_age  Always      -      2167
 
==Anhang 11 - Partitionierung - fdisk==
 
*Bezeichnungen herausfinden
#fdisk -l
 
*Datenträger partitionieren
 
# fdisk /dev/sdc
 
Welcome to fdisk (util-linux 2.33.1).                                                                                                           
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
 
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xdfca4904.
Command (m for help):
 
*GPT (GUID-Partition-Table) wird angelegt.


Command (m for help): '''g'''
*[https://rsnapshot.org/ https://rsnapshot.org/]
 
*[https://duply.net/Duply_(simple_duplicity) https://duply.net/Duply_(simple_duplicity)]
Created a new GPT disklabel (GUID: 748568BC-EC8C-F34A-B822-45C2E267CFFB).
*[https://gnupg.org/ https://gnupg.org/]
 
*Partitionstabelle anlegen
 
Command (m for help): '''n'''
 
Partition number (1-128, default 1): '''1'''
First sector (2048-3907029134, default 2048): '''2048'''
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-3907029134, default 3907029134): '''+1842G'''
 
Created a new '''partition 1''' of type 'Linux filesystem' and of '''size 1,8 TiB'''.
 
*Partition als RAID-Partition markieren
 
Command (m for help): '''t'''
 
Selected partition 1
Partition type (type L to list all types): '''29'''
 
Changed type of partition 'Linux filesystem' to 'Linux RAID'.
 
*Änderungen auf Korrektheit überprüfen
 
Command (m for help): '''p'''
 
Disk '''/dev/sdc''': 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZRX-00D
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: '''gpt'''
Disk identifier: 748568BC-EC8C-F34A-B822-45C2E267CFFB
 
Device    Start        End    Sectors  Size Type
/dev/sdc'''1'''  '''2048''' '''3862956031''' 3862953984  1,8T '''Linux RAID'''
 
*Änderungen schreiben
 
Command (m for help): '''w'''
 
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
 
==Anhang 12 - Alignment (Ausrichtung)==
 
*Datenträger, RAID-Verbunde und Dateisysteme fassen Daten jeweils für sich in Blöcke zusammen, bevor sie gespeichert werden.
*Diese Blöcke haben im Allgemeinen alle unterschiedliche Größen.
*Um eine optimale Performance zu erzielen, sollten die Größen aufeinander abgestimmt sein.
*Dafür muss zunächst die sog. Chunk Size, also die Datenmenge, die in einem einzelnen Schreibvorgang geschrieben wird, bekannt sein.
 
===Ermittlung der Chunk Size===
 
# mdadm -D /dev/md0 | grep "Chunk Size"
 
*Bei einem RAID 5 mit Standardeinstellungen liefert dies z.B.:
 
    Chunk Size : 512K
 
*Es werden also 512 [https://de.wikipedia.org/wiki/Byte#Vergleichstabelle KiB] Chunks verwendet.
 
===Änderung der Chunk Size===
*Chunk Size auf 64 KiB ändern.
*Macht nur Sinn, wenn auf dem RAID hauptsächlich sehr kleine Dateien geschrieben bzw. gelesen werden sollen.
 
# mdadm --grow -c 64 /dev/md0
 
===Berechnung des Alignments===
*Hieraus können, zusammen mit der Anzahl der Partitionen und des RAID-Levels, die Dateisystem-Parameter berechnet werden.
 
*Am einfachsten geht das mittels eines [https://busybox.net/~aldot/mkfs_stride.html Raid-Stride-Calculators].
 
*Alternativ können die Parameter auch von Hand ermittelt werden.
**'''block-size''' - Die Größe der Dateisystemblöcke in Bytes. Heutzutage werden fast ausschließlich '''4096 Byte''' (4 KiB) Blöcke verwendet.
**'''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 5 über 4 Partitionen ergibt sich hier '''128 * 3 = 384'''.
 
*Details zur Anzahl der effektiv nutzbaren Partitionen findet man im Artikel [[Hardware:Storage:RAID#RAID-Level|Hardware:Storage:RAID]].
 
*Sind die Parameter ermittelt, wird das Dateisystem erstellt:
 
# mkfs.ext4 -b 4096 -E stride=128,stripe-width=384 /dev/md0
 
==Protokoll==
*[https://www.ihk-berlin.de/blueprint/servlet/resource/blob/4556030/d3cc99dbda3683b53c1d57e86713a62e/protokoll-projektarbeit-itse-data.pdf Protokoll über die durchgeführte Projektarbeit]
 
==Deckblatt (wird bei Seitenanzahl nicht mitgerechnet)==
#Projektbezeichnung: Aufbau und Einrichtung eines Backup-Servers in einem LAN für Client-Backups und zusätzlich Einrichtung einer externen Backup-Lösung.
#Namen und Vornamen: Quies, Robert
#Prüfungsausschuss: ITSE 02
#Ausbildungsberuf: IT-Systemelektroniker
#Ausbildungsstätte bzw. Praktikumsbetrieb: itw gGmbH, Groninger Straße 25, 13347 Berlin bzw. Dirk Wagner Berlin, Carstennstraße 6, 12205 Berlin
 
==Inhaltsverzeichnis (wird bei Seitenanzahl nicht mitgerechnet)==


=Quellen allgemein zur Dokumentation=
=Quellen allgemein zur Dokumentation=
*[https://www.ihk-berlin.de/blueprint/servlet/resource/blob/4556030/d3cc99dbda3683b53c1d57e86713a62e/protokoll-projektarbeit-itse-data.pdf Protokoll über die durchgeführte Projektarbeit]
*[https://www.ihk-berlin.de/blueprint/servlet/resource/blob/4556030/d3cc99dbda3683b53c1d57e86713a62e/protokoll-projektarbeit-itse-data.pdf Protokoll über die durchgeführte Projektarbeit]
*[https://www.ihk-berlin.de/blueprint/servlet/resource/blob/2278684/157ef5cf87bfafde9fa6b515b6ca1d6d/leitfaden-it-systemelektroniker-data.pdf IHK-Leitfaden ITSE]
*[https://www.ihk-berlin.de/blueprint/servlet/resource/blob/2278684/157ef5cf87bfafde9fa6b515b6ca1d6d/leitfaden-it-systemelektroniker-data.pdf IHK-Leitfaden ITSE]
[[Kategorie:Backup/Server]]

Aktuelle Version vom 27. Juli 2024, 10:36 Uhr

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“