Backup allgemein

Aus LOMSO
Zur Navigation springen Zur Suche springen
Du bist hier : {{#youAreHere:Backup allgemein}}




Backup allgemein

Backup mit Linux Mitteln

copy/paste

Verbreitet sind Backups per copy/paste auf eine andere HD oder eine externe Festplatte. Das kann jeder, ist einfach, hat aber gravierende Probleme.

  • dauert relativ lange
  • wenig Kontrolle über den Fortschritt
  • kann nicht unterbrochen werden
- man kann, aber dann ist der Stand des Kopiervorganges nicht bekannt
- und man muss alles wiederholen
  • keine Integritätsprüfung
  • Ausschluss unerwünschter Dateien schwierig

Da die Verzeichnisstrukturen im Original und im Backup meist sehr ähnlich sind, ist es leicht möglich, dass 'Backup' und 'Original' in der Aufregung eines evtl. notwendigen 'Restore' vertauscht werden, ohne dass man es gleich merkt.

Und ein versehentliches rm -rf / kann alle Daten löschen

rsync, das bessere cp

Ersatz für copy/paste

  • mehr Prüfungen
  • inkrementell
  • kann mit SSH zusammenarbeiten
  • kann mit remote Systemen arbeiten
  • flexibel, viele Optionen
  • Entkopplung Quelle - Ziel ist einfach
  • delta-transfer (nur Differenzen werden übertragen)

Filesysteme für rsync

  • nur Linux, andere vermeiden, wie FAT32, NTFS
  • ext3, ext4
  • SAMBA im NAS, was wird intern verwendet?

meine Optionen für 'rsync', ohne SSH

  • $ rsync -avSAXHP source/ target/
- alle Attribute, Sparse Files, Rechte, Hardlinks,


rsync remote mit SSH

  • nicht komplexer als vorher
  • $ rsync -avSAXHP **user@client:**/source/ target/
- SSH wird automatisch verwendet (Option -e, kann weggelassen werden)
- in beide Richtungen möglich
    • Entkopplung
- Server holt die Daten vom Client
- versehentliches Löschen nicht möglich
- Client hat keine Möglichkeit, die Daten zu manipulieren
- rm -rf / löscht nur den Client, nie das Backup

SSH für Verwendung mit 'rsync'

  • nur über Schlüssel sinnvoll
  • Client hat keinen Zugriff auf Server
  • Server hat Zugriff auf Client, je nach Rechten
  • Server hat u.U. root Zugriff !
  • d.h. Server im Netz gut absichern


Probleme mit 'rsync'

Path Syntax

  • rsync -avSAXHP source target/
- legt source in target an
  • rsync -avSAXHP source/ target/
- source wird nicht in target angelegt (Unterschied ist der Slash nach Source, ohne Leerzeichen)
  • Hilfe:
- Option -n (Dry Run) verwenden
- zeigt an, was 'rsync' ausführt, aber ohne eigentliche Ausführung

rsync überschreibt Files

  • keine Warnung
  • kann man abschalten, mit --backup
  • rsync soll automatisieren
- daher: testen, testen, testen, 3 x hinschauen

Prüfungen in 'rsync'

  • Größe und Datum der Dateien und Verzeichnisse
  • keine Prüfung des Inhalts von Files
- kann erzwungen werden, dauert dann aber sehr lange
- (-I, --ignore-times – don't skip files that match size and time)
- (-c, --checksum – skip based on checksum, not mod-time & size)
  • bei RAM Fehlern keine Kontrolle der Integrität
- eigene Prüfungen vorsehen
- 2 x Backup, MD5, diff u.a.
- RAM im PC mit memtest prüfen

rsnapshot

rsync der Oberklasse

  • mit Historie
  • über cron gesteuert,
- hourly, daily, monthly
  • flexibel

Einstellungen

  • 3 Dinge, die aufeinander abgestimmt sind
    • in rsnapshot.conf
- (retain, logfiles, backup Zeilen)
    • source folder und target folder
    • cronjobs einrichten, mit Werten aus 'retain' im Config-File aufrufen

Backupsoftware

eine Schicht mehr im System

  • weniger Kontrolle
  • auf Hersteller angewiesen
  • Updates?
  • Datenformat?
  • Historie
  • Preis, alle Kosten berücksichtigen, 'Total cost of ownership' beachten (TCO)
  • Wartung
  • Verschlüsselung?
  • SSH?
  • remote?
  • Entkopplung?
  • wir haben Linux, wir brauchen das nicht
- rsync, rsnapshot, diff, SSH, LUKS


KISS – 'keep it simple, stupid'

- The Art of Unix Programming
- The Art of Unix Usability
  • KISS: Keep It Simple, Stupid

NAS?

  • gleiche Probleme wie externe HD und einfaches copy/paste,
    • Probleme:
- welches Linux? Versionen? Updates? Modifiziert?
- wird Filesystem Standard eingehalten?
- Abhängigkeit vom Hersteller
- alle Nachteile der externen HD
- keine Trennung Client/Server,
- relativ teuer
- leistungsschwache CPU
- viele Linux Programme fehlen
- eigenes Linux nicht installierbar
- welche SSH Version, dto. rsync
  • als Fileserver ok
    • als Backup Server nicht


meine Lösung: Mini Server

preiswerter kleiner Server

  • mit Linux unserer Wahl
  • Open Source
  • austauschbar

SSH, rsync

  • Version identisch mit Client, da Linux mit allen Updates
  • Updates ok
    • LUKS
    • headless, ohne Monitor, Maus und Tastatur
    • ohne GUI
    • mehr Leistung
    • Wartung über SSH

es reicht ein alter PC

  • Stromverbrauch?
  • USB?
  • SATA?
  • kann auch eine VM sein
    • Backup über das Netz

LUKS

Zugriffssicherheit

  • mit Keyfile, für rsync
  • mit Passwort für eigenen Zugriff (bis zu 7 sind möglich)
- Passwort notieren
- LUKS Header sichern
- geht PW/Keyfile verloren, sind die Daten weg !

Brandschutz

  • mit LUKS kann man eine HD an eine unsichere Stelle auslagern
    • Inhalt der HD bleibt verborgen
  • beim Nachbarn, im Schließfach

LUKS ist immer letzte Stufe

  • einfacher Austausch der HD,
  • kein Schreddern der Daten

man spart

  • Tresor
  • bei Diebstahl ist nur der Neuwert der HD weg, nicht die Daten

die Endstation unseres Backups

  • extern,
  • austauschbar,
  • 2x pro Datensatz anlegen, besser 3x
- gelegentlich Bitvergleich machen, mit diff bzw. Prüfsummen
- bei heutigen Datenmengen sind Festplattenfehler nicht mehr sehr selten. (1 Bitfehler pro 10^14 Byte)

HDs rotieren, nach Plan

  • Austausch der Platten mit den externen Sicherungen

Link

SSH Installation

  • SSH installieren (auf allen beteiligten PCs)
- 'autossh'installieren
- erlaubt eine automatische Wiederaufnahme einer SSH Session nach einem Abbruch
  • # apt-get install ssh autossh
  • Server absichern
- /etc/ssh/sshd_config editieren
- Passwort-Login für alle Benutzer sperren
- Schlüsselpaar erzeugen und sichern ($ ssh-keygen)
- für jeden Client, der in das Backup eingebunden wird
  • öffentliche Schlüssel des Servers auf die Clients verteilen
  • privater Schlüssel verbleibt auf dem Server
  • öffentlicher Schlüssel kommt auf den Client (~/.ssh/authorized_keys)

eigenen Router am Server freischalten

  • Port 22 (bzw. der für SSH -R gewählte Port) muss zum Server-PC im eigenen Netz weitergeleitet werden
  • für Remote-Backup mit 'SSH -R'
  • Firewall im Router beachten, bzw. den SSH Port freischalten
  • Testsystem, nicht im eigenen Netz, bereit halten
- Test ob der Backup-Server aus dem Internet erreichbar ist

remote Router nicht freischalten

  • nicht nötig
- wegen SSH -R
  • oft ist dieser Router, in der Wohnung, in der der Remote-PC steht, nicht konfigurierbar
- Passwort 'vergessen'
- keine Hilfe in der Umgebung vorhanden



SSH -R

Client verbindet sich mit Server

  • ermöglicht Remote Zugriff per localhost
  • im Client:
    • /usr/bin/autossh -p xxxxx -q -f -N -R nnnnn:localhost:22 user@my_home_server
    • xxxxx = offener Port zum Server
    • nnnnn = nach SSH Ausführung ‚offener‘ Port im Server zum Client via 'localhost'
    • -q -f -N quiet, background process, no remote command
  • im Server:
    • Verbindung über 'loclahist' testen
    • autossh -p nnnnn client@localhost

Backup mit rsync via localhost

  • remote Daten abholen
  • rsync -avSAXH -e 'ssh -p nnnnn‘ client@localhost:/home/client/ /mnt/backup/
    • remote Zugriff: //client@localhost:/home/client///
    • lokaler Folder für das Backup: ///mnt/backup///


Rechner meldet sich beim Start am Server an

  • für jeden remote PC einen Account im Server
  • für jeden remote PC einen Port im Server
    • mit autossh Client-Anmeldung an einem Login Account im Server
      • in 'rc.local' des Client
  • 'rsync' auf Remote-User via localhost

in /etc/rc.local des Clients

  • SSH -R zum Server,
    • silent (-q -f -N)
      • 12345 ist Portweiterleitung über den Router zum Server
    • Verbindung von localhost zu localhost
- su -s /bin/sh user -c '/usr/bin/autossh -p 12345 -q -f -N -R 54321:localhost:22 login@yy.xxxxxx.de'
    • im Server Account:
- Fernwartung: ssh -p 54321 -X -C user@localhost
- Backup: rsync -avP -e 'ssh -p 54321' user@localhost:/home/user/ /mnt/user/


  • keine Portweiterleitung im Client Router
  • Ort des Client im Internet braucht nicht bekannt zu sein (!)

rsync kann unterbrochen werden

  • shutdown des Client
    • Skript auf dem Server → Test mit Ping, ob der Client wieder aktiv ist
    • rsync neu starten


alles zusammen, mit rsnapshot

rsync

  • remote Daten abholen,
  • erstes ‚rsync‘ braucht u.U. lange (einige Wochen, langsame DSL Verbindung)
  • SSH -R
- remote Zugriff per localhost

rsnapshot

  • ungeeignet für Remote-Rechner, die nicht immer laufen
- fixe cron zeiten
- einen Arbeitsbereich (Staging Area) anlegen, der mit rsync gefüllt wird
- rsnapshot holt mit cron die Daten dort ab
- ca. 30GB pro Remote PC

LUKS

  • als finale HD im Server
  • austauschbar
  • 2x, um zu vergleichen
  • ein Datensatz kann außerhalb gelagert werden
    • wöchentliche Rotation

Neue Anforderungen

  • einfaches rsync und rsnapshot reicht oft nicht

wartungsfrei für den Benutzer

  • flexible Zeiten, kein cronjob
  • einfacher HD Tausch , ohne mount/umount
  • keine 24/7 uptimes

vollautomatisch

  1. HD anstecken
  2. warten bis das ‚ok‘ kommt
  3. HD abziehen

Installation durch Admin

  • Konsolidierung der Daten
  • Konfiguration der Zeiten
  • testen
    • ab dann automatisch


Abgerufen von „http://www.lug-ottobrunn.de/mediawiki/index.php?title=Backup_allgemein&oldid=3143“