10
Rsync kann einige Files nicht synchronisieren (code 23)
Hallo!
Ich möchte Daten per rsync von einem Linux-Server auf einen anderen synchronisieren, dass läuft aber bei vielen Dateien auf Fehler
Der Befehl sieht so aus:
rsync -azvAp --delete /srv/share/zentral/ backup:/500GB/backup
Den Befehl setze ich als root ab.
Das klappt zu einem Teil, aber bei sehr vielen Dateien steht:
Am Ende steht dann:
was bedeutet das?
Wie kann ich sicher stellen, dass der rsync-Befehl auch wirklich alles synchronisiert?
Ich möchte Daten per rsync von einem Linux-Server auf einen anderen synchronisieren, dass läuft aber bei vielen Dateien auf Fehler
Der Befehl sieht so aus:
rsync -azvAp --delete /srv/share/zentral/ backup:/500GB/backup
Den Befehl setze ich als root ab.
Das klappt zu einem Teil, aber bei sehr vielen Dateien steht:
Am Ende steht dann:
was bedeutet das?
Wie kann ich sicher stellen, dass der rsync-Befehl auch wirklich alles synchronisiert?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 136097
Url: https://administrator.de/forum/rsync-kann-einige-files-nicht-synchronisieren-code-23-136097.html
Ausgedruckt am: 23.12.2024 um 15:12 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
es kann sein, dass Du
a) Dateien hast die nicht so ganz in die POSIX Namenenskonvention passen oder
b) das Du auf einige der Dateien keine Rechte hast (auch wenn Du den Befehl als root ausführst
kannst Du mal ein paar Details zu den zu synchronisierenden Dateien geben. Ansonsten mal den Output mit > (file_name) 2>&1 umleiten, dann können wir ja mal im Detail an einem Dateibeispiel gucken.
Bye
MT
es kann sein, dass Du
a) Dateien hast die nicht so ganz in die POSIX Namenenskonvention passen oder
b) das Du auf einige der Dateien keine Rechte hast (auch wenn Du den Befehl als root ausführst
kannst Du mal ein paar Details zu den zu synchronisierenden Dateien geben. Ansonsten mal den Output mit > (file_name) 2>&1 umleiten, dann können wir ja mal im Detail an einem Dateibeispiel gucken.
Bye
MT
Hallo!
Habe mittlerweile rausgefunden, dass trotz der Meldungen alle Dateien rübergesynct werden, allerdings werden die ACLs zerschossen und nur noch root, der Besitzer und die Besitzergruppe können auf die Datei zugreifen. wir haben aber natürlich diverse Gruppen erstellt, die auch in den ACLs stehen und dann auf dem Zielserver nicht mehr auf die Datei zugreifen können.
Der Parameter A soll ja eigentlich dafür sorgen, dass die ACLs mit rübergeschoben werden.
Ich habe nun von meinem Rechenzentrum den Hinweis bekommen, dass ich ausserhalb des /srv-Verzeichnisses keine ACLs mehr beeinflussen kann. Auf dem Zielserver kopiere ich aber ja die Dateien nicht in ein Unterverzeichnis unter /srv sondern auf eine komplett andere gemountete Platte (in diesem Fall also nach /500GB/backup)
Ich vermute hier das Problem.
Aber wie haben die das gemacht und gibt es einen Weg, diese Einschränkung zumindest für meine zusätzliche Platte wieder aufzuheben, so dass die ACLs mitgenommen werden können?
Jemand 'ne Idee?
Habe mittlerweile rausgefunden, dass trotz der Meldungen alle Dateien rübergesynct werden, allerdings werden die ACLs zerschossen und nur noch root, der Besitzer und die Besitzergruppe können auf die Datei zugreifen. wir haben aber natürlich diverse Gruppen erstellt, die auch in den ACLs stehen und dann auf dem Zielserver nicht mehr auf die Datei zugreifen können.
Der Parameter A soll ja eigentlich dafür sorgen, dass die ACLs mit rübergeschoben werden.
Ich habe nun von meinem Rechenzentrum den Hinweis bekommen, dass ich ausserhalb des /srv-Verzeichnisses keine ACLs mehr beeinflussen kann. Auf dem Zielserver kopiere ich aber ja die Dateien nicht in ein Unterverzeichnis unter /srv sondern auf eine komplett andere gemountete Platte (in diesem Fall also nach /500GB/backup)
Ich vermute hier das Problem.
Aber wie haben die das gemacht und gibt es einen Weg, diese Einschränkung zumindest für meine zusätzliche Platte wieder aufzuheben, so dass die ACLs mitgenommen werden können?
Jemand 'ne Idee?
Hallo,
kann es sein, dass die Dateisysteme, also sprich Quelle und Ziel unterschiedlich sind?
Bye
MT
kann es sein, dass die Dateisysteme, also sprich Quelle und Ziel unterschiedlich sind?
Bye
MT
nein, bei Quelle und Ziel handelt es sich um linux-Dateisystem
Seltsam, dann sollten die ACLs mitkommen.
Zwei Sachen vielleicht noch.
Passiert das auch wenn Du die Kompression raus nimmst?
Bei einigen Distributionen gab es mal Probleme mit dem Thema SLES war eine der Baustellen, ich weiß aber nicht genau ob das mal gefixt wurde oder nicht. Welche Dist, benutzt Du?
Zwei Sachen vielleicht noch.
Passiert das auch wenn Du die Kompression raus nimmst?
Bei einigen Distributionen gab es mal Probleme mit dem Thema SLES war eine der Baustellen, ich weiß aber nicht genau ob das mal gefixt wurde oder nicht. Welche Dist, benutzt Du?
Habe mal testweise die Kompression rausgenommen, kein Erfolg. Es wird weiterhin die ACL zerschossen.
Hier mal ein Beispiel: das Verzeichnis fawism sieht auf dem Quellserver acl-mäßig so aus:
group::r-x
group:sperre-alle-lw:---
group:sperre-lw-q:---
group:fawism_admin:rwx
group:fawism:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:fawism_admin:rwx
default:group:fawism:rwx
default:mask::rwx
default:other::---
Nach dem Syncen sieht die ACL auf dem Zielserver dann so aus:
group::rwx
other::---
Alles schön sauber ;)
die Frage ist: wieso und wie löse ich das Problem...?
Hier mal ein Beispiel: das Verzeichnis fawism sieht auf dem Quellserver acl-mäßig so aus:
- file: fawism/
- owner: root
- group: root
group::r-x
group:sperre-alle-lw:---
group:sperre-lw-q:---
group:fawism_admin:rwx
group:fawism:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:fawism_admin:rwx
default:group:fawism:rwx
default:mask::rwx
default:other::---
Nach dem Syncen sieht die ACL auf dem Zielserver dann so aus:
- file: fawism/
- owner: root
- group: root
group::rwx
other::---
Alles schön sauber ;)
die Frage ist: wieso und wie löse ich das Problem...?
Sorry, bin noch dran, jedoch wie das so in der Arbeit ist ^_^
Aaaalso, ich habe mir mal ein paar Ideen noch von einem Kollegen geholt. Laut deren Info sollte das ja alles ganz wunderbar gehen. Also, vielleicht noch zwei interessante Punkte.
Hast Du das Volume vom anderen Server mit root Rechten gemountet? (Ich würde mal vermuten ja, das wäre ja Standard)
Eine Vermutung des Kollegen war, dass Du vielleicht auf der Zielbox einen User mit gleicher ID aber anderen Rechten hast, weshalb die Rechte, für diese ID, nicht gesetzt werden können.
Der völlige Brachialtrick um ein Problem bei den IDs zu umgehen und um zu sehen, ob vielleicht die verwendete Version das Problem herstellt, ist, laut meinen Kollegen, dass Du die IDs von Quellserver auf Zielserver klonst, den rsync job ausführst, die Berechtigungen checkst und anschließend die IDs auf dem Zielserver wiederherstellst. Dadurch könnten wir es ja ein wenig eingrenzen.
Hast Du das Volume vom anderen Server mit root Rechten gemountet? (Ich würde mal vermuten ja, das wäre ja Standard)
Eine Vermutung des Kollegen war, dass Du vielleicht auf der Zielbox einen User mit gleicher ID aber anderen Rechten hast, weshalb die Rechte, für diese ID, nicht gesetzt werden können.
Der völlige Brachialtrick um ein Problem bei den IDs zu umgehen und um zu sehen, ob vielleicht die verwendete Version das Problem herstellt, ist, laut meinen Kollegen, dass Du die IDs von Quellserver auf Zielserver klonst, den rsync job ausführst, die Berechtigungen checkst und anschließend die IDs auf dem Zielserver wiederherstellst. Dadurch könnten wir es ja ein wenig eingrenzen.
Vielen Dank MegaTraveller für die Hilfestellung und Ideen und den Hirnschmalz!!!
Die Lösung war dann aber doch etwas anderes (hat mich ein Kollege drauf gebracht):
Die Festplatte war irgendwie falsch gemountet. Wenn man "mount" eingibt, erhält man ja die Übersicht, was wie gemountet ist. Dort steht dann nicht nur das Dateisystem (was ja bei mir korrekterweise ext3 bei Quelle und Ziel ist) sondern auch weitere Parameter zum Volume.
Und genau bei den Parametern war der Hund begraben. Meine zusätzliche IDE-Platte war mit dem Standard Mount-Befehl ohne Parameter gemountet und hatte daher bei den Parametern nur "rw" stehen.
Um die erweiterten ACLs auf diesem Volume aber auch nutzen zu können, muss mindestens auch der Parameter "acl" erscheinen.
Ich habe das so gelöst: in der /etc/fstab habe ich den Eintrag für die weitere Platte wie folgt modifiziert:
und das volume einmal mit umount und mount neu gemountet. Und siehe da, nun steht nach Eingabe von "mount" bei dem Volume als Parameter auch acl mit drin.
Wenn ich nun mittels rsync und dem Parameter -A synchronisiere, werden auch schön die ACLs mit rüber geschoben. Fein Fein!
Also nochmal: auch wenn's nicht direkt die Lösung war: vielen Dank für die Tipps und Ideen!!!
Die Lösung war dann aber doch etwas anderes (hat mich ein Kollege drauf gebracht):
Die Festplatte war irgendwie falsch gemountet. Wenn man "mount" eingibt, erhält man ja die Übersicht, was wie gemountet ist. Dort steht dann nicht nur das Dateisystem (was ja bei mir korrekterweise ext3 bei Quelle und Ziel ist) sondern auch weitere Parameter zum Volume.
Und genau bei den Parametern war der Hund begraben. Meine zusätzliche IDE-Platte war mit dem Standard Mount-Befehl ohne Parameter gemountet und hatte daher bei den Parametern nur "rw" stehen.
Um die erweiterten ACLs auf diesem Volume aber auch nutzen zu können, muss mindestens auch der Parameter "acl" erscheinen.
Ich habe das so gelöst: in der /etc/fstab habe ich den Eintrag für die weitere Platte wie folgt modifiziert:
/dev/hda1 /500GB ext3 noauto,acl,usrquota 0 0und das volume einmal mit umount und mount neu gemountet. Und siehe da, nun steht nach Eingabe von "mount" bei dem Volume als Parameter auch acl mit drin.
Wenn ich nun mittels rsync und dem Parameter -A synchronisiere, werden auch schön die ACLs mit rüber geschoben. Fein Fein!
Also nochmal: auch wenn's nicht direkt die Lösung war: vielen Dank für die Tipps und Ideen!!!
Cool, Dank, wieder auch mal was dazu gelernt 
