Backup dauert ewig

[pio007]

Hallo,
habe ein Backup über VPN zwischen einer DS411 und einer RS815 eingerichtet.
Läuft auch alles, ABER: die weiteren Backups dauern ewig, obwohl nicht wirklich Daten verändert worden sind. Zeit ist so ca. 8-10 Stunden! Wie gesagt, kaum Daten verändert.
Wo liegt da der Fehler, bzw. wie kann ich das umstellen?
Danke und Gruß
Marc

 

[dil88]

Es müssen alle Daten verglichen werden hinsichtlich Größe und Timestamp, das dauert übers Internet natürlich, wenn Du viele Dateien hast. Welche Datensicherung verwendest Du denn? Möglicherweise ist eine Variante günstiger, die blockbasiert arbeitet (m.W. die Netzwerksicherung auf ein Volume).

 

[frankyst72]

VPN ist sicherlich auch nicht die performanteste Art der Datenübertragung. Wie hoch ist denn Dein möglicher Upload des DSL bei der Quell-DS?

Mein Backup übers Internet (ca. 2,5 TB) per Datesicherung & Replikation auf eine andere DS dauert ohne Datenänderungen, ca. 8 Minuten. (SSH-verschlüsselt, blockbasiert, Komprimierung aktiv, Upload 6 MBit (750 KByte/s))

@dil88 "blockbasiert" geht auch bei Sicherung auf einem Gemeinsamen Ordner

 

[pio007]

Hi,
6MBit upload habe ich.
Einstellungen in Datensicherung&Replikation: Übertragungsverschlüsselung aktiviert, Sicherungsrotation (von der frühesten Version,10)
Wo kann ich denn blockbasiert einstellen? auch die Komprimierung.
Habe gerade wieder abgebrochen: 12h Laufzeit, 4%, Es scheint mir, als ob immer alles komplett neu übertragen wird, und nicht nur die neuen, geänderten Daten...
Gruß

 

[dil88]

Ist das Backup denn schon einmal erfolgreich bis zum Ende durchgelaufen? Wie ist die CPU-Last auf den Geräten?

 

[raymond]

Ja CPU und RAM-Auslastung auf beiden NASes wäre interessant. Eventuell muss die DS411 durch ein schnelleres Modell getauscht werden.
Zudem kann auch eine möglicherweise vorhandene schlechte/schwankende Qualität der Internetanschlüsse an beiden Standorten dafür verantwortlich sein (bzw. dort die Router).

 

[frankyst72]

Wo kann ich denn blockbasiert einstellen?

Übertragungsverschlüsselung aktiviert,

das brauchst Du eigentlich nicht, wenn Du die Verbindung über ein VPN abgesichert hast.

Es scheint mir, als ob immer alles komplett neu übertragen wird,

Das wäre der Fall, wenn er voher nicht vollständig geklappt hat. Datensicherung & Replikation fängt immer von vorne an und setzt nicht bei der zuletzt übertragenen Datei wieder auf. Der Sicherungsjob muss komplett gelaufen sein, sonst fängt er bei jedem Versuch wieder von vorne an.

Hast Du eine Vorstellung, von wie viel Daten wir reden? 1) Vollständiges Backup, 2) die Änderungen, seit dem letzten erfolgreichen Backup

 

[Super-Grobi]

