Archiv:Generationsbackup mit rsync und rsnapshot im Netzwerk - Versionsgeschichte

Tommes: Tommes verschob die Seite Generationsbackup mit rsync und rsnapshot im Netzwerk nach Archiv:Generationsbackup mit rsync und rsnapshot im Netzwerk

2025-03-15T07:31:22Z

Tommes verschob die Seite Generationsbackup mit rsync und rsnapshot im Netzwerk nach Archiv:Generationsbackup mit rsync und rsnapshot im Netzwerk

← Nächstältere Version	Version vom 15. März 2025, 07:31 Uhr
(kein Unterschied)

imported>Johayek: /* Verschlüsseltes Backup via Netzwerk */

2015-01-30T06:26:58Z

Verschlüsseltes Backup via Netzwerk

← Nächstältere Version		Version vom 30. Januar 2015, 06:26 Uhr
Zeile 95:		Zeile 95:
	=== Verschlüsseltes Backup via Netzwerk ===		=== Verschlüsseltes Backup via Netzwerk ===
	Dazu müsst ihr Euch zuerst einen RSA Schlüssel erstellen (puttygen kann das, der Schlüssel sollte 1024 Bit lang sein und nicht länger!). Den Private Key sollte KEIN Passwort haben und gehört ins /root der DS, die rsnapshot startet.<br />		Dazu müsst ihr Euch zuerst einen RSA Schlüssel erstellen (puttygen kann das, der Schlüssel sollte 1024 Bit lang sein und nicht länger!). Den Private Key sollte KEIN Passwort haben und gehört ins /root der DS, die rsnapshot startet.<br />
	Der Public Key kommt in die Datei /root/.ssh/authorized_keys (wenn nicht vorhanden ~~anlgegen~~) auf der entfernten DS. Also diejenige auf die rsnapshot remote zugreift.		Der Public Key kommt in die Datei /root/.ssh/authorized_keys (wenn nicht vorhanden anlegen) auf der entfernten DS. Also diejenige auf die rsnapshot remote zugreift.

	Danach hat man die Möglichkeit rsync OHNE rsync Daemon zu nutzen d.h. in diesem Fall müssen eine Module für rsyncd erstellt werden, auch muss der rsyncd nicht laufen		Danach hat man die Möglichkeit rsync OHNE rsync Daemon zu nutzen d.h. in diesem Fall müssen eine Module für rsyncd erstellt werden, auch muss der rsyncd nicht laufen

imported>RudiWiesmayr am 24. Mai 2012 um 14:06 Uhr

2012-05-24T14:06:38Z

← Nächstältere Version		Version vom 24. Mai 2012, 14:06 Uhr
Zeile 1:		Zeile 1:
			[[Category:Backup and Recovery]]
	== Backups mit rsync und rsnapshot ==		== Backups mit rsync und rsnapshot ==
	Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generationen von Zuständen. Für den ersten Fall ist rsync das Mittel der Wahl, für den zweiten Fall verwendet man rsnapshot. rsnapshot verwendet im Hintergrund zwar auch rsync, kann aber durch trotzem Sohn-Vater-Grossvater Backups erstellen. Damit wird es möglich den Zustand zu (beinahe) jedem Zeitpunkt wieder herzustellen.		Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generationen von Zuständen. Für den ersten Fall ist rsync das Mittel der Wahl, für den zweiten Fall verwendet man rsnapshot. rsnapshot verwendet im Hintergrund zwar auch rsync, kann aber durch trotzem Sohn-Vater-Grossvater Backups erstellen. Damit wird es möglich den Zustand zu (beinahe) jedem Zeitpunkt wieder herzustellen.

imported>Raymond: /* Verschlüsseltes Backup via Netzwerk */

2011-08-01T13:44:33Z

Verschlüsseltes Backup via Netzwerk

← Nächstältere Version		Version vom 1. August 2011, 13:44 Uhr
Zeile 104:		Zeile 104:
	ssh_args -i /root/privateKey		ssh_args -i /root/privateKey
	</pre>		</pre>
	Dann noch die Backup Jobs in der ~~Konfig~~ anpassen		Dann noch die Backup Jobs in der Konfiguration anpassen
	<pre>		<pre>
	backup root@192.168.100.102:/volume1/photo/ localhost/		backup root@192.168.100.102:/volume1/photo/ localhost/
	</pre>		</pre>

imported>Raymond: /* Verschlüsseltes Backup via Netzwerk */ typo

2011-08-01T13:44:15Z

Verschlüsseltes Backup via Netzwerk: typo

← Nächstältere Version		Version vom 1. August 2011, 13:44 Uhr
Zeile 100:		Zeile 100:
	rsync -av -e "ssh -i /root/privateKey" root@IP_REMOTE_DS:/volume1/photo /volume1/backup/		rsync -av -e "ssh -i /root/privateKey" root@IP_REMOTE_DS:/volume1/photo /volume1/backup/
	</pre>		</pre>
	Damit auch rsnapshot die Backups via ssh machen kann, muss man die ~~Config~~ unter /opt/etc/rsnapshot.conf etwas anpassen		Damit auch rsnapshot die Backups via ssh machen kann, muss man die Konfiguration unter /opt/etc/rsnapshot.conf etwas anpassen
	<pre>		<pre>
	ssh_args -i /root/privateKey		ssh_args -i /root/privateKey

imported>Jahlives: /* rsync-Daemon einrichten */

2010-04-17T19:13:07Z

rsync-Daemon einrichten

← Nächstältere Version		Version vom 17. April 2010, 19:13 Uhr
Zeile 19:		Zeile 19:

	=== rsync-Daemon einrichten ===		=== rsync-Daemon einrichten ===
	Auf der Quelle muss also der rsync-Daemon laufen. Dieser Daemon stellt dann lokale Verzeichnisse als "Freigaben" zum Backup zur Verfügung. Zur Installation von rsync gibt es genügend Beispiele im Internet oder auch [[http://www.synology-wiki.de\|~~in userem~~ Wiki]]. Hier soll es um die Einrichtung des Daemons gehen.		Auf der Quelle muss also der rsync-Daemon laufen. Dieser Daemon stellt dann lokale Verzeichnisse als "Freigaben" zum Backup zur Verfügung. Zur Installation von rsync gibt es genügend Beispiele im Internet oder auch [http://www.synology-wiki.de\|hier im Wiki]. Hier soll es um die Einrichtung des Daemons gehen.
	==== rsyncd.conf ====		==== rsyncd.conf ====
	In dieser Datei, meist unter '''/opt/etc''' werden die Einstellungen für den rsync-Daemon vorgenommen.		In dieser Datei, meist unter '''/opt/etc''' werden die Einstellungen für den rsync-Daemon vorgenommen.

imported>Jahlives am 17. April 2010 um 19:04 Uhr

2010-04-17T19:04:14Z

← Nächstältere Version		Version vom 17. April 2010, 19:04 Uhr
Zeile 4:		Zeile 4:
	Im Folgenden soll es nicht um die Installation von [[Backup_über_RSync_auf_einen_angeschlossenen_Datenträger#Vorarbeiten\|rsync]] oder [[Rsnapshot#Installation\|rsnapshot]] gehen. Hier soll es darum gehen das Zusammenspiel von rsync und rsnapshot so zu optimieren, dass man auch bei Netzwerkbackups Generationen vorhalten kann.		Im Folgenden soll es nicht um die Installation von [[Backup_über_RSync_auf_einen_angeschlossenen_Datenträger#Vorarbeiten\|rsync]] oder [[Rsnapshot#Installation\|rsnapshot]] gehen. Hier soll es darum gehen das Zusammenspiel von rsync und rsnapshot so zu optimieren, dass man auch bei Netzwerkbackups Generationen vorhalten kann.
	=== Netzwerkbackup ===		=== Netzwerkbackup ===
	Es gibt eigentlich nur zwei Möglichkeiten mit diesen beiden Programmen zusammen ein Backup via Netzwerk zu erstellen. Die "grosse Einschränkung" ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. rsnapshot kann Backups nicht auf entfernte Ziele speichern, das Backupziel muss also immer lokal sein		Es gibt eigentlich nur zwei Möglichkeiten mit diesen beiden Programmen zusammen ein Backup via Netzwerk zu erstellen. Die "grosse Einschränkung" ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. rsnapshot kann Backups nicht auf entfernte Ziele speichern, das '''Backupziel muss also immer lokal''' sein
	Mit dieser Einschränkung gibt es also nur zwei Möglichkeiten:		Mit dieser Einschränkung gibt es also nur zwei Möglichkeiten:
	# lokales Backup mit rsnapshot und dann das Archiv mit rync auf den Backupserver		# lokales Backup mit rsnapshot und dann das Archiv mit rync auf den Backupserver
Zeile 13:		Zeile 13:

	Bei 2) ist das Ganze etwas schwieriger einzurichten und ausserdem birgt es gewisse Sicherheitsrisiken. In einem LAN hinter einem Router mit aktivierter Firewall auf der DS und gesetzten IP-Beschränkungen beim Backupzugriff kann man diese Risiken jedoch vernachlässigen. Das Problem ist, dass auf der Backupquelle rsync im Daemonmodus laufen muss. Dieser Dämon stellt die Daten für das Backup seitens rsnapshot zur Verfügung. Das Risiko ist, dass der Benutzer unter dem der Daemon läuft mindestens lesenden Zugriff auf alle zu backupenden Daten haben muss		Bei 2) ist das Ganze etwas schwieriger einzurichten und ausserdem birgt es gewisse Sicherheitsrisiken. In einem LAN hinter einem Router mit aktivierter Firewall auf der DS und gesetzten IP-Beschränkungen beim Backupzugriff kann man diese Risiken jedoch vernachlässigen. Das Problem ist, dass auf der Backupquelle rsync im Daemonmodus laufen muss. Dieser Dämon stellt die Daten für das Backup seitens rsnapshot zur Verfügung. Das Risiko ist, dass der Benutzer unter dem der Daemon läuft mindestens lesenden Zugriff auf alle zu backupenden Daten haben muss
	Gerade für Systemfiles und Homeverzeichnisse der User kommt eigentlich fast nur root ist Frage! root ist auch wunderbar bequem weil man damit alle Rechte hat jede Datei zu kopieren.		Gerade für Systemfiles und Homeverzeichnisse der User kommt eigentlich fast nur '''root''' ist Frage! root ist auch wunderbar bequem weil man damit alle Rechte hat jede Datei zu kopieren.
	In diesem Fall müssen aber sehr restriktive IP Einschränkungen für den Zugriff auf den rsync-Daemon gesetzt werden. Bei mir darf einzig und alleine die entfernte Backupmaschine (dort wird der rsnapshot aufgerufen) auf den rsync-Daemon zugreifen		In diesem Fall müssen aber sehr restriktive IP Einschränkungen für den Zugriff auf den rsync-Daemon gesetzt werden. Bei mir darf einzig und alleine die entfernte Backupmaschine (dort wird der rsnapshot aufgerufen) auf den rsync-Daemon zugreifen

Zeile 21:		Zeile 21:
	Auf der Quelle muss also der rsync-Daemon laufen. Dieser Daemon stellt dann lokale Verzeichnisse als "Freigaben" zum Backup zur Verfügung. Zur Installation von rsync gibt es genügend Beispiele im Internet oder auch [[http://www.synology-wiki.de\|in userem Wiki]]. Hier soll es um die Einrichtung des Daemons gehen.		Auf der Quelle muss also der rsync-Daemon laufen. Dieser Daemon stellt dann lokale Verzeichnisse als "Freigaben" zum Backup zur Verfügung. Zur Installation von rsync gibt es genügend Beispiele im Internet oder auch [[http://www.synology-wiki.de\|in userem Wiki]]. Hier soll es um die Einrichtung des Daemons gehen.
	==== rsyncd.conf ====		==== rsyncd.conf ====
	In dieser Datei, meist unter /opt/etc werden die Einstellungen für den rsync-Daemon vorgenommen.		In dieser Datei, meist unter '''/opt/etc''' werden die Einstellungen für den rsync-Daemon vorgenommen.
	===== global =====		===== global =====
	<pre>		<pre>
Zeile 48:		Zeile 48:
	</pre>		</pre>
	Diese Parameter einer "Freigabe" sollten selbsterklärend sein. chroot würde sicherstellen, dass das angegebene Verzeichnis unter path nicht verlassen werden könnte. Nur bringt das nicht viel wenn des path Verzeichnis / ist ;-) <br />		Diese Parameter einer "Freigabe" sollten selbsterklärend sein. chroot würde sicherstellen, dass das angegebene Verzeichnis unter path nicht verlassen werden könnte. Nur bringt das nicht viel wenn des path Verzeichnis / ist ;-) <br />
	Auf jeden Fall muss eine solche root Freigabe nur lesbar sein. Die IPs unter hosts allow definieren welche IPs überhaupt auf die Freigabe zugreifen dürfen. Nicht aufgeführte IPs werden durch hosts deny = * geblockt. <br />		Auf jeden Fall muss eine solche root Freigabe '''nur''' lesbar sein. Die IPs unter hosts allow definieren welche IPs überhaupt auf die Freigabe zugreifen dürfen. Nicht aufgeführte IPs werden durch '''hosts deny = '''* geblockt. <br />
	Man kann auch eine Userauthentifizierung mit Username und Passwort pro Freigabe machen, nur gibt es keine Möglichkeit dem rsnapshot ein Passwort mitzugeben. Dieses würde in diesem Fall vom User auf der Konsole abgefragt und damit könnte man es nicht in einen cronjob verwenden.		Man kann auch eine Userauthentifizierung mit Username und Passwort pro Freigabe machen, nur gibt es keine Möglichkeit dem rsnapshot ein Passwort mitzugeben. Dieses würde in diesem Fall vom User auf der Konsole abgefragt und damit könnte man es nicht in einen cronjob verwenden.
	==== Testen ====		==== Testen ====
Zeile 55:		Zeile 55:
	rsync localhost::root		rsync localhost::root
	</pre>		</pre>
	Damit sollte Euch der Inhalt der Freigabe root angezeigt werden, das root Verzeichnis also.		Damit sollte Euch der Inhalt der Freigabe '''root''' angezeigt werden, das root Verzeichnis also.

	=== rsnapshot einrichten ===		=== rsnapshot einrichten ===
Zeile 63:		Zeile 63:

	==== rsnapshot.conf ====		==== rsnapshot.conf ====
	Diese Datei liegt ebenfalls unter /opt/etc. Am Ende dieser Datei werden die Backupjob definiert. Der Aufbau eines Jobs ist einfach		Diese Datei liegt ebenfalls unter '''/opt/etc'''. Am Ende dieser Datei werden die Backupjob definiert. Der Aufbau eines Jobs ist einfach
	<pre>		<pre>
	backup SOURCE TARGET		backup SOURCE TARGET
Zeile 76:		Zeile 76:
	backup 192.168.1.100::root/volume1/web/ webserver/		backup 192.168.1.100::root/volume1/web/ webserver/
	</pre>		</pre>
	Oben habe ich bei den Quellen nach der IP und den :: den Namen des rsync Moduls angegeben. Danach folgen ganz normale Pfadangaben innerhalb des Moduls. Der abschliessende Slash bei der Quelle sorgt dafür, dass nur Dateien und Unterverzeichnisse kopiert werden, nicht aber das angegebene Verzeichnis selber. Im Backup mailserver kommen also gleich die Dateien und Verzeichnisse der Quelle. Ohne Slash würde unter mailserver zuerst ein Verzeichnnis postfix kommen und erst dann der Inhalt. Da es sich bei mailserver und webserver um lokale Verzeichnisse innerhalb des Backuparchivs handelt müssen diese auf jeden Fall mit einem Slash am Ende angegeben werden.		Oben habe ich bei den Quellen nach der IP und den :: den Namen des rsync Moduls angegeben. Danach folgen ganz normale Pfadangaben innerhalb des Moduls. Der abschliessende Slash bei der Quelle sorgt dafür, dass nur Dateien und Unterverzeichnisse kopiert werden, nicht aber das angegebene Verzeichnis selber. Im Backup mailserver kommen also gleich die Dateien und Verzeichnisse der Quelle. Ohne Slash würde unter mailserver zuerst ein Verzeichnnis postfix kommen und erst dann der Inhalt. Da es sich bei mailserver und webserver um lokale Verzeichnisse innerhalb des Backuparchivs handelt '''müssen''' diese auf jeden Fall mit einem Slash am Ende angegeben werden.
	==== Testen ====		==== Testen ====
	Bevor man jetzt einen Backupjob startet sollte man die rsnapshot Konfiguration testen		Bevor man jetzt einen Backupjob startet sollte man die rsnapshot Konfiguration testen

imported>Jahlives: /* Backups mit rsync und rsnapshot */

2010-04-17T00:07:07Z

Backups mit rsync und rsnapshot

← Nächstältere Version		Version vom 17. April 2010, 00:07 Uhr
Zeile 2:		Zeile 2:
	Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generationen von Zuständen. Für den ersten Fall ist rsync das Mittel der Wahl, für den zweiten Fall verwendet man rsnapshot. rsnapshot verwendet im Hintergrund zwar auch rsync, kann aber durch trotzem Sohn-Vater-Grossvater Backups erstellen. Damit wird es möglich den Zustand zu (beinahe) jedem Zeitpunkt wieder herzustellen.		Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generationen von Zuständen. Für den ersten Fall ist rsync das Mittel der Wahl, für den zweiten Fall verwendet man rsnapshot. rsnapshot verwendet im Hintergrund zwar auch rsync, kann aber durch trotzem Sohn-Vater-Grossvater Backups erstellen. Damit wird es möglich den Zustand zu (beinahe) jedem Zeitpunkt wieder herzustellen.

	Im Folgenden soll es nicht um die Installation von rsync oder rsnapshot gehen~~. Dazu gibt es genügend Hilfen (z.B. http://www.synology-wiki.de) im Internet~~. Hier soll es darum gehen das Zusammenspiel von rsync und rsnapshot so zu optimieren, dass man auch bei Netzwerkbackups Generationen vorhalten kann.		Im Folgenden soll es nicht um die Installation von [[Backup_über_RSync_auf_einen_angeschlossenen_Datenträger#Vorarbeiten\|rsync]] oder [[Rsnapshot#Installation\|rsnapshot]] gehen. Hier soll es darum gehen das Zusammenspiel von rsync und rsnapshot so zu optimieren, dass man auch bei Netzwerkbackups Generationen vorhalten kann.

	=== Netzwerkbackup ===		=== Netzwerkbackup ===
	Es gibt eigentlich nur zwei Möglichkeiten mit diesen beiden Programmen zusammen ein Backup via Netzwerk zu erstellen. Die "grosse Einschränkung" ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. ~~__rsnapshot~~ kann Backups nicht auf entfernte Ziele speichern, das Backupziel muss also immer lokal ~~sein__~~		Es gibt eigentlich nur zwei Möglichkeiten mit diesen beiden Programmen zusammen ein Backup via Netzwerk zu erstellen. Die "grosse Einschränkung" ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. rsnapshot kann Backups nicht auf entfernte Ziele speichern, das Backupziel muss also immer lokal sein
	Mit dieser Einschränkung gibt es also nur zwei Möglichkeiten:		Mit dieser Einschränkung gibt es also nur zwei Möglichkeiten:
	# lokales Backup mit rsnapshot und dann das Archiv mit rync auf den Backupserver		# lokales Backup mit rsnapshot und dann das Archiv mit rync auf den Backupserver
Zeile 13:		Zeile 12:
	Bei 1) ist jedoch das Problem, dass viel zu viele Daten über das Netzwerk geschickt werden. Dies liegt am Konzept von rsnapshot bei der Erstellung des Backuparchivs. Wenn ein neuer Snapshot erstellt wird dann werden die bereits bestehenden Snapshots nach hinten gerückt im Archiv. Nicht geänderte Dateien werden nicht erneut kopiert sondern auf die "Originale" im älteren Snapshot verlinkt. Eigentlich enstehen dabei fast keine neuen Daten und doch wird rsnapshot eine riesige Datenmenge übertragen: Snapshots werden immer so nummeriert XXX.0 XXX.1 Dabei ist .0 immer der aktuellste Snapshot. Beim Anlegen eines neuen Snapshots wird das bereits existierende XXX.0 zu XXX.1 umbenannt und dann mit XXX.0 der aktuelle Snapshot angelegt. In XXX.0 befinden sich sehr wenige Daten, weil die nicht geänderten Daten nur als Links auf die Daten in XXX.1 angelegt werden. rsync sieht aber das aber so, dass hier ein geändertes Verzeichnis (XXX.0) und ein neues (XXX.1) vorliegt. Et voilà es werden beide wieder kopiert (gerade bei statischen Daten wie DVD- oder CD Images oder Photos ist das tödlich)		Bei 1) ist jedoch das Problem, dass viel zu viele Daten über das Netzwerk geschickt werden. Dies liegt am Konzept von rsnapshot bei der Erstellung des Backuparchivs. Wenn ein neuer Snapshot erstellt wird dann werden die bereits bestehenden Snapshots nach hinten gerückt im Archiv. Nicht geänderte Dateien werden nicht erneut kopiert sondern auf die "Originale" im älteren Snapshot verlinkt. Eigentlich enstehen dabei fast keine neuen Daten und doch wird rsnapshot eine riesige Datenmenge übertragen: Snapshots werden immer so nummeriert XXX.0 XXX.1 Dabei ist .0 immer der aktuellste Snapshot. Beim Anlegen eines neuen Snapshots wird das bereits existierende XXX.0 zu XXX.1 umbenannt und dann mit XXX.0 der aktuelle Snapshot angelegt. In XXX.0 befinden sich sehr wenige Daten, weil die nicht geänderten Daten nur als Links auf die Daten in XXX.1 angelegt werden. rsync sieht aber das aber so, dass hier ein geändertes Verzeichnis (XXX.0) und ein neues (XXX.1) vorliegt. Et voilà es werden beide wieder kopiert (gerade bei statischen Daten wie DVD- oder CD Images oder Photos ist das tödlich)

	Bei 2) ist das Ganze etwas schwieriger einzurichten und ausserdem birgt es gewisse Sicherheitsrisiken. In einem LAN hinter einem Router mit aktivierter Firewall auf der DS und gesetzten IP-Beschränkungen beim Backupzugriff kann man diese Risiken jedoch vernachlässigen. Das Problem ist, dass auf der Backupquelle rsync im Daemonmodus laufen muss. Dieser Dämon stellt die Daten für das Backup seitens rsnapshot zur Verfügung. ~~__Das~~ Risiko ist, dass der Benutzer unter dem der Daemon läuft mindestens lesenden Zugriff auf alle zu backupenden Daten haben ~~muss__~~		Bei 2) ist das Ganze etwas schwieriger einzurichten und ausserdem birgt es gewisse Sicherheitsrisiken. In einem LAN hinter einem Router mit aktivierter Firewall auf der DS und gesetzten IP-Beschränkungen beim Backupzugriff kann man diese Risiken jedoch vernachlässigen. Das Problem ist, dass auf der Backupquelle rsync im Daemonmodus laufen muss. Dieser Dämon stellt die Daten für das Backup seitens rsnapshot zur Verfügung. Das Risiko ist, dass der Benutzer unter dem der Daemon läuft mindestens lesenden Zugriff auf alle zu backupenden Daten haben muss
	Gerade für Systemfiles und Homeverzeichnisse der User kommt eigentlich fast nur root ist Frage! root ist auch wunderbar bequem weil man damit alle Rechte hat jede Datei zu kopieren.		Gerade für Systemfiles und Homeverzeichnisse der User kommt eigentlich fast nur root ist Frage! root ist auch wunderbar bequem weil man damit alle Rechte hat jede Datei zu kopieren.
	In diesem Fall müssen aber sehr restriktive IP Einschränkungen für den Zugriff auf den rsync-Daemon gesetzt werden. Bei mir darf einzig und alleine die entfernte Backupmaschine (dort wird der rsnapshot aufgerufen) auf den rsync-Daemon zugreifen		In diesem Fall müssen aber sehr restriktive IP Einschränkungen für den Zugriff auf den rsync-Daemon gesetzt werden. Bei mir darf einzig und alleine die entfernte Backupmaschine (dort wird der rsnapshot aufgerufen) auf den rsync-Daemon zugreifen
