Linux.rsync: Unterschied zwischen den Versionen

Aktuelle Version vom 20. Juli 2023, 14:03 Uhr

rsync als Backup Hilfsmittel

rsync ist ein leistungsstarker Verzeichnis-Replikator
Ein "Server"-System, das Dateien zum Sichern anbietet aktiviert den Dienst "rsync.service".
- Dieses stellt gewisse Verzeichnissbereiche im "Nur-Lesen"- Modus zur Verfügung.
Ein rsync-Client (Das "Backup"-System) kann einen eigenen Verzeichnisbereich mit dem des Servers abgleichen.
- Nach dem ersten Kopierlauf werden nur noch Änderungen übertragen.
Am Ende des rsync-Prozesses sollten beide Verzeichnisbäume gleich sein (wenn der Server nicht ständig Änderungen macht, oder noch Dateien offen hält).

Best Practice

Im Netzwerk gibt es unterschiedliche Dienstleister die sicherungswürdige Dateien halten. Jeder Server / jede VM weis dabei am besten selbst welche Daten sicherungswürdig sind. Diese Daten werden in 2 Verzeichnisse "virtuell" gedoppelt und zusammengefasst. Bei den "Freigabenamen" in rsyncd.conf sollte dabei auch kein Wildwuchs erlaubt sein. Die "Server" dürfen den Backup-Clients nicht ihre eigene Verzeichnisstruktur aufzwingen, das macht Server-Migrationen schwierig. Das macht die Konfiguration der Backup-Clients schwierig. Es hat sich bewährt, dass jeder Server genau 2 "Freigabenamen" verwendet. Jeder Server stellt durch "Bind" Mounts sicher, dass die beiden "virtuellen" Verzeichnisse all jene Daten/Verzeichnisse beinhalten die wichtig sind. Alternativ durch "exclude" in der rsyncd.conf. Ich unterscheide 2 "Freigabenamen" (im Original [MODULE] genannt) - geordnet nach ihrer Wichtigkeit:

[major]

Wichtige Dateien, die in mehreren Versionen gesichert werden, so z.B. jeden Tag, in 10 Versionen, in Unterverzeichnissen von "0" bis "9"

[minor]

Weniger wichtige Dateien, die z.B. auf dem Server bereits auf einem RAID6-Verbund liegen, aber dennoch gesichert werden sollen, aber nicht stark versioniert wie bei "major".
Daten, die selbst Datensicherungen sind oder aus dem Internet abermals downloadbare Dateien (Setups, ISO-Images)

Band-Begriff

grosse Datenvolumen konnten früher nur auf Magnetbändern gehalten werden (1960-1980)
Backups konnten leicht erstellt werden, dazu wurde einfach ein Magnetband "offline" durch eine Kopierstation dupliziert
Später waren die Festplatten für das Tagesgeschäft - weil schneller - und die Bänder nur noch für die Datensicherung - weil billiger
Die Bänder wurden durch ein ausgeklügeltes System gewechselt, so dass man ein "Dienstagsband" oder ein "Vormonatsband" bereithielt
Bändern "0" bis "10" wurden z.B. rotierend eingesetzt
dieses Konzept wollen wir übernehmen, wobei aber ein Band einem Unterverzeichnis entspricht

Funktions-Hostnamen

Neben dem "eigenen" / "echten" Hostnamen sollten im Netz Funktions-Hostnamen als Alias vergeben werden, so dass wenn Idenditäten wechseln die Backup-Skripts weiterhin funktionieren:

#
# Der Webserver
# =============
#
# * Das Konfigurationsverzeichnis mit den virtuellen Hosts
# * Die Web-Content-Verzeichnisse
# * Die Server-Konfiguration
#
websrv

#
# Der Fileserver 
# ==============
#
# * Das Freigabeverzeichnis
#
nassrv

#
# Der Dienstserver
# ================
#
# * Die Daten des DHCPD-Server, Name-Server, NTP-Server usw.
# * Die Datenbanken eines DB-Servers
# * FTP Ablagen
netsrv

Backup-Hardware