Hast Du zufällig die 815 auf DSM 6.0 laufen?
Ich habe gerade einen Schriftwechsel mit dem Synology-Support (Synology Support Ticket: #723160) der mir erzählen will, dass man auf dem Source-NAS (NICHT das Target-NAS) mindestens den gleichen Platz freihaben müßte wie das Backup groß ist.

----
Thank you for contacting Synology support.

After checked with developers, current design will act like that,

When the backup running will need almost the same capacity for cache,
and it will be eliminate after the backup is complete success.

But if the backup fail, it won't clear the cache, until the next time you run the backup task.

So, please try provide the enough capacity at backup source for success run the backup task, sorry for your inconvenience.

Best Regards,
Andrew Chen
----

Daher bricht mein RSync-Backup von meiner DS1515 (DSM 6.0) auf eine DS210+ (DSM5.2) nach ~ 1TB immer ab, da ich auf dem Volume1 keine 2TB mehr frei habe....

Völliger Blödsinn dass.

Ich hoffe noch, dass Andrew Chen (Der Supporter) mit dem Entwickler (der wohl gemeint haben soll, dass das das neue Design sei, und so gewollt sei) aneinander vorbei geredet hatq. Sowas kann doch nicht wahr sein.

Die Transferraten waren/sind bei mir ähnlich unterirdisch. Ich kam auf knapp 6-7 MB Sekunde.

Nun sollte eigentlich der DSM6.0 bei mir wieder runter, und der 5.2er rauf. Aber wenn es mit dem 5.2er ähnliche Probleme gibt, kann ich mir das ja sparen....

Grüße

 

[dil88]

Für die rsync-basierte Datensicherung bestreite ich das. Man kann während des Backuplaufes ja die Belegung des Volumes mitverfolgen, da wird überhaupt nichts gecacht. In der normalen Konfig macht rsync soetwas auch nicht. Bei Time Backup, das ja auch auf rsync aufsetzt, kann man m.E. ein Caching-Volume definieren. Das ist aber standardmäßig nicht der Fall.

 

[Super-Grobi]

Moin,

Du magst es bestreiten, aber meine DS mit DSM 6.0 verhält sich leider so.
> Für die rsync-basierte Datensicherung bestreite ich das

Der Support war per SSH auf den beiden NAS, und wie Du oben lesen kannst, bestreitet der Support das leider nicht.
Er sagt leider, dass dies das geplante Verhalten darstelle.

Grumpf...

 

[frankyst72]

von Platzproblemen hat doch keiner geredet... ggf. wird durch dieses Verhalten unter DSM 6 dafür gesorgt, dass ein abgebrochenes Backup an dem Punkt wieder aufgesetzt werden kann, wo es abgebrochen ist. Unter DSM 5.2 ist das nicht der Fall.

 

[Puppetmaster]

Aus Erfahung mit der regulären Sicherung (rsync basiert) kann ich nur bestätigen, dass auf dem Target(!) immer ein gewisser freier Platz sein muss, da rsync wohl so arbeitet, dass immer erst die neue Version einer Datei geschrieben wird bevor die alte gelöscht wird. Also wenn du eine aktualisierte 10GB Datei sicherst, die sich bereits im Target befindet, muss auch min. 10 GB noch auf dem Target frei sein.

 

[dil88]

Aus Erfahung mit der regulären Sicherung (rsync basiert) kann ich nur bestätigen, dass auf dem Target(!) immer ein gewisser freier Platz sein muss, da rsync wohl so arbeitet, dass immer erst die neue Version einer Datei geschrieben wird bevor die alte gelöscht wird.

Standardmäßig macht rsync das nicht, da hat Synology offenbar die Option --delete-after gesetzt (oder --delete-delay). Dann macht das Sinn.

 

[Super-Grobi]

Hi

Aus Erfahung mit der regulären Sicherung (rsync basiert) kann ich nur bestätigen, dass auf dem Target(!) immer ein gewisser freier Platz sein muss, da rsync wohl so arbeitet, dass immer erst die neue Version einer Datei geschrieben wird bevor die alte gelöscht wird. Also wenn du eine aktualisierte 10GB Datei sicherst, die sich bereits im Target befindet, muss auch min. 10 GB noch auf dem Target frei sein.

Leider geht es NICHT um das Target, sondern nur um das Source System. Wenn es das Zielsystem wäre, würde ich ja gar nichts sagen.


Auf dem Quell-System muß laut Synolgy beim DSM 6.0 (Backup & Restore als App) ebenfalls der Platz für alle! zu transferierenden Daten, auf dem Volume auf dem die App installiert ist, vorhanden sein.
Ich konnte es auch nicht glauben, aber der Support und mein NAS bestehen leider darauf.

Wie gesagt ich hatte noch rund 1TB auf dem Vol1 des Quellsystems frei. 3TB auf dem Zielsystem frei, und es sollten rund 1.5TB von dem Quellsystem gesichert werden.
Der Cache wächst an, bis Volume1 zu 100% belegt ist, danach bricht das Backup mit Fehler ab.
Leider absolut reproduzierbar.

Meine Hoffnung besteht derzeit nur darin, dass Support und Entwicklung aneinander vorbei geredet haben, und daher die Entwicklung davon ausgeht, dass es um ein Platzproblem auf dem Zielsystem geht, und das eigentliche Problem gar nicht nicht mitbekommen hat

Deshalb hatte ich jetzt heute Nachmittag nochmal nachgefragt:

Da der Support aber wohl in einem asiatischen Callcenter sitzt, wird es erst morgen eine Antwort geben.

Grüße
Jörg

 

[dil88]

Ist verstanden. Man kann rsync vermutlich auch so konfigurieren, aber ich verstehe die bisherigen Informationen zu Backup & Restore so, dass blockbasiert in eine Datenbank gesichert wird. Das klingt nicht nach rsync. Die Information ist auf jeden Fall sehr interessant - eine weitere, die ich besorgniserregend finde.

 

[Puppetmaster]

Ja, besorgniserregend oder man kann es auch entspannt sehen. So ist für mich die Option, in nächster Zeit auf DSM 6.0 umzusteigen vom Tisch und ich muss da erst einmal keine weitere Zeit hinein investieren.
Sorry für OT.

 

[Super-Grobi]

Hi

> dass blockbasiert in eine Datenbank gesichert wird

ja, das könnte passen. Zumindest wird weder auf dem Zielsystem, noch in den Cachedateien, eine normale Ordnerstruktur angelegt die der Struktur entsprechen würde die auf der Quelle zu finden ist.
(Was für mich ein weiterer unangenehmer Punkt ist. Ich würde eine normale, durch rsync verlinkte Struktur absolut bevorzugen)
Wobei es auch nicht nach "Datenbank aussieht. Viiiiele einzelne Files.....

Also zurück auf DSM 5.2 und Synology Server-Basiertes Backup....

Grüße

 

[dil88]

Die vielen, einzelnen Files wurden schon beschrieben, dahinter verbirgt sich aber vermutlich eine Datenbank.

@Puppetmaster: Man kann es nur entspannt sehen, da bin ich ganz Deiner Meinung - wie auch in Deiner Schlussfolgerung. Ich habe zwar nicht erwartet, dass DSM 6.0 bald Einzug bei mir halten würde, aber das, was sich im Backupbereich jetzt abzeichnet, ist schon fast Zweikomponentenkleber auf DSM 5.2.

 

[Hafer]

confirmed: Das versionierende Backup&Restore von DSM6.0 verbraucht auf dem Source tatsächlich während des backup Speicher, der anschließend wieder freigegeben wird. Ob es 100% oder weniger sind, kann ich nicht beziffern. Nach Abschluss des initialen backup trat der Effekt nicht mehr auf - oder lediglich in einem ähnlich großen bzw. kleinen Umfang, wie die jeweilige Differenz zur Vorversion.

Dem Threadstarter hilft das allerdings vermutlich nicht.

Gruß Hafer

 

[pio007]

So, nach längerer Abwesenheit zurück zum Thema und den Fragen:
@ frankyst72: diesen Haken "in Blöcken" habe ich bei mir nicht!
Der Job ist einmal komplett abgelaufen (bei mir im Netzwerk). Dann Transfer in des andere Netzwerk, dort am Anfang auch komplett abgelaufen, allerdings das erste bereits 6 Stunden. Und jetzt wird's immer länger. Zuletzt Abbruch nach 3 Tagen und 10% !!!
Daten sind ca. 2 TB

@Super-Grobi : DSM 5.2 5644

Weitere Ideen?
Danke und Gruß Marc