pedant
Goto Top

Bash-Skript mit rsync (Anfänger bittet um Hilfe)

Hallo,

unter Windows fühle ich mich zuhause, doch was Linux angeht bin ich recht unerfahren.
Jetzt möchte ich eine Aufgabe mit einem bash-Skript lösen.
Da ich, wie gesagt, von Linux kaum eine Ahnung habe, habe ich zwar ein Skript schreiben können, kann aber nicht beurteilen, ob das zweckmäßig ist.
Mir erscheint das Skript zielführend zu sein, aber ich habe keine Ahnung wo die Falltüren sind und welche himmelschreienden Anfängerfehler ich da reingetippt habe.
Meine Bitte wäre jetzt, dass sich jemand erbarmt, sich das Skript anzusehen und/oder auf meine Fragen einzugehen.
Im Moment habe ich weder Zeit noch Neigung, mich ins Neuland "Linux" soweit einzuarbeiten, dass ich ohne Hilfe auskäme, daher hoffe ich Euer KnowHow nutzen zu dürfen, ohne dass mir das als zu bequemer Weg vorgeworfen wird.


1. Die Aufgabe
Ich möchte Dateien eines Windows-Fileserver auf einem NAS sichern.
Auf dem NAS läuft ein Linux (DSM 6.1.4-15217 Update 5 auf Synology RS3617xs+).
Der aktive Part soll dabei das NAS sein und auf den Windowsserver möchte ich keine zusätzlichen Tools installieren.
SSH und sonstige Sicherheitsmaßnahmen benötige ich nicht.
Die Boardmittel und Zusatzpakete des NAS, die Backups ohne Skript ermöglichen, habe ich weitgehend ausprobiert und war damit nicht zufrieden.
Google zeigte mir ein paar fertige rsync-Skripte, die mir aber alle unnötig komplex erschienen und deren Funktionen für mich nicht verständlich waren.
Ich würde ein möglichst schlankes Skript bevorzugen, das ich gänzlich nachvollziehen kann.


2. Der Lösungsansatz
Ich mounte am NAS die Netzwerkfreigabe des Windows-Fileservers, auf der die zu sichernden Dateien liegen.
Dann kopiere ich mit dem NAS, die Dateien in einen lokalen Ordner des NAS.
Danach unmounte ich die Quelle wieder.
Zum Kopieren nutze ich rsync.
Die Ausgaben von rsync schreibe ich in eine Logdatei (2017-01-05_rsynclog.txt).
Im Skript erzeuge ich weitere Ausgaben, die in eine weitere Logdatei (2017-01-05_scriptlog.txt) geschrieben werden.
Die Trennung der Logs soll dazu dienen, dass das Kontroll-Log schlank bleibt und leicht ausgewertet werden kann.
Im Falle eines Fehlers oder Neugier, kann ich im rsync-Log nachsehen was tatsächlich passiert ist.


3. Der Status
Mein Skript habe ich noch nicht getestet, ich habe es heute geschrieben, um hier nicht mit leeren Händen dazustehen.
Die Kern-Befehle sudo mount.cifs... und sudo rsync... habe ich aber gestern in einer Telnet-Sitzung ausprobiert und sie funktionieren.


4. Das Script


5. Die Automatisierung
Wie ich das Skript zeitgesteuert starten kann, weiß ich.
Wie ich das erzeugte Log auswerten kann, weiß ich auch.
Also Alles außerhalb des Skriptes bekomme ich alleine hin.


6. Meine Fragen

6.1 Linux mount
Unter Windows kann ich direkt auf eine Freigabe zugreifen.
Beispiel: xcopy \\WinServer\Freigabe\Ordner\*.* D:\Backup\
Wird dabei - warum auch immer - die Verbindung unterbrochen, so wird auch der Kopiervorgang abbrechen.
Bei Linux scheint das so nicht zu gehen (oder doch?)
Jetzt mache ich mir folgende Sorge:
Wenn ich einen tatsächlich vorhandenen, lokalen Ordner nutzen muss, um darin die Freigabe zu mounten, ist dieser Ordner auch dann noch vorhanden, wenn die Verbindung zum Windowsserver abbricht.
Der lokale Ordner, der zum Mounten verwendet wird, enthält aber nicht die Dateien, die ich kopieren möchte.
Wird rsync in Kombination mit --delete dann feststellen, dass die vortags gesicherten Dateien im Ziel, nicht in der Quelle sind und daher - wie angewiesen - mein Backup (das Ziel) leeren, obwohl genau jetzt der Fall eingetreten sein könnte, in dem ich das Backup benötigen würde?

