Datensicherung - Probleme mit LuckyBackup


Flotux

Recommended Posts

  

28 minutes ago, ich777 said:

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.

 

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

Ok. Werde es dann bei der nächsten Gelegenheit auf ein Linuxdateisystem ändern. Welche Empfehlung würdest du aussprechen?

 

Erstellungsdatum wurde ebenfalls geändert. Wurde alles auf "jetzt" gesetzt. Also die Zeit wann die Datei vom Backup angefasst wurde.

Link to comment
2 hours ago, ich777 said:

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

 

Nee. Das Archiv Bit der Quelle wird gesetzt - nicht des Ziels. Mir fiel beim Lesen dieses Threads ein, dass mir das im letzten Jahrhundert bei der Verwendung von XCOPY aufgefallen war. Ich meine, dass auch ZIP so etwas machte. Sobald die Tools eine Archiv Option besitzen, fummeln die an der Quelle rum. Wie es heute ist weiß ich nicht. Ich wette aber das sich daran nix geändert hat.

 

  • Confused 1
Link to comment

@Cyanrider mach mal bitte zum Beispiel bei einem oder mehreren files stat ... am Besten wo du sicher bist dass die auch älter oder jünger sind

 

root@AlsServer:/mnt/cache/Media/TVRIPS/The Walking Dead/Season 11# stat The\ Walking\ Dead\ -\ S11E01\ -\ Acheron\,\ Part.mkv
  File: The Walking Dead - S11E01 - Acheron, Part.mkv
  Size: 2290934625      Blocks: 4474496    IO Block: 4096   regular file
Device: 259,1   Inode: 1075655264  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2021-08-23 06:52:55.000000000 +0200
Modify: 2021-08-23 06:53:05.000000000 +0200
Change: 2021-08-23 06:53:28.157227895 +0200
 Birth: 2021-08-23 06:52:55.629852143 +0200
root@AlsServer:/mnt/cache/Media/TVRIPS/The Walking Dead/Season 11#

 

vielleicht kann man was basteln ...

Link to comment
48 minutes ago, Cyanrider said:

Leider ja

Kannst du mal ins Terminal von Unraid gehen dann navigierst du zu deim entsprechneden Ordner, sowas wie das sollte funktionieren:

cd /mnt/user/SHARENAME/UNTERORDNER

(natürlich musst du SHARENAME mit dem Ordnernamen und UNTERORDNER mit dem entsprechenden Unterordner ersetzen wenn du denn einen hast)

 

und dann machst du:

stat EINDATEINAME

(wobei du wieder EINDATEINAME mit einem Dateinamen ersetzt)

 

und poste bitte den Output hier, man kann das geändert Datum theoretisch mit einem Skript wieder ändern wenn das Birth date stimmt beispielsweise, aber ich schätze mal nicht das es stimmt weil es wahrscheinlich dem Datum entspricht an dem du es von deiner Synology kopiert hast, kann aber auch falsch liegen.

  • Like 1
Link to comment
9 hours ago, ich777 said:

Kannst du mal ins Terminal von Unraid gehen dann navigierst du zu deim entsprechneden Ordner, sowas wie das sollte funktionieren:

cd /mnt/user/SHARENAME/UNTERORDNER

(natürlich musst du SHARENAME mit dem Ordnernamen und UNTERORDNER mit dem entsprechenden Unterordner ersetzen wenn du denn einen hast)

 

und dann machst du:

stat EINDATEINAME

(wobei du wieder EINDATEINAME mit einem Dateinamen ersetzt)

 

und poste bitte den Output hier, man kann das geändert Datum theoretisch mit einem Skript wieder ändern wenn das Birth date stimmt beispielsweise, aber ich schätze mal nicht das es stimmt weil es wahrscheinlich dem Datum entspricht an dem du es von deiner Synology kopiert hast, kann aber auch falsch liegen.

Ich find's bisschen fies, dass mir hier nicht geglaubt wird und dass wir damit jetzt unsere Zeit damit verschwenden, zu beweisen, dass es nicht an früheren Kopiervorgängen lag:

Nochmal:

 

1. Der Umzug vom Synology zum Unraid war damals super erfolgreich. Ich war froh und hab damals genau davor Angst gehabt und genau das überprüft, weil ich eben immer auf das Änderungsdatum achte und damit arbeite. <<< (Das soll hier auch gar nicht das Thema sein)

2. Kann ich es beweisen, weil ich nicht alles gesichert und unwichtige Dateien und Verzeichnisse ausgeschlossen habe, die damals beim Umzug ja auch übertragen worden sind. Mit denen ist alles in Ordnung, weil diese nicht von Luckybackup bzw. rsync berührt wurden.

3. Zweiter Beweis durch Wiederholung des Jobs jederzeit möglich.

 

Das Erstellungsdatum wurde wie bereits oben geschrieben genau wie das Änderungsdatum von Luckybackup überschrieben.

 

Hier das Beispiel Anhand einer alten Datei die leider von LuckyBackup misshandelt wurde. Sie hatte vorher das Datum 14.02.2007 (kann ich auf einem alten unbrauchbaren Chaosbackup sehen):

 

  File: mathe.docx
  Size: 15040           Blocks: 32         IO Block: 4096   regular file
Device: 30h/48d Inode: 648799827789915136  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2022-03-08 05:27:57.462093599 +0100
Modify: 2022-03-08 04:42:26.048396300 +0100
Change: 2022-03-08 05:27:57.462093599 +0100
 Birth: -

 

Link to comment
41 minutes ago, Cyanrider said:

Hier das Beispiel Anhand einer alten Datei die leider von LuckyBackup misshandelt wurde. Sie hatte vorher das Datum 14.02.2007 (kann ich auf einem alten unbrauchbaren Chaosbackup sehen):

 

