Datensicherung - Probleme mit LuckyBackup

[Flotux]

Hallo zusammen,

 

ich habe mir einen Share eingerichtet, der PDF-Dateien in Ordnern nach Jahren entfhält. Diesen möchte ich von Share aus auf eine Externe Festplatte sichern. Die Externe Festplatte ist mit Ex-Fat formatiert, damit ich die Dateien bei Bedarf auf einem MacOSX lesen kann.

 

Beim Sichern bekomme ich dann aber ziemlich oft folgende Fehlermelungen:

Failaid to set time on .. ... operation not permitet.

 

am Ende des Vorgangs heisst es dann "some files are not transfered .. code 23".

 

wir bekomme ich eine saubere Sicherung ?

 

Danke

Flotux

 

[ich777]

Hallo zusammen,
 
ich habe mir einen Share eingerichtet, der PDF-Dateien in Ordnern nach Jahren entfhält. Diesen möchte ich von Share aus auf eine Externe Festplatte sichern. Die Externe Festplatte ist mit Ex-Fat formatiert, damit ich die Dateien bei Bedarf auf einem MacOSX lesen kann.
 
Beim Sichern bekomme ich dann aber ziemlich oft folgende Fehlermelungen:
Failaid to set time on .. ... operation not permitet.
 
am Ende des Vorgangs heisst es dann "some files are not transfered .. code 23".
 
wir bekomme ich eine saubere Sicherung ?
 
Danke
Flotux
 

Nicht exFAT oder NTFS verwenden wäre die erste möglichkeit da die Dateisysteme nicht alle Attribite die zB ext4 oder xfs unterstützen speichern können.

Oder du gehst in die Optionen von der Synchronisierung in luckyBackup und schaltest die Erweiterten Ansicht an und wählst dort das dass Ziel ein FAT/NTFS Dateisystem ist, dann sollte dieses Problem gelöst sein.

Kopierst du vielleicht auch noch Dateien Ordner die root Rechte benötigen?
Standardmäßig läuft der Container nicht als root und diese Dateien können eventuell nicht kopiert/synchronisiert werden.

Sent from my C64

[mgutt]

23 hours ago, Flotux said:

Die Externe Festplatte ist mit Ex-Fat formatiert, damit ich die Dateien bei Bedarf auf einem MacOSX lesen kann.

Schau lieber wie man eine Ubuntu VM auf dem Mac startet, damit du Linux Dateisysteme verwenden kannst. Alternativ alles mit tar sichern.

[Flotux]

Danke werde ich mit ansehen und durchspielen.

[Cyanrider]

On 11/1/2021 at 6:59 PM, Flotux said:

Hallo zusammen,

 

ich habe mir einen Share eingerichtet, der PDF-Dateien in Ordnern nach Jahren entfhält. Diesen möchte ich von Share aus auf eine Externe Festplatte sichern. Die Externe Festplatte ist mit Ex-Fat formatiert, damit ich die Dateien bei Bedarf auf einem MacOSX lesen kann.

 

Beim Sichern bekomme ich dann aber ziemlich oft folgende Fehlermelungen:

Failaid to set time on .. ... operation not permitet.

 

am Ende des Vorgangs heisst es dann "some files are not transfered .. code 23".

 

wir bekomme ich eine saubere Sicherung ?

 

Danke

Flotux

 

 

Ist dir aufgefallen, dass dabei alle Quelldateien ihren Timestamp auf JETZT geändert haben?

Alle meine Dateien, die ich sorgfältig seit 2003 immer sauber umgezogen habe, haben nun einen Timestamp von 2022.

 

Danke an Unraid, Luckybackup und generell die Linux-Community für so einen Schwachsinn.

Ich hatte zudem noch die Angst, dass beim Synchronisieren einfach die Quelle gelöscht wird und alles weg ist. Das wäre es gewesen.

[ich777]

9 minutes ago, Cyanrider said:

Danke an Unraid, Luckybackup und generell die Linux-Community für so einen Schwachsinn.

Das hat eher was mit dem Filesystem zu tuhen, hast du das hier aktiviert und auch gelesen:

 

EDIT: Synchronisierst du denn auch auf FAT/NTFS? Wenn ja warum?

 

9 minutes ago, Cyanrider said:

Ich hatte zudem noch die Angst, dass beim Synchronisieren einfach die Quelle gelöscht wird und alles weg ist. Das wäre es gewesen.

Nein, wie du schon schreibst du Synchronisierst hier von Source -> Destination und verschiebst nicht.

[alturismo]

1 hour ago, Cyanrider said:

Danke an Unraid, Luckybackup und generell die Linux-Community für so einen Schwachsinn.

Ich hatte zudem noch die Angst, dass beim Synchronisieren einfach die Quelle gelöscht wird und alles weg ist. Das wäre es gewesen.

 

Dir ist schon klar dass ... 

 

Ich kriege Angst wenn Leute das lesen auch noch für voll nehmen ... also wenn Kritik, dann vielleicht auch mit etwas mehr Hintergrund was du gemacht hast und dann kann man Dir sicher oder eventuell auch helfen

[Cyanrider]

4 hours ago, ich777 said:

Das hat eher was mit dem Filesystem zu tuhen, hast du das hier aktiviert und auch gelesen:

 

EDIT: Synchronisierst du denn auch auf FAT/NTFS? Wenn ja warum?

 

Nein, wie du schon schreibst du Synchronisierst hier von Source -> Destination und verschiebst nicht.

Ja ich synchronisiere auf eine mit Unraid formatierte NTFS USB HDD, damit ich diese im Notfall schnell einfach an irgendeinen Rechner klemmen kann und dort kein Linux-Dateisystem läuft und ja ich habe diesen Haken gesetzt und vorhin erst das Popup gelesen, welches darauf hinweist.

 

Aber: Warum wird beim Sichern überhaupt die Quelle berührt? 😥

 

Ohne Backup vor dem Backup gibts keinen Trick um die Timestamps zurückzuholen oder? Irgendwelche versteckten DBs wo sowas noch gespeichert wird oder so? Ein "undo" von LuckyBackup oder so? 19 Jahre, alles "futsch".

[Cyanrider]

3 hours ago, alturismo said:

 

Dir ist schon klar dass ... 

 

Ich kriege Angst wenn Leute das lesen auch noch für voll nehmen ... also wenn Kritik, dann vielleicht auch mit etwas mehr Hintergrund was du gemacht hast und dann kann man Dir sicher oder eventuell auch helfen

 

Entschuldigung. Du hast vollkommen Recht aber in dem Fall dachte ich danach einfach:

Welchen Sinn hat so eine Option/Funktion. Welche beim Sichern/Synchronisieren das Erstell- sowie Änderungsdatum der Quelle bearbeitet.

 

Ich war schon so vorsichtig aber wohl nicht vorsichtig genug...

Absolut meine Schuld, weil ich noch mehr hätte testen müssen, dann wäre mir das mit den Timestamps vielleicht auch noch eingefallen, womit ich nie gerechnet hätte.

Ich sollte mehr zum gewöhnlichen "User" mutieren.

 

Gibt es irgendeinen Weg die Timestamps ohne Backup vor dem Backup wiederherzustellen? Irgendeine Datenbank oder sowas, von der ich nichts weiß, wo vielleicht diese Infos noch stecken?

 

Bei Fotos hätte ich eine Idee: Das Erstellungsdatum aus den Meta-Daten irgendwie als Datei-Erstellungs- bzw. letztes Änderungsdatum setzen. Geht mit FastStone Image Viewer aber da muss man alle Fotos "einzeln" auswählen. Ich würde gerne meinen ganzen Fotoordner damit einmal drüber laufen lassen, auch wenn das meinen Dokumenten, meiner Musik und meinen Videos nicht mehr hilft...

Edited March 8, 2022 by Cyanrider
doppelpunkt

[hawihoney]

12 minutes ago, Cyanrider said:

Warum wird beim Sichern überhaupt die Quelle berührt?

 

Kenne LuckyBackup nicht, aber viele Backup Programme setzen unter Windows das Archiv Bit der Quelle. Der Verursacher ist also evtl. die erzwungene Windows Kompatibilität von LuckyBackup und nicht Unraid.

 

Musste leicht schmunzeln da mir nach über 40 Jahren IT und gefühlt 10-15 Betriebssystemen immer mal wieder das Datum flöten ging. Deshalb heißen bei mir alle Dokumente "yyyymmdd Dateiname.ext" und Skripte patchen bei Bedarf das Datum.

 