Zeile 49:		Zeile 48:
	</pre>		</pre>
	Diese Parameter einer "Freigabe" sollten selbsterklärend sein. chroot würde sicherstellen, dass das angegebene Verzeichnis unter path nicht verlassen werden könnte. Nur bringt das nicht viel wenn des path Verzeichnis / ist ;-) <br />		Diese Parameter einer "Freigabe" sollten selbsterklärend sein. chroot würde sicherstellen, dass das angegebene Verzeichnis unter path nicht verlassen werden könnte. Nur bringt das nicht viel wenn des path Verzeichnis / ist ;-) <br />
	Auf jeden Fall muss eine solche root Freigabe ~~__nur__~~ lesbar sein. Die IPs unter hosts allow definieren welche IPs überhaupt auf die Freigabe zugreifen dürfen. Nicht aufgeführte IPs werden durch hosts deny = * geblockt. <br />		Auf jeden Fall muss eine solche root Freigabe nur lesbar sein. Die IPs unter hosts allow definieren welche IPs überhaupt auf die Freigabe zugreifen dürfen. Nicht aufgeführte IPs werden durch hosts deny = * geblockt. <br />
	Man kann auch eine Userauthentifizierung mit Username und Passwort pro Freigabe machen, nur gibt es keine Möglichkeit dem rsnapshot ein Passwort mitzugeben. Dieses würde in diesem Fall vom User auf der Konsole abgefragt und damit könnte man es nicht in einen cronjob verwenden.		Man kann auch eine Userauthentifizierung mit Username und Passwort pro Freigabe machen, nur gibt es keine Möglichkeit dem rsnapshot ein Passwort mitzugeben. Dieses würde in diesem Fall vom User auf der Konsole abgefragt und damit könnte man es nicht in einen cronjob verwenden.
	==== Testen ====		==== Testen ====