ok, dann sorry ... da können wir auch nicht schnell ein script basteln und retour setzen auf ein "altes" Datum ... da ist ja alles neu ...

Link to comment
6 minutes ago, mgutt said:

Warum ist das unbrauchbar? Wenn es korrekte Änderungsdaten hat, könnte man was Skripten was nur das Datum über-nimmt.

Ja? Ok. Das klingt nach einem Plan. Sind halt einzelne Ordner verteilt auf verschiedene Festplatten. 

 

So ein Script wäre interessant. 

Link to comment
48 minutes ago, Cyanrider said:

Ich find's bisschen fies, dass mir hier nicht geglaubt wird und dass wir damit jetzt unsere Zeit damit verschwenden, zu beweisen, dass es nicht an früheren Kopiervorgängen lag

Entschuldigung bitte, aber wir wollen dir hier helfen und du brauchst uns nichts zu beweisen.

Mir ist es eigentlich darum gegangen ob das Birth date gepasst hätte weil dann hätte man mit einem Script das Ursprüngliche Datum wiederherstellen können.

Link to comment
Just now, Cyanrider said:

Ja? Ok. Das klingt nach einem Plan. Sind halt einzelne Ordner verteilt auf verschiedene Festplatten. 

Du könntest auch auf XFS sichern, damit könntest du den Haken raus geben in luckyBackup und das Problem wäre gelöst, von Paragon gibt es übrigens eine Software mit denen du Linux Dateisysteme auf Windows mounten kanns (Plug and Play).

 

Aber wenn du wirklich mal ein Backup wiederherstellen müsstest dann würd ich das wie oben geschrieben direkt auf Unraid machen und nicht über Windows.

Link to comment
14 minutes ago, ich777 said:

Entschuldigung bitte, aber wir wollen dir hier helfen und du brauchst uns nichts zu beweisen.

Mir ist es eigentlich darum gegangen ob das Birth date gepasst hätte weil dann hätte man mit einem Script das Ursprüngliche Datum wiederherstellen können.

Ok. Sorry & Danke nochmal. 

Link to comment
12 minutes ago, ich777 said:

Du könntest auch auf XFS sichern, damit könntest du den Haken raus geben in luckyBackup und das Problem wäre gelöst, von Paragon gibt es übrigens eine Software mit denen du Linux Dateisysteme auf Windows mounten kanns (Plug and Play).

 

Aber wenn du wirklich mal ein Backup wiederherstellen müsstest dann würd ich das wie oben geschrieben direkt auf Unraid machen und nicht über Windows.

Dann formatiere ich die USB Backup HDD nun in XFS und wiederhole den Backup-Job. 

 

Paragon Linux File Systems for Windows kann XFS und Btrfs nur lesen. 

 

Schreiben ist nur auf Ext2, 3 und 4 möglich. 

Darf ich die USB-HDD dann auch in Ext formatieren? Wenn ja, welches am Besten?

Link to comment

Nicht getestet, sollte aber denke ich gehen:

 

# Einstellungen
share_pfad="/mnt/user/<sharename>"
backup_pfad="/mnt/disks/<diskid>"
# alle Dateien aus einem Share durcharbeiten
while IFS= read -r -d '' datei; do
  dateiname=$(basename "$datei")
  # zaehlen ob dieser Dateiname auf der Backup-Disk nur 1x vorkommt
  while IFS= read -r -d '' backupdatei; do
    if [[ $einzigartig ]]; then
      unset einzigartig
      break
    fi
    einzigartig=1
  done < <(find "$backup_pfad" -type -f -name "$dateiname" -print0)
  # der Dateiname wurde nur 1x gefunden, also koennen wir das Dateidatum uebernehmen
  if [[ $einzigartig ]]; then
    echo "$datei erhaelt das Datum von $backupdatei"
    touch --reference="$backupdatei" "$datei"
    unset einzigartig
  # der Dateiname wurde leider haeufiger gefunden und wird uebersprungen
  else
    echo "$dateiname wurde leider haeufiger in $backup_pfad gefunden"
  fi
done < <(find "$share_pfad" -type -f -print0)

 

backup_pfad entsprechend der gemounteten Backup-Disk setzen.

 

 

Wie man sieht sucht das Skript nur nach dem Dateinamen. Wenn Dateinamen doppelt vorkommen, überspringt der die Datei. Man könnte dann noch darüber nachdenken den kompletten Pfad zu vergleichen, vorausgesetzt die Dateien liegen im Backup in der selben Ordnerstruktur.

 

 

  • Thanks 2
Link to comment
1 minute ago, ich777 said:

kann aber nur lesen oder

Jo

 

1 minute ago, ich777 said:

kann nativ unter Windows lesen bzw. die ext Dateisysteme auch schreiben und ist auch günstiger.

Dank WSL kann Windows mittlerweile auch ext4, muss man aber über die Kommandozeile einbinden.

  • Thanks 1
Link to comment
  • 5 weeks later...

ext geht ja so direkt in Unraid über Unassigned Devices nicht zu formatieren. Ich probiere mal exFAT bevor ich XFS nehme. Hat Alex von den GeekFreaks auch gerade gesagt.

image.png.64d89aab9c39872bda4ca66dc9001339.png

 

 

 

edit:

Mit exFAT gibts auch nur haufenweise Errors. Entweder werden nur die Ordner gesynct und der Inhalt ist leer (rsync: [generator] chgrp failed: Operation not permitted (1))

oder es werden wieder die Daten der Quelle verändert.

Mit XFS laufen die Backup-Jobs nun ohne Errors im Log!

Edited by Cyanrider
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.