Edited March 8, 2022 by hawihoney

[Cyanrider]

1 minute ago, hawihoney said:

 

Kenne LuckyBackup nicht, aber viele Backup Programme setzen unter Windows das Archiv Bit.

 

Musste leicht schmunzeln da mir nach über 40 Jahren IT und gefühlt 10-15 Betriebssystemen immer mal wieder das Datum flöten ging. Deshalb heißen bei mir alle Dokumente "yyyymmdd Dateiname.ext" und Skripte patchen bei Bedarf das Datum.

 

Ja, wie gesagt. Mir seit 2003 nicht passiert. Wieviele verschiedene PCs, DVDs, Betriebsssyteme, Dateisysteme, NAS-Laufwerke usw. diese Dateien überlebt haben... und nun sowas...

 

LuckyBackup = rsync mit GUI

 

Von Archiv Bit habe ich auch schon gelesen und gegoogelt aber das setzt ja nur einen Haken und enthält kein Datum, richtig?

 

Ich hätte doch lieber bei Unraid > abgespeckte Win10-VM > DirSync Pro bleiben sollen. War zwar völlig unnötig eine ganze Win10 VM nur für einen Backupjob für den Fileserver-Teil meines Unraid-Servers laufen zu haben aber es hat wenigstens sauber funktioniert. Never change a ...

 

Schade, dass es keine "Backup-App" von/für Unraid gibt.

 

[hawihoney]

15 minutes ago, Cyanrider said:

aber das setzt ja nur einen Haken und enthält kein Datum, richtig?

 

Würde mich nicht wundern wenn das Setzen des Archiv Bits in einem fehlerhaften Umfeld gleichzeitig das Setzen des Modification Date triggert. Vielleicht ist das einstellbar. Nur geraten ...

 

[Archonw]

Auf welchem Dateisystem waren lagen denn die Originale von denen aus synchronisiert wurde.

Und wie kamen sie dort hin? Sicher, dass das Datum erst durch LuckyBackup falsch gesetzt wurde?  

[hawihoney]

19 minutes ago, Cyanrider said:

DirSync Pro

 

Schau Dir mal die User Scripts an. Das Sichern ist total einfach mit rsync und Skripts. Ob USB, SMB, SSH - alles geht. Ist halt nicht klicki bunti bekommt trotzdem jeder hin.

 

Frag einfach.

 

[ich777]

1 hour ago, Cyanrider said:

Aber: Warum wird beim Sichern überhaupt die Quelle berührt? 😥

Die Quelle sollte eigentlich nicht berührt werden... Zumindest ist es bei mir nicht so, ich hab zwar noch nie versucht auf NTFS ein Backup zu machen aber das werd ich bei Gelegenheit mal ausprobieren.

 

57 minutes ago, hawihoney said:

Musste leicht schmunzeln da mir nach über 40 Jahren IT und gefühlt 10-15 Betriebssystemen immer mal wieder das Datum flöten ging. Deshalb heißen bei mir alle Dokumente "yyyymmdd Dateiname.ext" und Skripte patchen bei Bedarf das Datum.

Gute Entscheidung, hab ich auch so.

 

1 hour ago, Cyanrider said:

Gibt es irgendeinen Weg die Timestamps ohne Backup vor dem Backup wiederherzustellen? Irgendeine Datenbank oder sowas, von der ich nichts weiß, wo vielleicht diese Infos noch stecken?

Normalerweise nicht, das Problem ist hier immer Windows, NTFS bzw. FAT unterstützt nicht so viele Attribute wie ein Linux Dateisystem.

 

47 minutes ago, Cyanrider said:

Ich hätte doch lieber bei Unraid > abgespeckte Win10-VM > DirSync Pro bleiben sollen. War zwar völlig unnötig eine ganze Win10 VM nur für einen Backupjob für den Fileserver-Teil meines Unraid-Servers laufen zu haben aber es hat wenigstens sauber funktioniert. Never change a ...

Mach doch einfach eine XFS Disk, die kannst unter Umständen auch unter Windows auslesen und wenn du ein Backup zurückspielen willst wäre es sowieso besser du mountest die Platte dann direkt in Unraid und spielst das Backup zurück, dann hast du keinen Overhead vom Netzwerk und das kopieren funktioniert generell schneller.

 