Zeile 60:		Zeile 59:
	=== rsnapshot einrichten ===		=== rsnapshot einrichten ===
	Im Folgenden noch kurz wie man die Backupquellen in der rsnapshot Konfiguration angibt, damit rsnapshot korrekt backupen kann. <br />		Im Folgenden noch kurz wie man die Backupquellen in der rsnapshot Konfiguration angibt, damit rsnapshot korrekt backupen kann. <br />
	~~<html>~~
	<span style="color:red">Wichtig ist, dass rsnapshot im Gegensatz zu rsync nicht auf der Backupquelle sondern dem Backupziel laufen muss.</span>		<span style="color:red">Wichtig ist, dass rsnapshot im Gegensatz zu rsync nicht auf der Backupquelle sondern dem Backupziel laufen muss.</span>
	~~</html>~~
	==== rsnapshot.conf ====		==== rsnapshot.conf ====
	Diese Datei liegt ebenfalls unter /opt/etc. Am Ende dieser Datei werden die Backupjob definiert. Der Aufbau eines Jobs ist einfach		Diese Datei liegt ebenfalls unter /opt/etc. Am Ende dieser Datei werden die Backupjob definiert. Der Aufbau eines Jobs ist einfach
Zeile 68:		Zeile 67:
	backup SOURCE TARGET		backup SOURCE TARGET
	</pre>		</pre>
	~~<html>~~
	<span style="color:red;">Wichtig ist, dass keine Leerzeichen sondern TABS verwendet werden müssen, sonst hagelt es Fehlermeldungen. Auch wichtig ist, dass es nicht das gleiche ist ob Verzeichnisse mit einem abschliessenden Slash (/) angegeben werden oder ohne. Lokale Verzeichnisse müssen immer einen abschliessenden Slash haben!</span>		<span style="color:red;">Wichtig ist, dass keine Leerzeichen sondern TABS verwendet werden müssen, sonst hagelt es Fehlermeldungen. Auch wichtig ist, dass es nicht das gleiche ist ob Verzeichnisse mit einem abschliessenden Slash (/) angegeben werden oder ohne. Lokale Verzeichnisse müssen immer einen abschliessenden Slash haben!</span>
	~~</html>~~

	Wenn man jetzt also vom rsync Daemon der entfernten Maschine etwas abholen will, dann gibt man das z.B. so an		Wenn man jetzt also vom rsync Daemon der entfernten Maschine etwas abholen will, dann gibt man das z.B. so an

