Schnell und sicher backup erstellen

ich schaue mal dass ich ein paar kleine jobs jedes Typs zusammengebaut kriege...

Zitat von Mavalok2

Du könntest anstelle SMB mal NFS versuchen

Guter Tipp. Hatte ich nicht mehr auf dem Schirm. Eben auf der QNAP nachgesehen. NFS wird mir unter Synchronisierung nur nicht angeboten. rsync und SMB/CIFS stehen zur Auswahl.

Und ja, wenn ich eine zweite QNAP hätte würde ich vermutlich auch RTRR nehmen.

Wesentlich einfacher und den Posts hier entnehme ich, daß es wohl auch funktioniert.

Muß aber mit jeweils einer QNAP und einer Syno zurechtkommen.

Zitat von tiermutter

ich schaue mal dass ich ein paar kleine jobs jedes Typs zusammengebaut kriege...

Danke Dir. Crazyhorse hat mir schon die Links zu älteren Versionen gegeben.

Habe aber das ungute Gefühl, daß es daran nicht liegt.

So, der Morgen war ruhig und ich habe mal neben meinen laufenden RTRR Jobs auch RSYNC, FTP und CIFS/SMB probiert.

Ich wusste jetzt nicht welche Backup Station Du verwendest, kann es ja aber ohnehin nur mit nachfolgenden Versionen testen...

Alles als manuelle Ein-Weg-Sync von einer TS-453A 4.4.3.1354 (HBS 3.0.200727) auf eine TS-131 4.3.6.1333 (HBS 2.1.190909).

RTRR läuft mit mehreren Jobs auch zu einem anderen QNAP seit jeher problemlos (zumindest was die Problematik unveränderter Daten angeht ).

Anbei die Ergebnisse... getestet wurde jeweils nach den initialen Jobs einmal ohne jegliche Dateiänderungen und einmal mit 2 neuen Dateien,

wobei es hierbei erwartungsgemäß keinen Unterschied gab.

RSYNC: (Speicher angelegt als RSYNC-kompatibler Server)

1) ohne Richtlinie "Dateiinhalte prüfen" rattert er alle bereits vorhandenen Daten rüber.

2) mit Richtlinie "Dateiinhalte prüfen" werden entsprechende Daten übersprungen.

Spielereien mit weiteren Richtlinien (TCP-BBR Kontrolle, kein Snapshot aufnehmen, Dateien im Zielordner entfernen) haben wie erwartet auch keine Besserung bewirkt, aber man muss ja alle Register ziehen.

RSYNC: (Speicher angelegt als NAS-basierter RSYNC Server)

1) ohne Richtlinie "Dateiinhalte prüfen" rattert er auch hier alle bereits vorhandenen Daten rüber.

2) mit Richtlinie "Dateiinhalte prüfen" werden entsprechende Daten auch hier übersprungen.

FTP: _{(hiervon war bislang gar nicht die Rede, oder?)}

die Richtlinie "Dateiinhalte prüfen" gibt es hier nicht, vorhandene Dateien werden übersprungen.

CIFS/SMB:

die Richtlinie "Dateiinhalte prüfen" gibt es hier nicht, vorhandene Dateien werden übersprungen.

Da die Jobs ja nun angelegt sind kann ich gerne noch weitere Optionen/ Richtlinien testen.

Als Anhang eine Auswahl an Screenshots von den Job-Berichten (initial und ohne Dateiänderung) für eventuelle Vergleiche etc.,

ich hoffe die Dateinamen / Beschriftung ist selbstredend.

Edit/ Nachtrag zwecks Vollständigkeit:

Meine laufenden RTRR Ein-Weg Sync Jobs (sowie Backup Jobs) überspringen vorhandene Dateien auch ohne "Dateiinhalte prüfen".

Also so wie ich es eigentlich erwarte. Und im zweiten Nachtrag noch um einen Screenshot vom RTRR Job ergänzt...

Wow, vielen Dank für Deine umfangreichen Tests. Die haben mich ein Stück weitergebracht.