Ein für Backups zuständiges System wird in einem gewissen Intervall per WOL aufgeweckt
- Alternativ via BMC "Power on" Linux.bmc
Dieses macht per rsync eine Verzeichnisreplikation und schaltet sich danach wieder ab!
Bevor er startet sollte er 2 Minuten warten, damit das skript unterbrochen werden kann
- Nicht immer ist ein "aktuelles" Backup hilfreich, es gibt Situationen bei den man das erstellen eines Backups verhindern sollte, insbesondere wenn ein Backup ein wertvolleres vorangehendes Backup überschreibt
Am Ende sollte eine Vollzugsemail gesendet werden und "poweroff" ausgeführt werden

Eines um sie alle zu binden

Erstelle auf dem zu sichernden Server ein Verzeichnis das wiederum alle Verzeichnisse enthält, die gesichert werden sollten
Mache das mit

mkdir mail
mount -B -r /var/mail mail

Vorbereitungen

Quell-Server

am Quell-Server (also der Sicherungsgeber) muss der Dienst rsyncd laufen
der Umfang der Angebote die dieser Dienst machen darf muss konfiguriert werden

joe /etc/rsyncd.conf

#
#
read only = true
use chroot = false
transfer logging = false
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
hosts allow = localhost 192.168.178.0/255.255.255.0
uid = nobody
gid = nobody

 # 
 # exclude
 #
 # Die Wichtigkeits-Unterscheidung zwischen "major" und "minor"
 # wird in diesem Beispiel durch exclude gelöst. In "Minor" werden
 # die "wichtigen" Verzeichnisse ausgeblendet, in "Major" werden die
 # unwichtigen Verzeichnisse ausgeblendet. Startpunkt (Wurzel) der 
 # Verzeichnisangaben ist immer der "path=" 
 #
 
[major]
 path = /srv/smb/ra6
 exclude = Datensicherung \
           Fotos \
           Karten \
           IT-Ordner

[minor]
 path = /srv/smb/ra6
 exclude = OrgaMon \
           Scanner \
           Arbeit

Den rsync-Dienst starten

systemctl enable rcsyncd
systemctl start rsyncd

Backup-System

rsync einfach mal ohne Parameter eingeben! muss gehen! Wenn nicht "rsnyc" installieren

 rsync

Oder sehe ich den rsync-Server?

 telnet <HostIP> 873    // oder
 rsync <HostName>:

es muss das Wort RSYNC erscheinen, ansonsten hört dir niemand zu! Oder eine Firewall verhindert die Verbindung.

Backup-Ziel-Verzeichnis vorbereiten:

Ich wollte ein backup von "heute" und eines von "gestern" haben. Also habe im in meinem /backup-Pfad zwei Unterverzeichnise gemacht: (immer chmod 0777 nur so zur Sicherheit)

backup/0 und backup/1

hat man also eine Datei heute ausversehen gelöscht ist sie im anderen Pfad sicher noch vorhanden. Es ist dem Konzept der alternierenden Bänder üblich, bei der man Datensicherungen mit 3 Bändern immer alternierend durchführt 0,1,2,0,1,2 usw.

Problembehebung

Zugriffsprobleme auf Quelldateien: Werden nicht alle Dateien übertragen sollten die Zugriffsrechte, mit denen rsync die Dateien auf dem Quellsystem lesen kann erhöht werden.

  uid = root
  gid = root

Datensicherungslauf automatisch mit cron starten

cron ist ein Dämon der zeitgesteuert Programme startet. Hierbei

Stelle sicher, dass cron als Dienst läuft (YaST2->System->runlevel editor)

jetzt noch /etc/crontab editieren, und folgenden Eintrag machen:

 #min    hour        daymo   month   daywk   usr   cmd
 0   9,12,15,18,22   *       *       *       root  /root/backup.sh

Datensicherungs Script backup.sh