imported>Jahlives: Die Seite wurde neu angelegt: „== Backups mit rsync und rsnapshot == Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generatione…“

2010-04-17T00:01:17Z

Die Seite wurde neu angelegt: „== Backups mit rsync und rsnapshot == Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generatione…“

Neue Seite

== Backups mit rsync und rsnapshot ==
Bei Backups auf der DS stellt sich immer die Frage, welchen Weg man gehen will: Nur den aktuellsten Zustand oder Generationen von Zuständen. Für den ersten Fall ist rsync das Mittel der Wahl, für den zweiten Fall verwendet man rsnapshot. rsnapshot verwendet im Hintergrund zwar auch rsync, kann aber durch trotzem Sohn-Vater-Grossvater Backups erstellen. Damit wird es möglich den Zustand zu (beinahe) jedem Zeitpunkt wieder herzustellen.

Im Folgenden soll es nicht um die Installation von rsync oder rsnapshot gehen. Dazu gibt es genügend Hilfen (z.B. http://www.synology-wiki.de) im Internet. Hier soll es darum gehen das Zusammenspiel von rsync und rsnapshot so zu optimieren, dass man auch bei Netzwerkbackups Generationen vorhalten kann.

=== Netzwerkbackup ===
Es gibt eigentlich nur zwei Möglichkeiten mit diesen beiden Programmen zusammen ein Backup via Netzwerk zu erstellen. Die "grosse Einschränkung" ist, dass rsnapshot immer auf jener Maschine laufen muss wo auch die Daten gespeichert werden. __rsnapshot kann Backups nicht auf entfernte Ziele speichern, das **Backupziel muss also immer lokal** sein__
Mit dieser Einschränkung gibt es also nur zwei Möglichkeiten:
# lokales Backup mit rsnapshot und dann das Archiv mit rync auf den Backupserver
# rsnapshot auf der Backupmaschine starten und die Daten von der Backupquelle abholen
Grundsätzlich funzen beide Möglichkeiten.

Bei 1) ist jedoch das Problem, dass viel zu viele Daten über das Netzwerk geschickt werden. Dies liegt am Konzept von rsnapshot bei der Erstellung des Backuparchivs. Wenn ein neuer Snapshot erstellt wird dann werden die bereits bestehenden Snapshots nach hinten gerückt im Archiv. Nicht geänderte Dateien werden nicht erneut kopiert sondern auf die "Originale" im älteren Snapshot verlinkt. Eigentlich enstehen dabei fast keine neuen Daten und doch wird rsnapshot eine riesige Datenmenge übertragen: Snapshots werden immer so nummeriert XXX.0 XXX.1 Dabei ist .0 immer der aktuellste Snapshot. Beim Anlegen eines neuen Snapshots wird das bereits existierende XXX.0 zu XXX.1 umbenannt und dann mit XXX.0 der aktuelle Snapshot angelegt. In XXX.0 befinden sich sehr wenige Daten, weil die nicht geänderten Daten nur als Links auf die Daten in XXX.1 angelegt werden. rsync sieht aber das aber so, dass hier ein geändertes Verzeichnis (XXX.0) und ein neues (XXX.1) vorliegt. Et voilà es werden beide wieder kopiert (gerade bei statischen Daten wie DVD- oder CD Images oder Photos ist das tödlich)