48 minutes ago, Cyanrider said:

Schade, dass es keine "Backup-App" von/für Unraid gibt.

CA Backup wäre eine möglichkeit, kannst auch einen Benutzerdefinierten Ordner hinzufügen wenn ich mich nicht täusche.

 

32 minutes ago, hawihoney said:

Würde mich nicht wundern wenn das Setzen des Archiv Bits in einem fehlerhaften Umfeld gleichzeitig das Setzen des Modification Date triggert. Vielleicht ist das einstellbar. Nur geraten ...

Aber sollte das nicht nur die Destination sprich das Ziel beeinflussen?

[Archonw]

Ich bin auch der Meinung, dass die Quelle schon vorher fehlerhaft war.

[Cyanrider]

35 minutes ago, Archonw said:

Auf welchem Dateisystem waren lagen denn die Originale von denen aus synchronisiert wurde.

Und wie kamen sie dort hin? Sicher, dass das Datum erst durch LuckyBackup falsch gesetzt wurde?  

 

Unraid xfs

Ja, ganz sicher. So sieht es auf meinen ganzen Shares aus, die vom Backup-Job betroffen waren. Ich arbeite immer mit "nach Änderungsdatum" sortieren im Windows-Explorer. Deswegen fällt mir sowas dann auf.

[Cyanrider]

3 minutes ago, Archonw said:

Ich bin auch der Meinung, dass die Quelle schon vorher fehlerhaft war.

Sorry aber wie kommst du denn darauf?

Wie gesagt: Ich arbeite immer mit Änderungsdatum in Windows. Sowas fällt sofort auf.

Was soll denn da vorher fehlerhaft gewesen sein?

[Cyanrider]

13 minutes ago, ich777 said:

Mach doch einfach eine XFS Disk, die kannst unter Umständen auch unter Windows auslesen und wenn du ein Backup zurückspielen willst wäre es sowieso besser du mountest die Platte dann direkt in Unraid und spielst das Backup zurück, dann hast du keinen Overhead vom Netzwerk und das kopieren funktioniert generell schneller.

 

CA Backup wäre eine möglichkeit, kannst auch einen Benutzerdefinierten Ordner hinzufügen wenn ich mich nicht täusche.

 

Aber sollte das nicht nur die Destination sprich das Ziel beeinflussen?

Ja das mit der XFS Disk ist ja nun auch zu spät. Die Vorteile von NTFS hatte ich ja vorhin genannt (Plug&Play für einen schnellen Restore-Zugriff auf einem beliebigen Windows-System).

Tatsächlich hatte ich die Platte direkt in Unraid gemountet und als NTFS formatiert. Unraid unterstützt das also auch ohne Probleme.

 

CA Backup? Ich kenne nur CA Appdata Backup. Das sichert nur Appdata aber keine Shares.

 

Fakt ist ja anscheinend, dass man es nicht ändern kann. Also egal.

 

Trotzdem: Vielen Dank für die schnelle Reaktion und Anteilnahme. Tolle Community 😊

[Archonw]

Das ist wirklich merkwuerdig. Muss ich bei mir doch mal auch nach sehen. 

Ich sehe keine Grund, warum  rsync etwas an den Quelldaten aendern sollte. Es arbeitet soweit ich weis nicht mit Archiv Bits, sondern vergelich den Datumsstempel.

 

Wie sind denn die Qriginale auf die XFS Partition gekommen? 

Ich wurde bisher immer noch vermuten, dass das Datum da nicht ordentlich mit uebernommen worden ist.

Edited March 8, 2022 by Archonw

[Cyanrider]

2 minutes ago, Archonw said:

Das ist wirklich merkwuerdig. Muss ich bei mir doch mal auch nach sehen. 

Ich sehe keine Grund, warum  rsync etwas an den Quelldaten aendern sollte. Es arbeitet soweit ich weis nicht mit Archiv Bits, sondern vergelich den Datumsstempel.

 

Wie sind denn die Qriginale auf die XFS Partition gekommen? 

Ich wurde bisher immer noch vermuten, dass das Datum da nicht ordentlich mit uebernommen worden ist.

rsync fasst wohl gerne die Quelldaten an: https://serverfault.com/questions/456368/how-to-tell-rsync-not-to-touch-the-destination-directory-permissions

