9
Symlinks mit rsync sichern (Windows zu Linux)
Hallo,
wenn ich meinen Windows-Fileserver sichern möchte, habe ich ein Problem mit dort abgelegten Symlinks.
Ich bekomme es nicht hin, dass die einfach kopiert werden.
Das Backup lasse ich unter Linux mit rsync ausführen.
Dazu mounte ich die Freigabe des Windows-Fileservers in einen lokalen Ordner des Linux-Rechners.
Dann starte ich rsync.
Im Log von rsync erhalte ich u.a. diese Meldungen:
(Die Windows-Quelle mit ntfs, das Linux-Ziel ist mit ext4 formatiert.)
Wenn ich unter Windows ein
erhalte ich diese Ausgabe:
Den relativen Pfad "Versions\Current\Resources" gibt es so nicht.
Es gibt aber "Versions\A\Resources\*.*"
"Current" im Unterordner "Versions" ist ein weiterer Symlink:
Aber egal, mich interessiert nicht, ob die vorhandenen Symlinks dort funktionieren oder nicht.
Zu Symlinks und rsync habe ich das hier gefunden:
rsync mit oder ohne der Option
Ich vermute daher, dass der Fehler schon an früherer Stelle zu suchen ist, also beim Mount oder schon beim Windows-Server.
Versuche ich diesen Symlink "Resources" übers Netzwerk vom Linux-Rechner (aus dem gemounteten Pfad) auf meinen Windows-PC zu kopieren, kommt diese Meldung:
Versuche ich diesen Symlink "Resources" übers Netzwerk vom Windows-Server auf meinen Windows-PC zu kopieren, kommt diese Meldung:
Bei der Suche nach den genannten Fehlermeldungen und -nummer habe ich nichts gefunden, was mir geholfen hat, mein Problem zu lösen oder zumindest mal zu verstehen was es ist und wo es eigentlich liegt.
Wie gesagt geht es mir um ein reines Backup der Dateien des Fileservers und dazu gehören auch die Symlink-"Dateien".
Ohne die wäre das Backup nicht vollständig und das Log voller Fehlermeldungen.
Die Symlinks auf dem Fileserver erfüllen dort keine Funktion, sondern sind dort nur abgelegt, weil sie zu Projekten gehören, die auf dem Fileserver gelagert werden
Gruß Frank
wenn ich meinen Windows-Fileserver sichern möchte, habe ich ein Problem mit dort abgelegten Symlinks.
Ich bekomme es nicht hin, dass die einfach kopiert werden.
Das Backup lasse ich unter Linux mit rsync ausführen.
Dazu mounte ich die Freigabe des Windows-Fileservers in einen lokalen Ordner des Linux-Rechners.
sudo mount.cifs -o iocharset=utf8,ro,username=Administrator,password=geheim //WinServer/Freigabe/ /volume1/admin/mountrsync -rtlDW --stats --log-file="/volume1/admin/log/rsynclog.txt" --link-dest=/volume1/Backup/1 /volume1/admin/mount/ /volume1/Backup/0rsync: send_files failed to open "/volume1/admin/mount/Ablage/EineMac.app/Contents/Frameworks/Dings Framework.framework/Resources": Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2]
In diesem Fall ist "Resources" ein Symlink.rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2]
(Die Windows-Quelle mit ntfs, das Linux-Ziel ist mit ext4 formatiert.)
Wenn ich unter Windows ein
dir absetzedir "\\WinServer\Freigabe\Ablage\EineMac.app\Contents\Frameworks\Dings Framework.framework"27.10.2017 08:19 <SYMLINK> Resources [Versions\Current\Resources]Es gibt aber "Versions\A\Resources\*.*"
"Current" im Unterordner "Versions" ist ein weiterer Symlink:
22.09.2017 08:23 <SYMLINK> Current [A]Aber egal, mich interessiert nicht, ob die vorhandenen Symlinks dort funktionieren oder nicht.
Zu Symlinks und rsync habe ich das hier gefunden:
-l = --links = copy symlinks as symlinks
-L = --copy-links = transform symlink into referent file/dir
Da ich nicht die verlinkten Dateien/Ordner kopieren möchte, wenn der Backup-Vorgang auf einen Symlink trifft, sondern einfach nur den Link kopieren möchte und es mir dabei egal ist, ob der funktioniert oder "broken" ist, schein mir -L = --copy-links = transform symlink into referent file/dir
-L die falsche Option zu sein.rsync mit oder ohne der Option
-l auszuführen, macht aber leider keinen Unterschied.Ich vermute daher, dass der Fehler schon an früherer Stelle zu suchen ist, also beim Mount oder schon beim Windows-Server.
Versuche ich diesen Symlink "Resources" übers Netzwerk vom Linux-Rechner (aus dem gemounteten Pfad) auf meinen Windows-PC zu kopieren, kommt diese Meldung:
Fehler 0x80070032: Die Anforderung wird nicht unterstützt.
Resources
Typ: Datei
Größe: 0 Bytes
Resources
Typ: Datei
Größe: 0 Bytes
Versuche ich diesen Symlink "Resources" übers Netzwerk vom Windows-Server auf meinen Windows-PC zu kopieren, kommt diese Meldung:
Fehler 0x800705B7: Der symbolische Link kann nicht verfolgt werden, da der Linktyp deaktiviert ist.
Resources
Typ: .symlink
Größe: 0 Bytes
Resources
Typ: .symlink
Größe: 0 Bytes
Bei der Suche nach den genannten Fehlermeldungen und -nummer habe ich nichts gefunden, was mir geholfen hat, mein Problem zu lösen oder zumindest mal zu verstehen was es ist und wo es eigentlich liegt.
Wie gesagt geht es mir um ein reines Backup der Dateien des Fileservers und dazu gehören auch die Symlink-"Dateien".
Ohne die wäre das Backup nicht vollständig und das Log voller Fehlermeldungen.
Die Symlinks auf dem Fileserver erfüllen dort keine Funktion, sondern sind dort nur abgelegt, weil sie zu Projekten gehören, die auf dem Fileserver gelagert werden
Gruß Frank
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: 360573
Url: https://administrator.de/forum/symlinks-mit-rsync-sichern-windows-zu-linux-360573.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
9 Kommentare
Neuester Kommentar
Wenn das ein Verzeichnis-Symlink ist brauchst du -K bzw. --keep-dirlinks und --copy-unsafe-links
Hallo fuerte,
danke für die Info.
Ich habe jetzt einen Durchlauf mit dieser Zeile gemacht:
<codetype="plain">
rsync -rtlDW --keep-dirlinks --copy-unsafe-links --stats --log-file="/volume1/admin/log/rsynclog.txt" --link-dest=/volume1/Backup/1 /volume1/admin/mount/ /volume1/Backup/0
Das Ergebins ist leider identisch, also die gleichen Fehlermeldungen im Log und die fraglichen Symlinks wurden nicht ins Ziel kopiert.
Was ich zu den Optionen im Netz fand, half mir nicht wirklich zu verstehen was sie bewirken.
Gruß Frank
danke für die Info.
Ich habe jetzt einen Durchlauf mit dieser Zeile gemacht:
<codetype="plain">
rsync -rtlDW --keep-dirlinks --copy-unsafe-links --stats --log-file="/volume1/admin/log/rsynclog.txt" --link-dest=/volume1/Backup/1 /volume1/admin/mount/ /volume1/Backup/0
Das Ergebins ist leider identisch, also die gleichen Fehlermeldungen im Log und die fraglichen Symlinks wurden nicht ins Ziel kopiert.
Was ich zu den Optionen im Netz fand, half mir nicht wirklich zu verstehen was sie bewirken.
--copy-dirlinks -k | Sender-Symlink auf Verz. in echtes Zielverz. umwandeln
--keep-dirlinks -K | Empfänger-Symlink auf Verz. als echtes Verz. behandeln
Option -k/--copy-dirlinks sorgt dafür, dass der Sender einen Symlink auf
ein Verz. als ECHTES Verz. behandelt. Symlinks auf alles außer Verz. bleiben
erhalten. OHNE diese Option wird beim Ersetzen eines Verz. durch einen
Symlink auf Senderseite die Empfängerseite ALLES löschen, was dem Symlink
im Weg steht (auch einen kompletten Verz.baum).
Option -K/--keep-dirlinks sorgt dafür, dass der Empfänger einen Symlink auf
ein Verz. als ECHTES Verz. behandelt (nur wenn er ein echtes Verz. auf dem
Sender referenziert). OHNE diese Option wird der Empfänger-Symlink entfernt
und durch ein echtes Verz. ersetzt.
--keep-dirlinks -K | Empfänger-Symlink auf Verz. als echtes Verz. behandeln
Option -k/--copy-dirlinks sorgt dafür, dass der Sender einen Symlink auf
ein Verz. als ECHTES Verz. behandelt. Symlinks auf alles außer Verz. bleiben
erhalten. OHNE diese Option wird beim Ersetzen eines Verz. durch einen
Symlink auf Senderseite die Empfängerseite ALLES löschen, was dem Symlink
im Weg steht (auch einen kompletten Verz.baum).
Option -K/--keep-dirlinks sorgt dafür, dass der Empfänger einen Symlink auf
ein Verz. als ECHTES Verz. behandelt (nur wenn er ein echtes Verz. auf dem
Sender referenziert). OHNE diese Option wird der Empfänger-Symlink entfernt
und durch ein echtes Verz. ersetzt.
Gruß Frank
Hallo,
viel gelesen, viel getestet.
Ich habe den Eindruck, dass es mit den Optionen von rsync nur zweitrangig zu tun hat.
Kopieren per
An passendsten scheint mir dieser Thread zu sein:
https://forum.ubuntuusers.de/topic/cifs-client-folgt-nicht-symbolischen- ...
Dort wird von der zusätzlichen mount-Option
Ich habe mein Testszenario vereinfacht, dahingehend, dass ich die Windowsfreigabe, die in einem Unterordner einen Symlink names "symlink" enthält, unter Linux mounte und dann versuche am Linuxrechner den Ordner aus dem mount in einen lokalen Ordner zu kopieren.
Das führt zu dieser Fehlerausgabe:
Ob ich mit oder ohne
Ob ich mit oder ohne
-P = --no-dereference = Symbolische Links als symbolische Links kopieren, statt den Links in der Quelle zu folgen
Im verlinkten Thread, geht es um Linux zu Linux, dort ist also auch die Quelle ein Linux-Server.
Das dort beschriebene Problem ließ sich serverseitig lösen.
Allerdings sollten dort die Links verfolgt werden.
Ich möchte sie aber lediglich kopieren, wie eine normale Datei, was diese Links ja letztendlich auch nur sind.
(Ähnlich wie die
Dass diese Dateien eine besondere Funktion (Verlinkung) haben, soll beim Kopieren/Backupen egal sein, sie sollen einfach kopiert und ihre verlinkende Funktion dabei ignoriert werden.
Dafür müsste die
Hier die serverseitige Lösung für das Linux-zu-Linux-Links-verfolgen-Problem:
Da ich einen Windows-Server als Quelle habe, habe ich leider keine
Soll ich's aufgeben oder hat jemand eine Idee was ich noch ausprobieren könnte?
Gruß Frank
viel gelesen, viel getestet.
Ich habe den Eindruck, dass es mit den Optionen von rsync nur zweitrangig zu tun hat.
Kopieren per
cp hat denselben Kummer.An passendsten scheint mir dieser Thread zu sein:
https://forum.ubuntuusers.de/topic/cifs-client-folgt-nicht-symbolischen- ...
Dort wird von der zusätzlichen mount-Option
nounix gesprochen.Ich habe mein Testszenario vereinfacht, dahingehend, dass ich die Windowsfreigabe, die in einem Unterordner einen Symlink names "symlink" enthält, unter Linux mounte und dann versuche am Linuxrechner den Ordner aus dem mount in einen lokalen Ordner zu kopieren.
sudo mount.cifs -o iocharset=utf8,ro,nounix,username=Administrator,password=geheim //WinServer/Freigabe/ /volume1/admin/mount
sudo cp -P -r /volume1/admin/mount/Ordner /volume1/Tempcp: cannot open ÔÇÿ/volume1/admin/mount/Ordner/symlinkÔÇÖ for reading: Operation not supported
Ob ich mit oder ohne
nounix mounte macht keinen Unterschied.Ob ich mit oder ohne
-P kopiere macht auch keinen Unterschied.-P = --no-dereference = Symbolische Links als symbolische Links kopieren, statt den Links in der Quelle zu folgen
Im verlinkten Thread, geht es um Linux zu Linux, dort ist also auch die Quelle ein Linux-Server.
Das dort beschriebene Problem ließ sich serverseitig lösen.
Allerdings sollten dort die Links verfolgt werden.
Ich möchte sie aber lediglich kopieren, wie eine normale Datei, was diese Links ja letztendlich auch nur sind.
(Ähnlich wie die
.lnk-Dateien unter Windows auch nur Dateien sind.)Dass diese Dateien eine besondere Funktion (Verlinkung) haben, soll beim Kopieren/Backupen egal sein, sie sollen einfach kopiert und ihre verlinkende Funktion dabei ignoriert werden.
Dafür müsste die
cp-Option -P sorgen, doch mit dem Mount als Quelle scheitert das Kopieren wie beschrieben.Hier die serverseitige Lösung für das Linux-zu-Linux-Links-verfolgen-Problem:
Ein cifs/smb-Client unter Linux folgt symbolischen Links auf dem Server nur, wenn folgende Einstellungen auf dem Server in
/etc/samba/smb.conf gemacht werden:[global]
> follow symlinks = yes
> # follow symlinks kann man weglassen, das ist i.d.R die Defaulteinstellung. Mit "no" gehts aber nicht
> wide links = yes
> # wide links kann man weglassen, das ist i.d.R die Defaulteinstellung. Mit "no" gehts aber nicht
> unix extensions = noDa ich einen Windows-Server als Quelle habe, habe ich leider keine
smb.conf mit der ich ausprobieren könnte, ob mein Problem damit auch zu beheben wäre.Soll ich's aufgeben oder hat jemand eine Idee was ich noch ausprobieren könnte?
Gruß Frank
Hi frank,
ich hab mal gelernt, das man Windows Betriebssysteme mit dem Befehl:
mounten soll? Oder sehr ich da was falsch?
Gruß
Holli
ich hab mal gelernt, das man Windows Betriebssysteme mit dem Befehl:
smbmountmounten soll? Oder sehr ich da was falsch?
Gruß
Holli
Hallo Holli,
Entweder ist es irgendwo versteckt oder nicht vorhanden.
Ich such noch mal intensiver.
Gruß und Dank
Frank
smbmount führt auf dem NAS (auf dessen Linux) zu "command not found".Entweder ist es irgendwo versteckt oder nicht vorhanden.
Ich such noch mal intensiver.
Gruß und Dank
Frank
Hi,
das mit dem NAS hattest Du oben nicht geschrieben! Daher ging ich von reinen Linux aus!
Schreib mal, welchen NAS Du genau hast und mit welcher Firmware?
Gruß
Holli
Zitat von @Pedant:
Hallo Holli,
Entweder ist es irgendwo versteckt oder nicht vorhanden.
Ich such noch mal intensiver.
Gruß und Dank
Frank
Hallo Holli,
smbmount führt auf dem NAS (auf dessen Linux) zu "command not found".Entweder ist es irgendwo versteckt oder nicht vorhanden.
Ich such noch mal intensiver.
Gruß und Dank
Frank
das mit dem NAS hattest Du oben nicht geschrieben! Daher ging ich von reinen Linux aus!
Schreib mal, welchen NAS Du genau hast und mit welcher Firmware?
Gruß
Holli
Hallo Holli,
ja, tatsächlich:
Gerät: Synology RS3617xs+
System: DSM 6.1.4-15217 Update 5 (ist das Aktuelle)
Gruß Frank
ja, tatsächlich:
Gerät: Synology RS3617xs+
System: DSM 6.1.4-15217 Update 5 (ist das Aktuelle)
Gruß Frank
Hi Frank,
was ist mit " iSCSI Targets auf einem Windows-Server"?
Vielleicht mußt Du das leider genau anders herum machen?
Siehe URL:
https://www.synology.com/de-de/knowledgebase/DSM/tutorial/Virtualization ...
Gruß
Holli
was ist mit " iSCSI Targets auf einem Windows-Server"?
Vielleicht mußt Du das leider genau anders herum machen?
Siehe URL:
https://www.synology.com/de-de/knowledgebase/DSM/tutorial/Virtualization ...
Gruß
Holli
Hallo Holli,
danke für die Anregung.
Ich möchte allerdings, dass die Window-Server und -Clients zu keinem Zeitpunkt schreibenden Zugriff auf das Nas (die Backups) haben.
Wenn sich mal eine Windowsseuche einschleusen sollte, so sollen zumindest die Backup davor geschützt sein.
Zu dem Zweck lasse ich einmal täglich versionierte Backups machen, mit 7 Tagen Haltbarkeit, damit ich auch noch unversehrte Dateien habe, wenn die Quellen verseucht wurden und der verseuchte Kram in die Backups geschrieben wurde.
Gruß Frank
danke für die Anregung.
Ich möchte allerdings, dass die Window-Server und -Clients zu keinem Zeitpunkt schreibenden Zugriff auf das Nas (die Backups) haben.
Wenn sich mal eine Windowsseuche einschleusen sollte, so sollen zumindest die Backup davor geschützt sein.
Zu dem Zweck lasse ich einmal täglich versionierte Backups machen, mit 7 Tagen Haltbarkeit, damit ich auch noch unversehrte Dateien habe, wenn die Quellen verseucht wurden und der verseuchte Kram in die Backups geschrieben wurde.
Gruß Frank