Bei 2) ist das Ganze etwas schwieriger einzurichten und ausserdem birgt es gewisse Sicherheitsrisiken. In einem LAN hinter einem Router mit aktivierter Firewall auf der DS und gesetzten IP-Beschränkungen beim Backupzugriff kann man diese Risiken jedoch vernachlässigen. Das Problem ist, dass auf der Backupquelle rsync im Daemonmodus laufen muss. Dieser Dämon stellt die Daten für das Backup seitens rsnapshot zur Verfügung. __Das Risiko ist, dass der Benutzer unter dem der Daemon läuft mindestens lesenden Zugriff auf alle zu backupenden Daten haben muss__
Gerade für Systemfiles und Homeverzeichnisse der User kommt eigentlich fast nur **root** ist Frage! root ist auch wunderbar bequem weil man damit alle Rechte hat jede Datei zu kopieren.
In diesem Fall müssen aber sehr restriktive IP Einschränkungen für den Zugriff auf den rsync-Daemon gesetzt werden. Bei mir darf einzig und alleine die entfernte Backupmaschine (dort wird der rsnapshot aufgerufen) auf den rsync-Daemon zugreifen

Trotzdem geht es im folgenden nur um 2), denn 1) ist aus den genannten Gründen schlicht vollkommen ungeeignet.

