Home AOMEI Products Support

Backupper Synchronisation, files in the destination twice the size

edited April 2016 in AOMEI Products Support

Hello,

The Backupper has launched today the synchronization again, although has since last Wednesday there was no change.

Why do the files in the destination twice the size !! ??

Greetings


image

image

image


Comments

  • edited April 2016

    Wie gross sind die Originaldaten des Sync? Das zweite Bild ist ja auch eine Sicherung, gemäss Bild, links oben. Es passt nichts zusammen (ausser die Dateinamen).

    Zudem sehe ich im Sync-Bild einen doppelten Ordnernamen, ein VMDK ist zuviel (source als \\Name\share anstatt \\192.168.p.pp\share angegeben, bekanntes Problem?

  • Hallo Peter,

    Die Originaldaten sind das untere Bild. Diese liegen auf einem lokalen Datenträger des Servers. Symantec System Recovery 2013 erstellt die VMDK wöchentlich am Mittwoch und legt sie dort gleich ab. Am nächsten Tag synchronisiere ich, von einem Client aus, diesen Ordner mit Backupper zur NAS.


    Soweit ich beobachtet habe, sind die Dateien nach dem ersten kopieren identisch. Das kann ich aber erst am Donnerstag morgen wieder überprüfen. Das die Dateien im Laufe der Woche öfter synchronisiert wurden, ist mir irgendwie schon aufgefallen. Es läuft alles automatisiert im Hintergrund.


    Quelle: 122 Elemente, 99,5 GB

    Ziel:      122 Elemente, 192 GB


    Die Sache mit dem doppelten Ordnernamen ist das bekannte Problem, welches mir neulich bereits aufgefallen ist. Könnte ich vielleicht mal ändern in \\IP\Share.


    Viele Grüße

  • edited April 2016

    Es gibt überhaupt keinen Sinn, dass die Dateien eine andere Grösse haben. Da wird irgendetwas fantasievolles von der Source gelesen... Ist es möglich, die Replikation der Sicherung von Hand zu machen?

    In my opinion it reads just anything from the source. It is known, from another thread with OP http://www.aomeitech.com/forum/discussion/2775/backupper-wrong-foldername-created#Item_20 , that sync source in the form  \\servername\share does not work, it would better be \\192.168.p.pp\share (but I do not guarantee)

    You may invest time into robocopy or xcopy (both built-in into Windows but of course harder to configure), or do the replication by drag-and-drop (means Explorer, mouse), once a week.



  • Zunar ,Is that ok now?

  • Hallo,

    ich habe den Quellpfad angepasst (\\192.168.x.x\share) und die Synchronisierung per Hand gestartet. Der Zielordner ist jetzt korrekt. 

    Dann habe ich die Synchronisierung ein zweites Mal durchgeführt. Die Dateien sind gleich geblieben. Allerdings hat nur das Vergleichen, anhand der Datenmenge, mindestens eine halbe Stunde gedauert. Scheinbar werden die Quelldateien noch mal komplett gelesen aber nicht geschrieben. Das konnte ich am Netzwerkmonitor erkennen. Hoher Download, minimaler Upload.


    Ich habe jetzt eine andere Lösung gefunden. Robocopy wird über einen Task mit den Rechten eines anderen Benutzers gestartet, der Zugriff auf die NAS hat. 

    Manchmal denkt man zu kompliziert.

  • zumar es wäre interessant zu erfahren, ob sync die Dateien korrekt kopiert hat, oder ob es am Ziel schlicht falsche Dateiinhalte hatte? Die fehlerhaften Grössenangaben würden das eigentlich besagen. Das geht aus deinem Bericht nicht hervor..

  • Sorry, das habe ich nicht mehr ausprobiert. Der Aufwand war mir jetzt zu groß, nur deswegen eine neue VM zu konfigurieren.

    Ich habe aber eine der doppelt so großen Dateien aus dem NAS-Ziel per Explorer auf meine Lokale Festplatte kopiert. An der Größe hat sich nichts mehr geändert. Ich bin davon ausgegangen, dass der Inhalt korrupt war. Diese VMDKs sind mir zu wichtig, um damit noch experimentieren.

    Ich kann gerne noch mit anderen Daten testen. Aber das mache ich, wenn ich etwas mehr Zeit habe.

  • edited April 2016

    1) also bei robocopy sind die Dateigrössen von source und ziel die gleichen?

    2) also bei IP waren die Dateigrössen von source und ziel die gleichen, oder waren bei IP die Dateigrössen im Ziel wie bei Servername, oder hat es bei IP nichts kopiert (gemäss Performancemonitor)?Dass die doppelt so grossen korrupt sind, ist selbstverständlich. Interessant wäre nur noch, ob die Dateien auch bei IP vergrössert werden, weil das besonders schlimm wäre! Diese Frage ist rückblickend, selbstverständlich lohnt es sich nicht, das nochmal zu wiederholen.

  • edited April 2016

    1) ja


    2) ja. Nach 2 syncs waren sie noch identisch. 

    Hoher Download von Netzwerkquelle, minimaler Upload auf NAS-Ziel. Es scheint, als würde in der Quelle nicht nur Dateiname, Datum, Dateigröße, sondern auch der komplette Dateiinhalt geprüft werden.


    Ich habe jetzt wieder eine Sync-Aufgabe erstellt. Wie ursprünglich mal gewesen ist.

    Aufgabenname: Lokal_zu_NAS

    Quelle: \\SBS2011\pflege auf S

    Ziel: \\NASC908B2\andre\test

    Ergebnis: \\NASC908B2\andre\test\Lokal_zu_NAS\pflege auf S\uf S  (Fehler, weil ohne IP)

    Eine große *.VMDK vom 13.04.2016 10:26, 1.984.000 KB


    Es wird jeden Tag morgens synchronisiert. Mal sehen, ob sich da die Tage etwas verändert.


    Nach einer Woche, oder wenn sich die Dateigröße im Ziel verändert, werde ich im Quellpfad die IP eingeben und nochmals testen.


    Ich berichte dann...

  • edited May 2016

    Den Test beende ich jetzt. Das Problem mit der Dateigröße ist wieder aufgetreten.

    Und zwar war alles in Ordnung, solange sich die Quelldateien nicht verändert haben.

    Heute habe ich die Dateien in der Quelle gegen aktuellere Dateien überschrieben und die Sync manuell gestartet. Danach waren die Dateien im Ziel größer. Wird das, was sich in der Quelldatei verändert, an das Ziel angefügt statt die Datei zu überschreiben?


    Und eben das Problem, das der Dateisync sehr lange dauert auch wenn sich die Quelldateien nicht verändert haben. Wie oben beschrieben.


    imageSource.jpg

    imageTarget.jpg


Sign In or Register to comment.