6.2 Mountstatus prüfen
Im lokalen Ordner, den ich zum Mounten nutze, habe ich eine lokale Datei lokal.txt abgelegt.
Wenn der Ordner nicht zum Mounten genutzt ist, dann habe ich lokal Zugriff auf diese Datei.
Ist der Ordner aber zum Mounten genutzt, so wird der tatsächliche, lokale Inhalt verborgen und nur der entfernte (gemountete) Inhalt zur Verfügung gestellt.
Finde ich die Datei lokal.txt im Mount-Ordner, dann ist dort nicht gemountet.
Ob das eine elegante Fallunterscheidung ist, ich weiß es nicht.

6.3 sudo im Script
Wie kann ich einen Befehl ausführen lassen, der sudo benötigt, ohne manuell das dafür notwendige Kennwort von Hand eingeben zu müssen?

6.4 Die rsync-Optionen
Der Parameter -a kombiniert diverse Parameter: -a = --archive = -rlptgoD
Ich frage mich, ob die enthaltenen Parameter -g = -group und -o = -owner für mich sinnvoll sind.
Alle Dateien und Ordner in der zu sichernen Windows-Quelle, sind einfach nur Daten, für die keine speziellen Berechtigungen gesetzt sind.
Jeder, der Zugriff auf die Freigabe des Windows-Fileserver hat, kann dort machen was er will.
Im Falle eines Restores, möchte ich unter Windows die Dateien vom Backupordner des NAS über's Netzwerk wieder auf den Windows-Fileserver kopieren.
Dabei und anschließend möchte ich nicht auf Schwierigkeiten treffen ala "Sie benötigen die Berechtigung von XY..." um dies oder das zu tun.
Sind die Parameter -g = -group und -o = -owner in diesem Sinne hilfreich oder kortraproduktiv?

Vielen Dank in Voraus
Gruß Frank

EDIT: Punkt 4. "Das Script" mit Änderungen aktualisiert

Content-Key: 360023

Url: https://administrator.de/contentid/360023

Ausgedruckt am: 02.10.2022 um 06:10 Uhr

Mitglied: 135111
Lösung 135111 05.01.2018 aktualisiert um 14:34:38 Uhr
Goto Top
Hi,
ich fang einfach mal an ein paar Fragen des Romans zu beantworten face-smile.
$datum=$(date +%y-%m-%d)
Datum wolltest du 4-stellig dann musst du das y groß schreiben %Y.
testdatei==${lokalequelle}/lokal.txt
Fehler, doppeltes Gleichheitszeichen.
Zeile 31
if [ -f $testdatei ]
Vergessen zu negieren? Du wolltest doch abbrechen wenn Datei nicht existiert.
6.3 sudo im Script
Kennwort des Linux Users bitte nicht hinterlegen, dazu nutzt man die sudoers Datei in der man eintragen kann welcher User welche Befehle oder Skripte ausführen mit sudo (auch ohne Passwort)ausführen kann.
https://stackoverflow.com/questions/25215604/use-sudo-without-password-i ...
https://wiki.ubuntuusers.de/sudo/Konfiguration/
z.B. mit
Alles ohne Passwort erlauben, kannst du ja auf die Befehle einschränken die du brauchst.

Alternativ startest du das ganze Skript elevated dann ist ein sudo im Skript nicht nötig.
6.2 Mountstatus prüfen
Prüfe den exit code des mount Befehls, das sollte hier reichen.
Beispiel: xcopy \\WinServer\Freigabe\Ordner\*.* D:\Backup\
Wird dabei - warum auch immer - die Verbindung unterbrochen, so wird auch der Kopiervorgang abbrechen.
Bei Linux scheint das so nicht zu gehen (oder doch?)
Doch rsync wird dir entsprechende Fehlermeldungen werfen.
Sind die Parameter -g = -group und -o = -owner in diesem Sinne hilfreich oder kortraproduktiv?
Brauchst du hier nicht, lässt sich auch trotz bei Verwendung von -a ausnehmen ohne jetzt -rlptD zu schreiben

Gruß @135111
Mitglied: aqui
aqui 05.01.2018, aktualisiert am 06.01.2018 um 12:15:37 Uhr
Goto Top
Wäre doch eher etwas für die Rubrik Bash & Shell Batch & Shell hier. Dann lesen es auch die richtigen Leute face-wink
(P.S.: Kann man nachträglich noch verschieben...)
Mitglied: Pedant
Pedant 05.01.2018 um 19:46:08 Uhr
Goto Top
Hallo fuerte,

Zitat von @135111:
ich fang einfach mal an ein paar Fragen des Romans zu beantworten face-smile.
Sorry für den vielen Text und Danke für Deine Hinweise.

Das Meiste davon habe ich jetzt in das Skript eingebaut bwz. korrigiert und im Ausgangspost aktualisiert.
Mittlerweile habe ich das Skript auch insgesamt getestet und dabei ein paar weitere Korrekturen und Kosmetik vorgenommen.
Es läuft jetzt ohne Fehler durch, es sei denn ich provoziere Fehler, die dann scheinbar auch an richtiger Stelle abgefangen werden.

Zitat von @135111:
Kennwort des Linux Users bitte nicht hinterlegen, dazu nutzt man die sudoers Datei
Dem Hinweis konnte ich nicht nachkommen, da auf meinem System kein visudo existiert, zumindest erhalte ich bei
sudo visudo den Hinweis: sudo: visudo: command not found
Da das Kennwort des Windows-Users auch im Klartext hinterlegt ist, ist es nur fair, wenn das auch für den Linux-User gilt.
(Okay, kein gutes Argument, aber jeder im Lan kennt das Kennwort ohnehin.)

Deiner verlinkten Anweisung zufolge sollte ich aber eventuelle Änderungen unbedingt mit visudo machen.
Die Datei /etc/sudoers habe ich allerdings gefunden.
Unverändert sieht sie so aus:


Zitat von @135111:
Doch rsync wird dir entsprechende Fehlermeldungen werfen.
Was das angeht bin ich noch nicht ganz beruhigt.
Das Ausfallen der Verbindung als solches kann rsync ja nicht bemerken, da es lediglich zwei lokale Ordner syncen soll.
Dass der Quellordner virtuell mit den Inhalten eines Fileservers gefüllt ist (oder war), kann es doch nicht erkennen, außer dass der Ordner plötzlich leer ist.
Das Mounten hat doch eher was von einer Anrufweiterschaltung, von der ich als Anrufender auch nichts mitbekomme.
Wie würde rsync sich verhalten, wenn beim Erstellen seiner "incremental file list" die Verbindung abbricht und rsync ab dann mit einem leeren, lokalen Ordner weiter macht?
Könnte es dann sein, dass rsync annimmt, dass im Ziel viele Dateien liegen, die nicht in der Quelle sind und diese dann brav im Ziel löscht?

Nochmal vielen Dank für Deine Mühe und Deine Tipps.

Zitat von @aqui:
Wäre doch eher etwas für die Rubrik Bash & Shell hier.
@aqui
Die Rubrik heißt Batch & Shell und das hatte ich (voreingenommen) als "Windows" abgestempelt.
Du kannst meine Frage aber gerne verschieben, wohin sie auch immer am besten passen mag.

Gruß Frank
Mitglied: 135111
Lösung 135111 06.01.2018 aktualisiert um 10:03:35 Uhr
Goto Top
Dem Hinweis konnte ich nicht nachkommen, da auf meinem System kein visudo existiert
Das brauchst du auch nicht unbedingt, das manuelle Eintragen der obigen Zeile in die sudoers tuts natürlich auch.
Wie würde rsync sich verhalten, wenn beim Erstellen seiner "incremental file list" die Verbindung abbricht
Es wirft einen Fehler weil ein SMB Timeout getriggert wird, der Ordner ist also dann nicht automatisch leer nur weil die Verbindung abbricht, der Zugriff auf das Verzeichnis hängt quasi in der Luft.