das /root/backup.sh sollte so aussehen

 ------------------------------snip
 #!/bin/bash
 
 # 
 # Bestimmen hier, wieviele Backup-Sätze du bevorraten willst.
 # In meinem Fall "2", also heute und gestern, bei entsprechendem
 # Plattenplatz kann das aber auch 20 oder 30 sein!
 #
 ANZAHL_BAENDER=2
  
 #
 # Option "Major": Täglich wechselnde Verzeichnisse
 #
 # Hier wird eine alsolute Tag-Nummer ermittelt. Mit Hilfe des Modulo-
 # Operator erhöht man die entsprechende "Band-Nummer", beginnen bei
 # Null (0).
 #
 BAND=$((($(date +%s)/86400)%$ANZAHL_BAENDER))
 
 #
 # Option "Minor": Wöchentlich wechselnde Verzeichnisse
 #
 # Hier wird die Kalenderwoche ermittelt, Also eine Woche
 # lang wird alles in das selbe Verzeichnis gesichert.
 # Danach wird gewechselt und alle anderen "Bänder" bleiben
 # Wochenlang unberührt.
 #
 #BAND=$(($(date +%V)%$ANZAHL_BAENDER))
 
 # 
 # jetzt der rsync an sich bwlimit verhindert, dass und rsync die ganze Bandbreite des Netzes
 # wegnimmt.
 #
 rsync -av --delete --force --ignore-errors --bwlimit=200 192.168.115.92::srv/ /backup/$BAND 
  
 #
 # mit dem touch am Ende ist es leicht zu sehen wann der rsync
 # zuletzt "0", "1", ... bearbeitet hat. Damit kann man die
 # Aktualität einer Sicherung besser beurteilen
 #
 touch /backup/$BAND

 ------------------------------snap

kann man ja erst mal so per Hand aufrufen!

Autostart des ./etc/backup.sh

Auf dem Rechner, der automatisch durch WOL gestartet wird sollte das Backup Skript automatisch starten.
die Sicherung sollte erst starten wenn das Ziel bereit ist (warten auf den Mount)

mit systemd

#
# /etc/systemd/system/bak.service
#
[Unit]
Description=Datensicherung
RequiresMountsFor=/srv/smb/ra6

[Service]
WorkingDirectory=/root
ExecStartPre=/bin/sleep 40
ExecStart=/root/bak.sh 

[Install]
WantedBy=multi-user.target

Dir-Links mitsichern (KAPUTT)

Ziel: "Server" Verzeichnisse, die man via symbolischem Link komplett mitsichern will

Einstellungen auf dem Server

 rsyncd.conf
 
 #
 # das Nachfolgen der Symlinks ausserhalb des Sicherungsbaumes 
 # ist ja unser Wunsch. Dagegen 
 #
 use chroot = false

Einstellungen auf dem Backup-Client

Es gibt dafür zahlreiche Optionen

       -l, --links                 copy symlinks as symlinks
       -L, --copy-links            transform symlink into referent file/dir
           --copy-unsafe-links     only "unsafe" symlinks are transformed
           --safe-links            ignore symlinks that point outside the tree
           --munge-links           munge symlinks to make them safer
       -k, --copy-dirlinks         transform symlink to dir into referent dir
       -K, --keep-dirlinks         treat symlinked dir on receiver as dir

Konkrete Vorgehensweise

Mache Dir in deinem ".BACKUP-LIST" Verzeichnis einen Symbolischen Link auf ein "echtes" Verzeichnis, das Du sichern willst

 ln -s /var/lib/mysql mysql

Dir-Mounts (Bind) mitsichern

Leider funktionieren obige "symbolische Links nicht!!"
Man muss leider einen Mount machen!

mkdir g
mount --bind --read-only ../g g

systemd.mount

# /etc/systemd/system/srv-smb-ra6-.LIST-ftp.mount
#
#
[Unit]
Description=srv-smb-ra6-.LIST-ftp 

[Mount]
What=/srv/smb/ra6/ftp
Where=/srv/smb/ra6/.LIST/ftp
Type=none
Options=bind,ro

[Install]
WantedBy=remote-fs.target

Diagnose

less /proc/self/mountinfo | grep g

ACHTUNG: keinen * verwenden