=== rsync-Daemon einrichten ===
Auf der Quelle muss also der rsync-Daemon laufen. Dieser Daemon stellt dann lokale Verzeichnisse als "Freigaben" zum Backup zur Verfügung. Zur Installation von rsync gibt es genügend Beispiele im Internet oder auch [[http://www.synology-wiki.de|in userem Wiki]]. Hier soll es um die Einrichtung des Daemons gehen.
==== rsyncd.conf ====
In dieser Datei, meist unter **/opt/etc** werden die Einstellungen für den rsync-Daemon vorgenommen.
===== global =====
<pre>
uid = root
gid = root
</pre>
Hier wird festgelegt unter welcher UserID und GruppenID der Daemon Prozess laufen soll.
<pre>
max connections = 5
syslog facility = local3
</pre>
Legt die maximale Anzahl erlaubter gleichzietiger Verbindungen fest und definiert wo rsync in den syslog schreiben soll.
<pre>
pid file = /var/run/rsyncd.pid
secrets file = /opt/etc/rsyncd.secrets
</pre>
Legen das pid (process ID) File fest und definiert zudem wo das Authentifizierungsfile von rsyncd liegt.
===== Freigabe =====
<pre>
[root]
use chroot = no
path = /
read only = yes
hosts allow = 192.168.1.101 127.0.0.1
hosts deny = *
</pre>
Diese Parameter einer "Freigabe" sollten selbsterklärend sein. chroot würde sicherstellen, dass das angegebene Verzeichnis unter path nicht verlassen werden könnte. Nur bringt das nicht viel wenn des path Verzeichnis / ist ;-) 
Auf jeden Fall muss eine solche root Freigabe **__nur__** lesbar sein. Die IPs unter hosts allow definieren welche IPs überhaupt auf die Freigabe zugreifen dürfen. Nicht aufgeführte IPs werden durch **hosts deny = *** geblockt. 
Man kann auch eine Userauthentifizierung mit Username und Passwort pro Freigabe machen, nur gibt es keine Möglichkeit dem rsnapshot ein Passwort mitzugeben. Dieses würde in diesem Fall vom User auf der Konsole abgefragt und damit könnte man es nicht in einen cronjob verwenden.
==== Testen ====
Nach Anpassung des rsyncd.conf Files muss der rsyncd neugestartet werden. Danach kann man die Konfiguration so testen
<pre>
rsync localhost::root
</pre>
Damit sollte Euch der Inhalt der Freigabe **root** angezeigt werden, das root Verzeichnis also.

=== rsnapshot einrichten ===
Im Folgenden noch kurz wie man die Backupquellen in der rsnapshot Konfiguration angibt, damit rsnapshot korrekt backupen kann. 
<html>
Wichtig ist, dass rsnapshot im Gegensatz zu rsync nicht auf der Backupquelle sondern dem Backupziel laufen muss.
</html>
==== rsnapshot.conf ====
Diese Datei liegt ebenfalls unter **/opt/etc**. Am Ende dieser Datei werden die Backupjob definiert. Der Aufbau eines Jobs ist einfach
<pre>
backup SOURCE TARGET
</pre>
<html>
Wichtig ist, dass keine Leerzeichen sondern TABS verwendet werden müssen, sonst hagelt es Fehlermeldungen. Auch wichtig ist, dass es nicht das gleiche ist ob Verzeichnisse mit einem abschliessenden Slash (/) angegeben werden oder ohne. Lokale Verzeichnisse müssen immer einen abschliessenden Slash haben!
</html>

Wenn man jetzt also vom rsync Daemon der entfernten Maschine etwas abholen will, dann gibt man das z.B. so an
<pre>
backup 192.168.1.99::root/var/spool/postfix/ mailserver/
backup 192.168.1.100::root/volume1/web/ webserver/
</pre>
Oben habe ich bei den Quellen nach der IP und den :: den Namen des rsync Moduls angegeben. Danach folgen ganz normale Pfadangaben innerhalb des Moduls. Der abschliessende Slash bei der Quelle sorgt dafür, dass nur Dateien und Unterverzeichnisse kopiert werden, nicht aber das angegebene Verzeichnis selber. Im Backup mailserver kommen also gleich die Dateien und Verzeichnisse der Quelle. Ohne Slash würde unter mailserver zuerst ein Verzeichnnis postfix kommen und erst dann der Inhalt. Da es sich bei mailserver und webserver um lokale Verzeichnisse innerhalb des Backuparchivs handelt **müssen** diese auf jeden Fall mit einem Slash am Ende angegeben werden.
==== Testen ====
Bevor man jetzt einen Backupjob startet sollte man die rsnapshot Konfiguration testen
<pre>
rsnapshot configtest
</pre>
Wenn dieser Test OK ergibt, dann kann man mal eine "Simulation" des Backups starten. Dabei gibt rsnapshot aus welche Quellen er holen und wo er sie lokal ablegen würde. Ausserdem zeigt er die Befehle an die ausgeführt werden. Dies kann man mittels
<pre>
rsnapshot -t hourly
</pre>
erreichen. 
Wenn auch jetzt noch alles gut ausschaut, kann man das initiale Backup dann mit
<pre>
rsnapshot hourly
</pre>
auslösen.
=== Verschlüsseltes Backup via Netzwerk ===
Dazu müsst ihr Euch zuerst einen RSA Schlüssel erstellen (puttygen kann das, der Schlüssel sollte 1024 Bit lang sein und nicht länger!). Den Private Key sollte KEIN Passwort haben und gehört ins /root der DS, die rsnapshot startet. 
Der Public Key kommt in die Datei /root/.ssh/authorized_keys (wenn nicht vorhanden anlgegen) auf der entfernten DS. Also diejenige auf die rsnapshot remote zugreift.

Danach hat man die Möglichkeit rsync OHNE rsync Daemon zu nutzen d.h. in diesem Fall müssen eine Module für rsyncd erstellt werden, auch muss der rsyncd nicht laufen
<pre>
rsync -av -e "ssh -i /root/privateKey" root@IP_REMOTE_DS:/volume1/photo /volume1/backup/
</pre>
Damit auch rsnapshot die Backups via ssh machen kann, muss man die Config unter /opt/etc/rsnapshot.conf etwas anpassen
<pre>
ssh_args -i /root/privateKey
</pre>
Dann noch die Backup Jobs in der Konfig anpassen
<pre>
backup root@192.168.100.102:/volume1/photo/ localhost/
</pre>