Zusätzlich kannst du natürlich einen Bit-Vergleich hinterherschieben, ich persönlich würde hier aber statt nur mit rsync zu arbeiten das ganze gleich versioniert mit rsnapshot aufbauen. Somit hast du immer eine gewisse Anzahl an Snapshots in der Hinterhand. Rsnapshot basiert auf rsync und läuft auch dort wo rsync läuft.
http://rsnapshot.org
Mitglied: Pedant
Pedant 06.01.2018 um 11:09:42 Uhr
Goto Top
Hallo fuerte,

Zitat von @135111:
...selbst hier getestet.
super, danke.

Zitat von @135111:
das manuelle Eintragen der obigen Zeile in die sudoers tust natürlich auch.
Wie schon erwähnt läuft das ganze auf einem NAS.
Starte ich das Skript in einer Telnetsitzung, muss ich das Kennwort eingeben.
Nutze ich aber die Aufgabenplanung der NAS-Software (Webinterface), kann ich auswählen das Skript als root ausführen zu lassen und dann läuft es auch ohne Kennwort (mit der unveränderten sudoers).
Den "Eingriff" kann ich mir daher sparen und das echo $sudokennwort | sudo -S command hab ich auch wieder rausgeworfen.

Zitat von @135111:
mit rsnapshot ... hast du immer eine gewisse Anzahl an Snapshots in der Hinterhand

rsnapshot hatte ich auch schon im Sinn und mich gerade an den Rechner gesetzt, um mich damit zu beschäftigen.
http://www.synology-wiki.de/index.php/Rsnapshot
Dennoch danke für die Anregung.

Jetzt habe ich erstmal Einiges zu lesen und auszuprobieren.
Ich melde mich wieder, sollte ich auf Schwierigkeiten stoßen oder eine fertige Lösung haben.
(Bis dahin halte ich den Thread noch offen, obwohl die Ausgangsfragen beantwortet wurden.)


Nur am Rande erwähnt. (Weiterlesen ist optional)...

Das NAS hatte ich jetzt neu angeschafft um endlich mehrere Missstände zu beheben und ein paar Verbesserungen einzuführen:

1. Katastrophenschutz
Meine Fileserver sichern sich bisher gegenseitig und alle sind mit Raid5+1HS ausgestattet.
Um Datenverlust wegen Hardwareausfall mache ich mir daher wenig Sorgen, aber alle Server stehen in einem Rack im selben Serverraum im Keller. Brand, Hochwasser o.ä. und alles wäre weg.
Das NAS kommt in ein anderes Gebäude, das auch am Lan angeschlossen ist.
2. Mehr Speicherplatz auf den Servern
Auf den Fielservern werde ich mehr Platz haben, weil ich dort keinen Platz mehr für die gegenseitigen Backups vorhalten muss.
3. Schutz vor den Auswirkungen von Virenbefall
Mein Netzwerk ist von innen sehr offen und das soll auch so bleiben, aber für einen Verschlüsselungstrojaner wäre es ein gefundenes Fressen.
Das NAS für die Backups möchte ich von dieser Offenheit ausgrenzen.
Daher soll keiner aus dem Lan schreibenden Zugriff auf das NAS erhalten, was mich dazu brachte die Backups vom NAS ausführen zu lassen, daher meine Beschäftigung mit rsync.
Wenn allerdings alle Quellen korrumpiert würden, würde beim nächsten täglichen Backup auch dieses korrumpiert sein.
Wenn ich ein Generationen-Backup mache, das täglich die geänderten Dateien sichert und die alten Versionen erst nach einer Woche verwirft, sollte ich Zeit genug haben zu merken, dass böse Dinge im Gange sind.
Im Moment habe ich etwa 16 TB an Dateien in den Quellen. Die täglichen Änderungen sind vergleichsweise eher klein.
Im Falle einer (unerwünschten) Verschlüsselung der Quellen, wären alle Quelldateien geändert und das inkrementelle Backup müsste dann statt ein paar GB die ganzen 16 TB sichern. Das hätte eine auffällige Backup-Berichts-E-Mail zur Folge, selbst wenn ansonsten niemand im Büro wäre, der sich über korrumpierte Dateien auf den Servern wundern würde.