Ich war auch nicht untätig. Ich habe wechselweise die Versionen von Crazyhorse durchprobiert.

Keine der Versionen hat das Problem lösen können. Wie ich bereits vermutete, muß der Fehler woanders liegen.

Ich habe mittlerweile aber neue Erkenntnisse gewonnen.

Jobs mit Filmen zum Beispiel, Dokumenten oder Bildern funktionieren wie erhofft. Es werden nur geänderte/neue Dateien auf das Ziel geschoben. Und jetzt wird es merkwürdig.

Mein Proxmox sichert ja die VMs auf die QNAP. Diese Verzeichnis wird zur Sicherheit nochmal auf eine Syno gesichert (Ein-Weg-Sync via cIFS).

Im Log sieht das so aus:

[2020/08/11 00:44:04] Job [DS415_Proxmox] started.

[2020/08/11 00:44:04] Synchronize files from a local folder to a remote folder.

[2020/08/11 00:44:04] Server IP address: 10.1.1.14, port number 0.

[2020/08/11 00:44:04] The SSL connection option is disabled.

[2020/08/11 00:44:04] The number of folder pairs = 1.

[2020/08/11 00:44:04] Pair1 = [Proxmox, /mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/].

[2020/08/11 00:44:04] Schedule type: Manually.

[2020/08/11 00:44:04] The deleting extra files option is enabled.

[2020/08/11 00:44:04] The checking data content option is disabled.

[2020/08/11 00:44:04] The detecting sparse files option is disabled.

[2020/08/11 00:44:04] The extended attributes option is disabled.

[2020/08/11 00:44:04] Symbolic link files are included.

[2020/08/11 00:44:04] The detail log is enabled with the maximum size 10 MB.

[2020/08/11 00:44:04] Use network adapter eth0 (10.1.1.12) for outgoing traffic.

[2020/08/11 00:44:04] Maximum retry times: 5; Retry interval in seconds: 180; Connection timeout in seconds: 60; Current retry number: 0.

[2020/08/11 00:44:05] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_11-00_39_11.log".

[2020/08/11 00:44:21] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_11-00_39_11.vma.zst".

[2020/08/11 00:44:21] Finished synchronizing.

[2020/08/11 00:44:21] Sync statistic: Total number of the folders: 11. Total number of the files: 28. Total updated size: 1.25 GB. Average updating speed: 79.97 (MB/sec). Time elapsed: 16 seconds

[2020/08/11 00:44:25] Job finished.

Wenn ich diesen Job unmittelbar nach Fertigstellung erneut starte wird wieder alles gesichert. Es wurden keinerlei neue Dateien hinzugefügt oder geändert. Es muß also irgendwie mit den Daten von Proxmox zu tun haben. Wenn das bitte wer gegentesten will, erstelle ich gerne einen Link zum Download. Einmal die *.log und *.vma.zst

Zitat von rednag

Wenn das bitte wer gegentesten will, erstelle ich gerne einen Link zum Download. Einmal die *.log und *.vma.zst

Klar, schick mal was rüber, eventuell kriege ich das heute noch hin...

Ich zumindestest habe keine Proxmox Daten zu sichern. Die einzige VM die ich sichere ist eine ca. 44GB *.img, läuft wie es soll... nur um noch ein paar Infos einzuwerfen

Sende mir die auch mal, ich habe hier ein paar VMware Maschinen die sich vom PC auf das NAS schreibe und dann über den RTRR Job weg sicher.

Gff. gibts mit dem Dateityp ja generell ein Problem.

Hallo liebe Leute. Danke für die Unterstützung.

Ich mach ein paar Dateien fertig und würde den Download-Link per PN an euch schicken.

Anbei die vorläufigen Ergebnisse aus meinen Tests... ich habe aktuell nur mit dem ca. 4GB großen VM-Datensatz getestet, dieser liegt in einem eigenen Ordner.

Eigentlich kann ich es kurz machen, das Ergebnis ist das selbe wie bei den vorherigen Tests, demnach als Zusammenfassung Copy + Paste:

RSYNC: (Speicher angelegt als RSYNC-kompatibler Server)

1) ohne Richtlinie "Dateiinhalte prüfen" rattert er alle bereits vorhandenen Daten rüber.

2) mit Richtlinie "Dateiinhalte prüfen" werden entsprechende Daten übersprungen.

RSYNC: (Speicher angelegt als NAS-basierter RSYNC Server)

1) ohne Richtlinie "Dateiinhalte prüfen" rattert er auch hier alle bereits vorhandenen Daten rüber.

2) mit Richtlinie "Dateiinhalte prüfen" werden entsprechende Daten auch hier übersprungen.

FTP:

die Richtlinie "Dateiinhalte prüfen" gibt es hier nicht, vorhandene Dateien werden übersprungen.

CIFS/SMB:

die Richtlinie "Dateiinhalte prüfen" gibt es hier nicht, vorhandene Dateien werden übersprungen.

Scheint bis dahin so als würden die Proxmox Daten nicht dafür verantwortlich sein.

Ich werde gleich nochmal alle 3 Datensätze in einem Job testen...

Edit:

Alle 3 Datensätze in einem Job per RSYNC und "Dateiinhalte prüfen" endet ebenfalls darin, dass unveränderte Daten übersprungen werden.

Ok, ich kann es nicht mehr nachvollziehen warum es bei mir nicht geht.

Andere Ordner für welche Backup-Jobs angelegt sind, funktionieren mit Übergehung der Daten welche schon am Ziel liegen.

Ich hab die Tage etliche Szenarien durchgespielt. Nun gehen mir die Ideen aus.

Ach ja, heute wäre eigentlich Telefonkonferenz mit QNAP angedacht gewesen. Gemeldet hat sich keiner, das Ticket ist auch nicht geändert/beanrbeitet worden.

Anbei noch das Log:

[2020/08/12 07:15:05] Job [DS415_Proxmox] started.
[2020/08/12 07:15:05] Synchronize files from a local folder to a remote folder.
[2020/08/12 07:15:05] Server IP address: 10.1.1.14, port number 0.
[2020/08/12 07:15:05] The SSL connection option is disabled.
[2020/08/12 07:15:05] The number of folder pairs = 1.
[2020/08/12 07:15:05] Pair1 = [Proxmox, /mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/].
[2020/08/12 07:15:05] Schedule type: Manually.
[2020/08/12 07:15:05] The deleting extra files option is enabled.
[2020/08/12 07:15:05] The checking data content option is disabled.
[2020/08/12 07:15:05] The detecting sparse files option is disabled.
[2020/08/12 07:15:05] The extended attributes option is disabled.
[2020/08/12 07:15:05] Symbolic link files are included.
[2020/08/12 07:15:05] The detail log is enabled with the maximum size 10 MB.
[2020/08/12 07:15:05] Use network adapter eth0 (10.1.1.12) for outgoing traffic.
[2020/08/12 07:15:05] Maximum retry times: 5; Retry interval in seconds: 180; Connection timeout in seconds: 60; Current retry number: 0.
[2020/08/12 07:15:06] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_11-05_30_02.log".
[2020/08/12 07:15:06] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-lxc-250-2020_08_11-05_30_25.log".
[2020/08/12 07:15:27] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_11-05_30_02.vma.lzo".
[2020/08/12 07:16:17] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-lxc-250-2020_08_11-05_30_25.tar.lzo".
[2020/08/12 07:16:17] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-260-2020_08_11-05_32_01.log".
[2020/08/12 07:16:17] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-270-2020_08_11-05_37_58.log".
[2020/08/12 07:23:36] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-260-2020_08_11-05_32_01.vma.lzo".
[2020/08/12 07:23:36] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-275-2020_08_11-05_46_13.log".
[2020/08/12 07:30:56] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-270-2020_08_11-05_37_58.vma.lzo".
[2020/08/12 07:38:15] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-275-2020_08_11-05_46_13.vma.lzo".
[2020/08/12 07:38:15] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-320-2020_08_11-05_58_37.log".
[2020/08/12 07:45:56] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-280-2020_08_11-05_52_19.vma.lzo".
[2020/08/12 07:45:56] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-340-2020_08_11-06_05_40.log".
[2020/08/12 07:54:07] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-320-2020_08_11-05_58_37.vma.lzo".
[2020/08/12 07:54:07] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-350-2020_08_11-06_11_33.log".
[2020/08/12 07:58:33] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-340-2020_08_11-06_05_40.vma.lzo".
[2020/08/12 07:58:33] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_12-05_30_02.log" file.
[2020/08/12 08:08:06] Update file "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-350-2020_08_11-06_11_33.vma.lzo".
[2020/08/12 08:08:06] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-lxc-250-2020_08_12-05_30_25.log" file.
[2020/08/12 08:08:26] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-205-2020_08_12-05_30_02.vma.lzo" file.
[2020/08/12 08:09:14] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-lxc-250-2020_08_12-05_30_25.tar.lzo" file.
[2020/08/12 08:09:14] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-260-2020_08_12-05_32_03.log" file.
[2020/08/12 08:09:14] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-270-2020_08_12-05_37_59.log" file.
[2020/08/12 08:16:31] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-260-2020_08_12-05_32_03.vma.lzo" file.
[2020/08/12 08:16:31] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-275-2020_08_12-05_46_15.log" file.
[2020/08/12 08:23:47] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-270-2020_08_12-05_37_59.vma.lzo" file.
[2020/08/12 08:23:47] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-280-2020_08_12-05_52_16.log" file.
[2020/08/12 08:31:01] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-275-2020_08_12-05_46_15.vma.lzo" file.
[2020/08/12 08:31:01] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-320-2020_08_12-05_58_36.log" file.
[2020/08/12 08:38:37] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-280-2020_08_12-05_52_16.vma.lzo" file.
[2020/08/12 08:38:37] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-340-2020_08_12-06_05_39.log" file.
[2020/08/12 08:46:47] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-320-2020_08_12-05_58_36.vma.lzo" file.
[2020/08/12 08:46:47] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-350-2020_08_12-06_11_38.log" file.
[2020/08/12 08:51:11] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-340-2020_08_12-06_05_39.vma.lzo" file.
[2020/08/12 09:00:41] Create the "mnt/RTRR_CIFS/10.1.1.14/user/NetBackup/Proxmox/dump/vzdump-qemu-350-2020_08_12-06_11_38.vma.lzo" file.
[2020/08/12 09:00:41] Finished synchronizing.
[2020/08/12 09:00:41] Sync statistic: Total number of the folders: 11. Total number of the files: 62. Total updated size: 508.62 GB. Average updating speed: 82.78 (MB/sec). Time elapsed: 1 hour 45 minutes 35 seconds
[2020/08/12 09:00:46] Job finished.

Die "Update" Files liegen schon am Ziel. Man sieht anhand der Zeitstempel, daß nochml übertragen wird.

Die "Created" sind neu, soweit in Ordnung. Die sollen ja übertragen werden. Aber nicht die Dateien welche schon am Ziel vorliegen...

Hier passiert das nicht, er erkennt die Dateien immer:

pasted-from-clipboard.png

Auch wenn ich eine neu entpackt haben und auf NAS übertragen habe, war die für den Job noch immer identisch.

Auch eine Änderung des Names und Änderung zurück hat nicht dazu geführt, das die Datei noch mal übertragen wurde.

Bennen ich die Datei (die 1.6GB wurden verwende) auf beiden Seite um, also Quell NAS und BU NAS, wird die auch nicht übertragen.

Hier muss also irgendwas dafür sorgen, das auf dem aktiven Part bei dir der falsche HASH ankommt.

Und er dann denkt, oh die ist anders, die muss ich neu übertragen.

Gibt es Infos welche RSYC Version QNAP und Synlology implementiert haben.

