- Mitglied seit
- 12. Feb 2009
- Beiträge
- 191
- Punkte für Reaktionen
- 7
- Punkte
- 24
Hallo zusammen,
ich bin auf ein Problem gestoßen, das ich gerne mit Euch teilen möchte. Evtl. hat jemand von Euch ein ähnliches Problem oder einen Denkansatz. Ich versuche das Thema so genau wie möglich zu beschreiben, ohne einen Roman zu erstellen. Stellt gerne Rückfragen, wenn ich Punkte übersehen/ausgelassen haben sollte.
Grundlage
Ich verwende mehrere Synology NAS-Geräte für den privaten und beruflichen Bereich (DS416, DS414, DS216, DS218).
Die Datensicherung erfolgt dreiteilig:
=> auf externe Festplatten (per USB an die DS, HyperBackup)
=> auf einen Cloudspeicher (mit HyperBackup)
=> per Remote-Verbindung an eine DS in einem anderen Gebäude
=> mit dem Programm HardlinkBackup auf eine weitere DS (lokal).
Hintergrund der Backupstrategie: Ich sichere die Daten auf verschiedene Medien, in verschiedenen Orten und mit verschiedenen Programmen. HyperBackup verwendet einen eigenen Container, HardlinkBackup sichert Daten, die mit jedem Betriebssystem gelesen werden können. Auf diese Weise versuche ich Hardwareschäden, Schäden an den HyerBackup-Containern, Wasser- und Feuerschäden zu umgehen.
Info: HardlinkBackup
Das Windows-Programm sichert im ersten Durchgang eine vollständige Kopie und sichert danach Hardlinks von unveränderten Dateien (ähnlich rsync). Dies funktioniert mit NTFS und mit SMB-Freigaben/Shares.
Das Problem
Jahrelang haben die Backups von HardlinkBackup (kurz HLB) problemlos funktioniert. Seit Herbst 2021 hagelte es dann Fehlermeldungen. Die Fehler bestanden darin, dass alte Backupsätze nicht mehr gelöscht werden konnten, da einzelne, fehlerhafte Dateien in den Verzeichnissen lagen.
=> Die fehlerhaften Dateien sind von Windows aus sichtbar, aber nicht bearbeitbar. Es erscheint die Fehlermeldung, dass die Datei nicht mehr vorhanden ist. Sie kann weder umbenannt, gelöscht oder verschoben werden. Das gleiche gilt für das übergeordnete Verzeichnis.
=> Über die DS kann ich die Datei problemlos löschen, umbenennen oder verschieben. Sie lässt sich auch öffnen, wenn ich sie z.B. auf einen Windows-Client herunterlade.
Nach vielen Tests konnte ich zu lange Dateipfade (in Summe) als Problem ausschließen. Zum einen kann HLB grundsätzlich damit umgehen und zum anderen lassen sich in den entsprechenden Ordnern mit dem Windows Explorer problemlos Dateien mit längerem Namen erstellen und auch löschen.
Die einzige Erklärung war, dass diese Dateien beim Erstellen der Hardlinks beschädigt wurden bzw. die Hardlinks nicht richtig funktionierten. Alle Dateien, die per innerer Hardlinks "verbunden" waren, ließen sich nicht mehr über Windows anfassen. D.h. wenn Datei "A" im Backupsatz "1" nicht zu löschen war, galt dies auch für die gleiche Datei in Backupsatz "2", "3" usw.
Problemeingrenzung
Ich habe dann angefangen umfangreiche Tests über fünf Monate zu erstellen:
- Backups auf USB-Laufwerke, lokale Laufwerke oder SMB-Freigaben auf Windows-Clients
- Backups auf ein Synology-NAS mit aktueller DSM7 hinterließ Hardlinks, die sich nicht löschen ließen
- Alle über die GUI des NAS verfügbaren SMB-Optionen habe ich durchprobiert (inkl. SMB1, 2, 3), ohne Erfolg
- Auch ein alternatives Synology-NAS mit frisch installierter Firmware habe ich erfolglos ausprobiert
- Alle Berechtigungen auf dem NAS habe ich mehrfach überprüft
- Verschiedene Windows-Clients brachten auch keinen Unterschied
- Bei den verschiedenen Testreihen waren auch immer andere Daten betroffen. Daher konnte ich die Quelldaten ausschließen.
=> Verschiedene DS, verschiedene Windows-Computer, verschiedene HLB-Versionen
=> Vergleichstests mit lokalen Festplatten, USB-Festplatten, SMB-Shares auf Windows-Clients
=> Innerhalb von DSM alle SMB-Einstellungen durchprobiert (SMB1, 2, 3 und die optionalen Punkte)
=> Ein alternatives Synology-NAS mit frisch installierter Firmware
=> Alle Berechtigungen auf dem NAS habe ich mehrfach überprüft
=> Verschiedene Windows-Clients
=> Bei den verschiedenen Testreihen waren auch immer andere Daten betroffen. Daher konnte ich die Quelldaten ausschließen.
Ergebnis (Kurzfassung):
Alle Tests auf lokalen Platten, USB-Platten und Windows-Shares verliefen fehlerfrei und problemlos
Alle Tests auf DS-Systemen zeigten den Fehler
Aber
Ich hatte bis dahin nur auf DSM 7.0 oder DS 7.1 getestet. Also habe ich auf einem Testsystem ein Downgrade auf 6.2.4 gemäß Anleitung hier im Forum durchgeführt.
=> Und sieht da: Die Probleme waren verschwunden. Und im Nachhinein konnte ich rekonstruieren, dass ich DSM 7.0 im Herbst 2021 das erste Mal installiert hatte. Dementsprechend passt das Fehlerbild zusammen.
Offenbar hat Synology beim Wechsel von DSM6 auf DSM7 auch die SMB-Funktionalität verändert, wodurch das Problem verursacht wird. Oder aber in der Software ist ein Fehler enthalten, der sich erst jetzt bemerkbar macht.
Lösung / Workaround
Aktuell ist der Workaround, dass ich auf den Backup-DS-Geräten das alte Betriebssystem laufen lasse. Hierfür muss ich erst 14TB Daten sichern (was mit Hardlinks nicht ganz unaufwendig ist) und dann das Downgrade durchführen.
Mittelfristig ist das aber keine Lösung, da ich natürlich auch von den Vorzügen von DSM7 profitieren möchte.
Eine Anfrage bei Synology habe ich laufen, aber ich vermute, dass die Antwort sein wird: Für Third-Party-Software bieten wir keinen Support. ;-) Daher erwarte ich hier keine direkte Lösung.
Im Forum von HLB habe ich auch eine entsprechende Anfrage gestellt (dort liest auch der Autor mit).
Ich freue mich, falls einer von Euch Ähnliches beobachtet hat oder noch eine Idee hat, was ich noch (in DSM7) testen könnte.
Viele Grüße,
SHC
Nachtrag:
Die Fehlermeldung unter Windows sieht wie folgt aus:
Den FAQ-Eintrag bei Synology habe ich schon abgearbeitet (DFS-Cache löschen)
https://kb.synology.com/de-de/DSM/tutorial/folder_does_not_exist_file_may_have_been_moved_or_deleted
ich bin auf ein Problem gestoßen, das ich gerne mit Euch teilen möchte. Evtl. hat jemand von Euch ein ähnliches Problem oder einen Denkansatz. Ich versuche das Thema so genau wie möglich zu beschreiben, ohne einen Roman zu erstellen. Stellt gerne Rückfragen, wenn ich Punkte übersehen/ausgelassen haben sollte.
Grundlage
Ich verwende mehrere Synology NAS-Geräte für den privaten und beruflichen Bereich (DS416, DS414, DS216, DS218).
Die Datensicherung erfolgt dreiteilig:
=> auf externe Festplatten (per USB an die DS, HyperBackup)
=> auf einen Cloudspeicher (mit HyperBackup)
=> per Remote-Verbindung an eine DS in einem anderen Gebäude
=> mit dem Programm HardlinkBackup auf eine weitere DS (lokal).
Hintergrund der Backupstrategie: Ich sichere die Daten auf verschiedene Medien, in verschiedenen Orten und mit verschiedenen Programmen. HyperBackup verwendet einen eigenen Container, HardlinkBackup sichert Daten, die mit jedem Betriebssystem gelesen werden können. Auf diese Weise versuche ich Hardwareschäden, Schäden an den HyerBackup-Containern, Wasser- und Feuerschäden zu umgehen.
Info: HardlinkBackup
Das Windows-Programm sichert im ersten Durchgang eine vollständige Kopie und sichert danach Hardlinks von unveränderten Dateien (ähnlich rsync). Dies funktioniert mit NTFS und mit SMB-Freigaben/Shares.
Das Problem
Jahrelang haben die Backups von HardlinkBackup (kurz HLB) problemlos funktioniert. Seit Herbst 2021 hagelte es dann Fehlermeldungen. Die Fehler bestanden darin, dass alte Backupsätze nicht mehr gelöscht werden konnten, da einzelne, fehlerhafte Dateien in den Verzeichnissen lagen.
=> Die fehlerhaften Dateien sind von Windows aus sichtbar, aber nicht bearbeitbar. Es erscheint die Fehlermeldung, dass die Datei nicht mehr vorhanden ist. Sie kann weder umbenannt, gelöscht oder verschoben werden. Das gleiche gilt für das übergeordnete Verzeichnis.
=> Über die DS kann ich die Datei problemlos löschen, umbenennen oder verschieben. Sie lässt sich auch öffnen, wenn ich sie z.B. auf einen Windows-Client herunterlade.
Nach vielen Tests konnte ich zu lange Dateipfade (in Summe) als Problem ausschließen. Zum einen kann HLB grundsätzlich damit umgehen und zum anderen lassen sich in den entsprechenden Ordnern mit dem Windows Explorer problemlos Dateien mit längerem Namen erstellen und auch löschen.
Die einzige Erklärung war, dass diese Dateien beim Erstellen der Hardlinks beschädigt wurden bzw. die Hardlinks nicht richtig funktionierten. Alle Dateien, die per innerer Hardlinks "verbunden" waren, ließen sich nicht mehr über Windows anfassen. D.h. wenn Datei "A" im Backupsatz "1" nicht zu löschen war, galt dies auch für die gleiche Datei in Backupsatz "2", "3" usw.
Problemeingrenzung
Ich habe dann angefangen umfangreiche Tests über fünf Monate zu erstellen:
- Backups auf USB-Laufwerke, lokale Laufwerke oder SMB-Freigaben auf Windows-Clients
- Backups auf ein Synology-NAS mit aktueller DSM7 hinterließ Hardlinks, die sich nicht löschen ließen
- Alle über die GUI des NAS verfügbaren SMB-Optionen habe ich durchprobiert (inkl. SMB1, 2, 3), ohne Erfolg
- Auch ein alternatives Synology-NAS mit frisch installierter Firmware habe ich erfolglos ausprobiert
- Alle Berechtigungen auf dem NAS habe ich mehrfach überprüft
- Verschiedene Windows-Clients brachten auch keinen Unterschied
- Bei den verschiedenen Testreihen waren auch immer andere Daten betroffen. Daher konnte ich die Quelldaten ausschließen.
=> Verschiedene DS, verschiedene Windows-Computer, verschiedene HLB-Versionen
=> Vergleichstests mit lokalen Festplatten, USB-Festplatten, SMB-Shares auf Windows-Clients
=> Innerhalb von DSM alle SMB-Einstellungen durchprobiert (SMB1, 2, 3 und die optionalen Punkte)
=> Ein alternatives Synology-NAS mit frisch installierter Firmware
=> Alle Berechtigungen auf dem NAS habe ich mehrfach überprüft
=> Verschiedene Windows-Clients
=> Bei den verschiedenen Testreihen waren auch immer andere Daten betroffen. Daher konnte ich die Quelldaten ausschließen.
Ergebnis (Kurzfassung):
Alle Tests auf lokalen Platten, USB-Platten und Windows-Shares verliefen fehlerfrei und problemlos
Alle Tests auf DS-Systemen zeigten den Fehler
Aber
Ich hatte bis dahin nur auf DSM 7.0 oder DS 7.1 getestet. Also habe ich auf einem Testsystem ein Downgrade auf 6.2.4 gemäß Anleitung hier im Forum durchgeführt.
=> Und sieht da: Die Probleme waren verschwunden. Und im Nachhinein konnte ich rekonstruieren, dass ich DSM 7.0 im Herbst 2021 das erste Mal installiert hatte. Dementsprechend passt das Fehlerbild zusammen.
Offenbar hat Synology beim Wechsel von DSM6 auf DSM7 auch die SMB-Funktionalität verändert, wodurch das Problem verursacht wird. Oder aber in der Software ist ein Fehler enthalten, der sich erst jetzt bemerkbar macht.
Lösung / Workaround
Aktuell ist der Workaround, dass ich auf den Backup-DS-Geräten das alte Betriebssystem laufen lasse. Hierfür muss ich erst 14TB Daten sichern (was mit Hardlinks nicht ganz unaufwendig ist) und dann das Downgrade durchführen.
Mittelfristig ist das aber keine Lösung, da ich natürlich auch von den Vorzügen von DSM7 profitieren möchte.
Eine Anfrage bei Synology habe ich laufen, aber ich vermute, dass die Antwort sein wird: Für Third-Party-Software bieten wir keinen Support. ;-) Daher erwarte ich hier keine direkte Lösung.
Im Forum von HLB habe ich auch eine entsprechende Anfrage gestellt (dort liest auch der Autor mit).
Ich freue mich, falls einer von Euch Ähnliches beobachtet hat oder noch eine Idee hat, was ich noch (in DSM7) testen könnte.
Viele Grüße,
SHC
Nachtrag:
Die Fehlermeldung unter Windows sieht wie folgt aus:
Den FAQ-Eintrag bei Synology habe ich schon abgearbeitet (DFS-Cache löschen)
https://kb.synology.com/de-de/DSM/tutorial/folder_does_not_exist_file_may_have_been_moved_or_deleted
Zuletzt bearbeitet:
