Wie Time-Backup Backups auf externe USB Festplatte kopieren/sichern

[ds409+dw]

Hallo,

ich versuche seit Tagen eine Kopie meiner durch Time-Backup erstellten Backups auf eine externe USB-Festplatte zu kopieren und bin bislang vollends gescheitert! Hier brauche ich mal eure Hilfe.

Hintergrund:
Aktiv nutze ich eine DS411+II als NAS, deren Daten ich bislang per Time-Backup auf eine DS409+ (DSM 4.2) gesichert habe. Da ab DSM 6.2 Time-Backup nun endgültig nicht mehr unterstützt wird, habe ich bereits seit ca. 2 Monaten (noch mit DSM 6.1) parallel zum Time-Backup Backups per Hyper Backup auf die DS409+ gesichert. Die DS411+II habe ich dann vor etwa zwei Wochen auf DSM 6.2 umgestellt.

Soweit so gut. ...

Um die Backups (sowohl die aktuellen von Hyper-Backup (ca. 850GB) wie auch die "alten" von Time-Backup (ca. 4TB) erstellten Backups!) auf der DS409+ wiederum zu sichern, habe ich mir eine externe 8TB WD MyBook USB-Festplatte besorgt und auf der DS409+ je einen Time-Backup Backup-Job (Hyper Backup gibt es für DSM4.2 nicht!) eingerichtet. Während der Backup-Job für die Hyper-Backup Daten problemlos durchgelaufen ist, bricht das Backup der Time-Backup Daten immer ab! Da die Übertragungsrate zwischen USB-Festplatte und DS409+ nur etwa 18MB/s beträgt, ist natürlich besonders toll, wenn der Job nach 30 Stunden abbricht und man nicht weiß warum (ich konnte jedenfalls keine Fehlermeldungen finden; Frage: legt Time-Backup tatsächlich keine Logs an?)!

Nachdem der Time-Backup Job mehrmals nach unterschiedlicher Zeit und kopierter Datenmenge abgebrochen hat, habe ich versucht die Daten per shell Befehl mit

"(cd /volume1/NetBackup/TimeBackup ; tar cf - .) | (cd /volumeUSB1/usbshare/TimeBackup/ ; tar xf -)"

zu kopieren. Das hat aber praktisch nicht funktioniert weil das Kommando mit Abbruch der SSH-Session ebenfalls abgebrochen wird (ich konnte ja keine ca. 50 Stunden - 4TB / (18Mb/s) - eingeloggt bleiben). Es nützt dann auch nichts den Job im Hintergrund laufen zu lassen. Ich habe als nächsten Versuch im DSM-Aufgabenplaner einen Job angelegt und den obigen Befehl dort eingetragen. Der Job wird zwar wie geplant gestartet, aber auch dieser bricht nach einiger Zeit (ettliche Stunden) ab.


Und jetzt habe keine Ideen mehr!
- Warum bricht der Backup-/Kopiervorgang immer wieder ab?
- Wie bekomme ich die Backups auf die externe Festplatte?

Ich hoffe, Ihr habt noch eine Idee!



P.S.
Kann das Problem evtl. mit den von Time-Backup verwendeten Hardlinks zu tun haben?

 

[dil88]

Sollten die Hardlinks durch Kopien ersetzt werden, wird die Kapazität der USB-Platte nicht reichen. Ich würde es einmal mit rsync und passenden Optionen versuchen.

 

[ds409+dw]

Hallo dil88,

vielen Dank für die Antwort, aber die Kapazitätsgrenze der USB-Festplatte wurde bislang auf keinen Fall erreicht. Neben der Tatsache, dass ich mir das auf der Shell immer mal wieder mit "df" habe ausgeben lassen, würde die Grenze bei 18MB/s erst nach ca. 120 Stunden erreicht werden. Die bisherigen Versuche sind weit früher abgebrochen worden.

 

[dil88]

Tar kommt ja auch mit Hardlinks klar. Wenn Du es nicht mit rsync probieren willst, sondern bei tar bleiben möchtest, bekommst Du das mit dem Hintergrundjob hin, indem Du Dir eine bash und nohup installierst per EBI.

 

[ds409+dw]

So, ich wollte mich nochmal mit dem aktuellen Stand melden:

1. Um sicher auszuschließen, dass die Hardware wirklich ok ist, habe ich die Backup-Daten einfach mal per Filestation auf die externe Platte kopiert. Der Kopiervorgang ist bis zum erwartungsgemäßen Abbruch mit "Festplatte voll" (dabei werden ja keine Hardlinks verwendet, sondern die entsprechenden Dateien mehrfach komplett kopiert) einwandfrei gelaufen => Hardware ok!

2. Anschließend habe ich den Time-Backup Job nochmal gestartet und die Speicherbelegung (diesmal HDD, RAM und SWAP-Speicher!) beobachtet. Der Backup-Job lief problemlos durch bis RAM+SWAP-Speicher komplett belegt waren! Auch die Log-Datei /var/log/messages enthielt danach einen "out of memory" Eintrag! => D.h. der verfügbare Arbeitsspeicher RAM+SWAP reicht einfach für den Job nicht aus!


Frage:
- Kann ich den RAM-Speicher (DS409+ hat ein 512MB DRAM-Modul; eine Vergrößerung auf z.B. 1GB/2GB scheint nach meiner Internet-Recherche eher nicht möglich zu sein) oder die SWAP-Partition vergrößern?
- Andere Ideen? Was kann ich noch ausprobieren?

 

[dil88]

Wenn Time Backup mit Deinem RAM nicht auskommt, ist da etwas faul. Das sollte m.E. nicht so sein. Mir ist nicht bekannt, dass Time Backup mindestens 1GB RAM voraussetzt. Hast Du die letzte Version von TIme Backup installiert - also die, die unter DSM 4.2 angeboten wird? Welche Version ist das? Ich benutzt Version 1.2-2369, wobei sich in der Funktionalität bei Time Backup ja schon eine Weile nichts mehr getan hat. Meiner Erinnerung nach geht bei mir auch die CPU-Last hoch - was m.E. am rsync liegt -, aber die RAM-Auslastung bleibt überschaubar. Werde ich mir beim nächsten Lauf nochmal genauer ansehen.

 

[ds409+dw]

Hallo dil88,

erstmal vielen Dank für Deine Unterstützung!


Also ich habe die Software-Versionen nochmal überprüft und meine DS ist auf aktuellem Stand. DSM ist auf Version 4.2-3259 (https://www.synology.com/de-de/releaseNote/DS409+) und das Time-Backup Paket ist auf Version 1.2-2301 (https://www.synology.com/de-de/releaseNote/TimeBackup?model=DS409+).

Da ich die DS409+ seit ca. 5 Jahren als reines Backup-NAS einmal die Woche benutze und es bislang Null(!) Probleme gegeben hat, gehe ich eher nicht davon aus, dass da etwas faul ist. Auch DSM4.2 stammt ja, bis auf kleinere Sicherheits-Updates, bereits aus 2014.

Achtung: Bez. der RAM-Auslastung hatte ich bei meinen ersten Versuchen immer nur auf die RAM-Auslastung geachtet, welche bis zum Abbruch zwar schwankend, aber nicht auf nahe 100% gegangen ist. Bei meinem letzten Versuch habe ich mir über die Laufzeit hinweg aber den Wert Total - free (in der Beispiel-Ausgabe ganz unten rechts angeschaut. Und dieser sankt während des Backup-Vorgangs bis auf 0, worauf dann mit "out of memory" abgebrochen wurde! Ich habe diesen Vorgang bis zum Abbruch auf der SSH-Sitzung beobachtet. Weiter unten habe ich mal den entsprechenden Ausschnitt aus der /var/log/messages eingefügt.


DS> df;free
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2451064 461204 1887460 20% /
/tmp 257720 212 257508 0% /tmp
/dev/mapper/vol1-origin
5754598864 4084285232 1670211232 71% /volume1
/dev/sdq1 7691408388 889539908 6801766080 12% /volumeUSB1/usbshare
total used free shared buffers
Mem: 515440 167688 347752 0 24252
Swap: 2097080 0 2097080
Total: 2612520 167688 2444832
DS>


/var/log/messages:

Nov 12 21:34:02 kernel: [681282.910317] scemd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Nov 12 21:34:02 kernel: [681282.917291] Call Trace:
Nov 12 21:34:02 kernel: [681282.919829] [be0b7c60] [a0007670] show_stack+0x54/0x160 (unreliable)
Nov 12 21:34:02 kernel: [681282.926287] [be0b7c90] [a0065924] oom_kill_process+0x58/0x1dc
Nov 12 21:34:02 kernel: [681282.932123] [be0b7cc0] [a0065cf0] __out_of_memory+0x48/0xd0
Nov 12 21:34:02 kernel: [681282.937789] [be0b7ce0] [a0065e78] out_of_memory+0x7c/0xa8
Nov 12 21:34:02 kernel: [681282.943283] [be0b7d00] [a00680e8] __alloc_pages_nodemask+0x3c0/0x444
Nov 12 21:34:02 kernel: [681282.949729] [be0b7d60] [a006a6ac] __do_page_cache_readahead+0xac/0x1f4
Nov 12 21:34:02 kernel: [681282.956352] [be0b7da0] [a0062634] filemap_fault+0x1cc/0x3c0
Nov 12 21:34:02 kernel: [681282.962021] [be0b7dd0] [a0077ccc] __do_fault+0x6c/0x430
Nov 12 21:34:02 kernel: [681282.967341] [be0b7e30] [a0078384] handle_mm_fault+0x2f4/0x698
Nov 12 21:34:02 kernel: [681282.973183] [be0b7e80] [a0012a0c] do_page_fault+0x2b8/0x428
Nov 12 21:34:02 kernel: [681282.978848] [be0b7f40] [a000f73c] handle_page_fault+0xc/0x80
Nov 12 21:34:03 kernel: [681282.986997] DMA per-cpu:
Nov 12 21:34:03 kernel: [681282.989617] CPU 0: hi: 186, btch: 31 usd: 163
Nov 12 21:34:03 kernel: [681282.994501] active_anon:54837 inactive_anon:54859 isolated_anon:0
Nov 12 21:34:03 kernel: [681282.994505] active_file:982 inactive_file:934 isolated_file:0
Nov 12 21:34:03 kernel: [681282.994508] unevictable:0 dirty:0 writeback:0 unstable:0
Nov 12 21:34:03 kernel: [681282.994512] free:2095 slab_reclaimable:527 slab_unreclaimable:6719
Nov 12 21:34:03 kernel: [681282.994516] mapped:11 shmem:27 pagetables:963 bounce:0
Nov 12 21:34:03 kernel: [681283.023742] DMA free:8380kB min:8192kB low:10240kB high:12288kB active_anon:219348kB inactive_anon:219436kB active_file:3928kB inactive_file:3736kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:520192kB mloc
Nov 12 21:34:03 kernel: [681283.063463] lowmem_reserve[]: 0 0 0
Nov 12 21:34:03 kernel: [681283.067049] DMA: 1103*4kB 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 8380kB
Nov 12 21:34:03 kernel: [681283.077380] 2861 total pagecache pages
Nov 12 21:34:03 kernel: [681283.081211] 918 pages in swap cache
Nov 12 21:34:03 kernel: [681283.084786] Swap cache stats: add 594373, delete 593455, find 56022676/56030304
Nov 12 21:34:03 kernel: [681283.092181] Free swap = 0kB
Nov 12 21:34:03 kernel: [681283.095143] Total swap = 2097080kB
Nov 12 21:34:03 kernel: [681283.120022] Out of memory: kill process 2370 (verbkp.cgi) score 2541 or a child
Nov 12 21:34:03 kernel: [681283.127418] Killed process 2516 (rsync)
Nov 12 21:34:04 verbkp.cgi: [2370]BK_ERR:child is terminated by signal [9]
Nov 12 21:34:04 verbkp.cgi: [2370]BK_ERR:rsync fail