Nicht das hier verschiedene Versionen unterwegs sind, die ab einer gewissen Dateigröße einen anderen Wert übergeben, da der alte Standard z.B. keine Dateien über xGB sauber unique Hashen konnte.

Und so was fällt dir jetzt hier auf die Füße.

pasted-from-clipboard.png

5 ist die Namensänderung und 6 ist ein Durchlauf, bei der ich mit einem Hex Editor an 2 Stellen was geändert habe.

Bei dir dreht also der Part mit den Prüfsummen total am Rad.

Ich habe jetzt auf meiner Be den Client laufen und auf dem 231p den Server.

Da berechnet bei mir also der Server die Prüfsummen sauber und mein Client versteht diese richtig und interpretiert da keinen Mist rein.

Danke für die Rückmeldung.

Derzeit habe ich rsync nicht mehr am laufen, sondern SMB/CIFS. Ändert aber auch nichts daran.

Gut, wir haben das Problem also auf "lokal" eingegrenzt.

Ich stehe im Moment echt an. Ich weiß nicht was ich noch prüfen oder ändern sollte.

Ich verstehe das "Update File" nicht. Das passiert auch wenn ich unmittelbar nach Fertigstellen des Jobs erneut auf "Synchronisieren" klicke. Da geht die Rödelei wieder von vorne los.

Zitat von Crazyhorse

Hier muss also irgendwas dafür sorgen, das auf dem aktiven Part bei dir der falsche HASH ankommt.

rednag

Schon mal versucht auf beiden Geräten von den jeweiligen Dateien manuell kurz vor der Sicherung einen Hash-Wert zu bilden? Möglicherweise werden die Dateien auch durch irgendetwas verändert. Das kann natürlich auf beide Seiten passieren.

Wie sieht es z.B. mit Virenscanner aus? Hatte schon den Fall (nicht auf QTS), dass nach einem Scan die Dateien vom System als geändert angesehen wurden.

Mavalok2 , nein. Das hatte ich ehrlich gesagt auch nicht auf dem Schirm.

Mit was generiert und vergleicht man so einen Hash?

Auf der Windows-Kiste dient der MS-Eigene Defender. Wobei der PC ja hier

eigentlich keine Rolle spielt. Auf der Syno ist kein AV installiert, und auf der QNAP nur die Eigenkreation Malware-Remover.

Also auch kein direkter AV-Scanner.

Hab das ganze jetzt mal testweise anders herum probiert. Proxmox-Backup -> Synology -> rsync -> QNAP.

Hier funktioniert das wie gewünscht. Bereits am Ziel befindliche Dateien werden nicht mehr gesichert.

Hast Du die Möglichkeit von QNAP auf ein anderes Gerät mit RSYNC oder SMB zu sichern?

Einfach mal testweise um zu sehen ob der Syno als Ziel der Übeltäter ist...

Zitat von rednag

Mit was generiert und vergleicht man so einen Hash?

Auf dem PC gibt es dazu genügend Tools die das machen können. Einfach mal auf ein Download-Portal Deines Vertrauens gehen. Der Hash ist ja nur eine Prüfsumme die errechnet wird und theoretisch für jede Datei und Stand einmalig. MD5 ist z.B. so ein "Verfahren". Allerdings sind Deine Dateien ja mega groß. Da ist der Umweg über den PC eher hinderlich. Auf einem NAS habe ich dies auch noch nie gemacht. Entweder gibt es ein Tool in einem der Stores oder möglicherweise geht es auch über die Konsole.

Zitat von Mavalok2

Auf einem NAS habe ich dies auch noch nie gemacht. Entweder gibt es ein Tool in einem der Stores oder möglicherweise geht es auch über die Konsole.

Auf dem NAS gibt es z.B. md5sum oder sha256sum, was man aber meiner Erinnerung nach per Entware nachinstallieren muss (Paketnamen suchen: [HowTo] Entware-ng und Linux-Pakete installieren ). Enthalten sind die Tools z.B. im Paket md5deep.

Danach einfach auf der Shell ausführen sha256sum file.