die Quelle nicht mit "*" angeben, dadurch verbleiben Verzeichnisse auf dem Replikat. die auf dem Original längst gelöscht sind. Ausserdem können dadurch mit einem Punkt beginnende Dateien nicht gesehen werden. Einfach die Root Verzeichnisse angeben.

ACHTUNG: Rechte

Dateien, die durch samba selbst angelegt werden haben die richtigen Datei-Zugriffs-Attribute. Wenn aber z.B. Linux-Prozesse direkt auf dem share-Bereich operieren (nicht über die Samba Schicht) kann "owner" und "Atribuite" so formuliert sein, dass rsync die Datei nicht mal sieht. Dann wird sie NICHT mitgesichert. Besonders bei Datenbankfiles kann dies passieren (Firebird: firebird,firebird,-rw-rw--- !!!). Die kann man aber (ab und zu, oder auch im BAckup-Skript) mit dem Befehl (auf dem Server!)

chmod -R +r *

korrigieren.

noch'n Script

#!/bin/bash
echo "OrgaMon Backup startet";

sleep 300

ANZAHL_BAENDER=1
BAND=$((($(date +%s)/86400)%$ANZAHL_BAENDER))
OPTIONS="-avK --delete --force --ignore-errors --copy-unsafe-links"

mkdir "/srv/smb/freigabe/"$BAND
chmod 777 "/srv/smb/freigabe/"$BAND
touch "/srv/smb/freigabe/"$BAND

#
# /srv
#
DEST=/srv/smb/freigabe/$BAND/srv
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.90::srv/ $DEST

#
# /etc
#
DEST=/srv/smb/freigabe/$BAND/etc
mkdir $DEST
chmod 777 $DEST
rsync $OPTIONS 192.168.115.90::etc/ $DEST

#
# Log!
#
php /srv/smb/mail/phpmailer/mail.php

#
# Halt!
#
sleep 30
ethtool -s eth0 wol g
halt

Einen Remote Server sichern

Dabei muss rsyncd abgesichert werden

auf dem Server

# 
# /etc/rsyncd.conf
#
use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log

[module]
 path = /srv
 read only = yes
 list = no
 uid = root
 gid = root
 auth users = user
 secrets file = /etc/rsyncd.secrets

#
# /etc/rsyncd.secrets
#
user:pwd

die "secrets" können nur gelesen werden wenn die Rechte an der dieser Datei stimmen, sonst komm "auth error"

chmod 600 /etc/rsyncd.secrets

auf dem Backup-System

lege eine Passwort-Datei an, die enthält einfach nur das Passwort für den User, sonst nichts

****

setzte die Rechte so, dass niemand ausser root die Datei lesen kann

chmod 600 ../pwd

verweise rsync auf diese Datei

rsync -av --delete --force --ignore-errors --password-file=../pwd user@orgamon.org::mod/ .

Mailen, mit Hilfer der php-Mailer-Class

Diese Mail-Benachrichtigung wird mit Hilfe des "phpmailers" verwirklicht!

http://phpmailer.sourceforge.net/

<?php 

require("class.phpmailer.php"); 

$mail = new PHPMailer();

$mail->IsSMTP();                                   // send via SMTP
$mail->Host     = "raib90"; // SMTP servers
$mail->SMTPAuth = true;     // turn on SMTP authentication
$mail->Username = "mail-af1";  // SMTP username
$mail->Password = "*******"; // SMTP password

$mail->From     = "raib86@orgamon.de";
$mail->FromName = "Sicherungsserver";
$mail->AddAddress("me@orgamon.com");
$mail->AddCC("you@orgamon.com");
$mail->AddReplyTo("server@orgamon.org","Server Support");

$mail->WordWrap = 50;                              // set word wrap

$mail->Subject =  "-- rsync Lauf beendet --";
$mail->Body    =  round((((disk_free_space("/") / 1024) / 1024) / 1024)) .  " Giga-Byte(s) noch frei!"; 

if(!$mail->Send()) {
   echo "Message was not sent";
   echo "Mailer Error: " . $mail->ErrorInfo;
   exit;
} else
{
 echo "Message has been sent";
}
?>