Gruß Frank
Mitglied: aqui
aqui 06.01.2018 aktualisiert um 12:17:22 Uhr
Goto Top
Du kannst meine Frage aber gerne verschieben,
Sorry für den Dreckfuhler, denn mit Bashing hat das natürlich nichts zu tun.
Deinen Beitrag können andere Forenteilnehmer natürlich NICHT so mirnixdirnix verschieben, wäre ja auch fataler Unsinn wenn das gehen würde.
Hier bist also nur DU selber als TO (=Thread Owner) gefragt das in die richtige Rubrik zu schieben. Batch und Shell gibt es übrigens bei Unix schon Jahrzehnte länger als bei Winblows. Soviel zur Voreingenommenheit face-wink
Mitglied: Pedant
Pedant 06.01.2018 um 14:35:20 Uhr
Goto Top
Hallo aqui,

Zitat von @aqui:
Du kannst meine Frage aber gerne verschieben,
Hier bist also nur DU selber als TO (=Thread Owner) gefragt das in die richtige Rubrik zu schieben.
es war mir gar nicht bewusst, dass ich meine Beiträge selbst verschieben kann.
Ich hab's jetzt einfach gemacht, indem ich mein Ausgangspost bearbeitet und dort eine andere Rubrik auswählt habe.
Es scheint funktioniert zu haben.
Dich hatte ich zum Verschieben aufgefordert, weil ich dachte ich dürfe das nicht und Du bist hier Administrator.

Zitat von @aqui:
Batch und Shell gibt es übrigens bei Unix schon Jahrzehnte länger als bei Winblows. Soviel zur Voreingenommenheit face-wink
Ja, ich weiß - 01.01.1970 - deswegen schrieb ich ja "voreingenommen".

Gruß Frank
Mitglied: Pedant
Pedant 06.01.2018 um 20:13:56 Uhr
Goto Top
Hallo,

Zitat von @Pedant:
Zitat von @135111:
das manuelle Eintragen der obigen Zeile in die sudoers tuts natürlich auch.
Ich habe es jetzt per vi eingetragen.

Zitat von @Pedant:
Jetzt habe ich erstmal Einiges zu lesen und auszuprobieren.
Es hat einige Zeit gedauert bis ich rsnapshot endlich auf dem Nas installiert hatte.
Dann folgte Konfigurieren und Testen.

Ich kam dann an den Punkt festzustellen, dass es sehr unflexibel ist.
Man muss alles in einer conf definieren und anschließend kann man immer nur alle Quellen sichern und die landen dann immer im selben Ziel.
Das gefällt mir nicht gut und da ich für jede Quelle einen andere Freigabe mounten muss, müsste ich vor dem Start alle Quellen mounten, statt einer nach der anderen (immer die, die ich gerade brauche).
Da rsnapshot sich auch nur des rsync' bedient, habe ich mir das genauer angesehen.
Dessen Parameter --link-dest=/pfad/vorhergehender_Backupordner machte die eigentliche Arbeit.
Ich habe mein Skript jetzt so umgebaut, dass es diesen Parameter nutzt und die Ordnerrotation zuvor abhandelt.
Noch ist es nicht soweit, dass ich's posten möchte, nur mal die rsync-relevanten Zeilen:

Das Installieren von rsnapshot war aber nicht vergebens.
Es brachte rsync in der Version 3.1.2 mit sich. Zuvor war 3.0.9 installiert.
Der entscheidene Unterschied ist, dass zwar Beide den Parameter --link-dest=DIR kennen, aber das Ältere kopiert trotzdem Dateien neu, statt nur Hardlinks anzulegen. Ein Bug, der es einem Neuling nicht einfacher macht.

Gruß Frank
Mitglied: Pedant
Pedant 07.01.2018, aktualisiert am 21.01.2018 um 12:57:29 Uhr
Goto Top
Hallo,

mit meinem Skript bin ich endlich fertig.
Jetzt wollte ich nur noch meine Lösung mitteilen.

Zuvor noch vielen Dank an fuerte für seine Hilfe hier und einen schönen Gruß an aqui.


Ich habe das Skript in fünf Teile aufgeteilt.