Außerdem scheint es ja an der Option zu liegen, die ich gesetzt habe: 

 

Die Originale sind damals von einem Synology Dateisystem auf eine NTFS USB Platte kopiert worden um anschließend dann wieder auf die neuen Shares in Unraid kopiert zu werden. Das ist nun auch schon Jahre her und hat bisher prima funktioniert. Die Timestamps wurden von LuckyBackup gesetzt. Kein Zweifel. Auch mein voriger Testjob beweist das. Verstehe daher diese Zweifel garnicht.

 

Habe ja auch unwichtige Daten/Shares nicht gesichert, diese haben ja auch noch ihre richtigen Timestamps behalten.

[ich777]

11 minutes ago, Cyanrider said:

rsync fasst wohl gerne die Quelldaten an: https://serverfault.com/questions/456368/how-to-tell-rsync-not-to-touch-the-destination-directory-permissions

Aber gehts hier nicht um die Destination also das Ziel?

 

11 minutes ago, Cyanrider said:

Außerdem scheint es ja an der Option zu liegen, die ich gesetzt habe: 

Das sollte auch nur die Destination betreffen.

 

12 minutes ago, Cyanrider said:

Verstehe daher diese Zweifel garnicht.

Ich muss das mal testen wenn ich Zeit habe.

 

24 minutes ago, Cyanrider said:

Tatsächlich hatte ich die Platte direkt in Unraid gemountet und als NTFS formatiert. Unraid unterstützt das also auch ohne Probleme.

Das schon aber NTFS kann bzw. ist unter Linux langsam(er) und es gibt auch Software mit der du zB ext3, ext4, XFS und BTRFS mounten kannst, auch Plug and Play.

 

Wenn du schon unter Linux arbeitest würd ich dir eher als Backup medium ein Linux Dateisystem zu verwenden und dann vermeidest du auch solche Sachen.

 

33 minutes ago, Cyanrider said:

Wie gesagt: Ich arbeite immer mit Änderungsdatum in Windows. Sowas fällt sofort auf.

Wie siehts mit dem Erstellungsdatum aus, wurde das auch geändert?

[Archonw]

Die Option besagt doch Destination.  Also im Ziel werden die Benutzerrechte nicht uerbenommen. Das kann ich auch nachvollziehen.

 

Nur was die Quelle betrifft da bin ich verwundert. Auch der Link von dir beschreibt eben das Ziel.

Rsync greift meines wissens im Original nur lesend zu. 

Ich muss mir noch mal Lucky Backup anschauen, ob man da noch irgendwo dafuer eine Einstellung treffen kann....

 

 

[mgutt]

6 hours ago, Cyanrider said:

Ist dir aufgefallen, dass dabei alle Quelldateien ihren Timestamp auf JETZT geändert haben?

Alle meine Dateien, die ich sorgfältig seit 2003 immer sauber umgezogen habe, haben nun einen Timestamp von 2022.

Oha. Kann deinen Ärger absolut nachvollziehen. Ein Backup Tool, dass die Quelldateien verändert, geht ja gar nicht. Wobei ich das nicht verstehe, weil Lucky Backup doch rsync nutzt und rsync ändert ja auch nicht einfach die Quelle?!

 

[mgutt]

Nachdem ich diesen Thread gelesen habe, würde ich sagen, dass folgendes passiert ist:

- rsync hat auf die Dateien zugegriffen und dabei wurde die Zugriffszeit der Quelldatei aktualisiert, was ja normal ist

- eine fehlerhafte Schnittstelle / Hardware / Treiber hat dann das Änderungsdatum aktualisiert

 

Es könnte zb ein fehlerhafter USB Adapter sein, falls die Platte per USB angeschlossen ist. Oder innerhalb vom LuckyBackup Container wird beim Mounten des Ex-Fat Laufwerks ein Treiber verwendet, der fehlerhaft ist. Vielleicht veraltet?!

 

Was auch immer die Ursache war. Wenn das Datum weg ist, dann ist es weg. Bliebe nur noch die Hoffnung auf anderem Weg an das Datum zu kommen. Bei PDFs könnte was im Text stehen wie zb auch bei Word-Dateien. Bei Fotos gäbe es die EXIF Daten. Bei Videos hätte man dagegen keine Chance.