1. Hauptskript
backups_ausfuehren.su
Das ist das Skript, das ich zeitgeplant, automatisch ausführen lasse.
Es sucht alle Aufgabenskripte (siehe 5.)
Dann liest es diese Skripte nacheinander ein und lässt jeweils das Workerskript damit laufen.
Am Anfang der Datei sind vier Zeilen zur individuellen Grundkonfiguration vorhanden.
Alles andere braucht nicht verändert werden.


2. Konfiguration
konfiguration.sh
Ergänzend zur Konfiguration im Hauptskript, sind hier alle weiteren, allgemeine Konfigurationen vorzunehmen, also die Anpassung an die individuelle Systemsituation.

3. Funktionen
funktionen.sh
In diesem Skript sind lediglich "funtions" ausgelagert, die vom Hauptskript und/oder Workerskript genutzt werden.
Hier muss nichts angepasst werden.

4. Workerskript
psync.su
Dieses Skript erledigt die eigentliche Arbeit.
Es wird je einmal pro Backupaufgabe vom Hauptskript aufgerufen.
(Es direkt aufzurufen ist nicht sinnvoll, es ist funktionell vom Hauptskript abhängig.)
Für jede Aufgabe legt es ein versioniertes Backup an.
Die Versionstiefe kann für jeden Backupjob getrennt im zugehörigen Aufgabenskript definiert werden.
Bei bspw. 7 Versionen werden die Backup-Unterordner 0-6 gepflegt.
Bei einer Ausführung pro Tag wäre das also ein Backup, das die letzten 7 Tage sichert.
Im Prinzip macht das Skript dasselbe wie rsnapshot.
Für jede Aufgabe erstellt es ein eigenes Paar Logdateien, zusätzlich zu Einträgen im Sammel-Log, welches für jede Ausführung des Hautskripts angelegt wird.
Scheitert es bei einer Aufgabe, macht das Rahmenskript dennoch mit der nächsten Aufgabe weiter.
Hier muss nichts angepasst werden.

5. Aufgabenskripte
sichern_eine-aufgabe.su
sichern_andere-aufgabe.su
usw.
Das sind Einzel-Skripte, die jeweils eine Backupaufgabe definieren.
Im Grunde sind es lediglich Config-Dateien.
Um eine neue Aufgabe zu erstellen, muss lediglich ein Aufgabenskript kopiert, benannt und der Aufgabe entsprechend, individuell angepasst werden.
Sie entsprechen namentlich alle einem, in der Konfiguration zu definierenden Muster, bspw. sichern_*.sh, damit sie vom Hauptskript gefunden und benutzt werden.
Zum Löschen einer Aufgabe kann die zugehörige Datei gelöscht, verschoben oder umbenannt werden. Beim Umbenennen ist darauf zu achten, dass der Dateiname nicht mehr dem definierenden Muster entspricht.


Jetzt noch die Codes..


1. Hauptskript backups_ausfuehren.su

2. Konfiguration konfiguration.sh

3. Funktionen funktionen.sh

4. Workerskript psync.su

5. Aufgabenskripte sichern_eine-aufgabe.su (und beliebig weitere)


In funktionen.sh wird das Tool nail zum E-Mail-Versand der Logdatei verwendet.
Nail muss gegebenenfalls noch installiert und konfiguriert werden und der Pfad zu nail angepasst werden.
Betriff: funktionen.sh - Zeile 327

In psync.sh wird das Tool rsync zur eigentlichen Backupausführung verwendet.
rsync muss gegebenenfalls noch installiert werden und der Pfad zu rsync angepasst werden.
Betriff: psync.sh - Zeilen 58 und 62

Gruß Frank

EDIT: Inhalt des Beitrags komplett aktualisiert am 21.01.2018
Mitglied: Pedant
Pedant 21.01.2018 um 12:56:30 Uhr
Goto Top
Hallo,

die Skritpe für meine rsync-Backuplösung habe ich noch weiter optimiert.
Meinen vorhergehenden Beitrag habe ich entsprechend angepasst.
Die Skripte sind dort jetzt so, wie ich sie bei mir im produktiven Einsatz habe.
Falls jemand Interesse an der Lösung hat, könnte er diese Skripte mit wenigen Anpassungen nutzen oder nach belieben "umprogrammieren".

Gruß Frank