NAS Ersatz + Backup verbessern

[LukS]

Wenn du allerdings die Version > QTS 4.4.3 oder aktueller installiert hast, sollte ein größeres Volume kein Problem sein, siehe QNAP-Link oben.

Danke. Laut Link sollte es bei meinem TS-459 Pro II funktionieren.

Sicherheitshalber sollte aber die CMOS-Batterie vorher noch gewechselt werden.

Daran hab ich auch gleich gedacht. Die ist sehr wahrscheinlich nach 13 Jahren dauerbetrieb leer.

 

[conf_t]

For the following models, the initial volume can be created over 16TB but can’t be expanded over 16TB, ensure the firmware versions is updated to the latest version before creating the new volume: .....TS-459 Pro II, .....

https://www.qnap.com/de-de/how-to/faq/article/16tb-storage-limitation

Der Hinweis auf das FW Update ist klar. Vermutlich wurde trotz der 64 Bit CPU QTS anfangs nur als 32 Bit Software ausgeliefert und hat zwischenzeitlich ein Upgrade auf 64 Bit erfahren.

 

[und tschüss]

Die ist sehr wahrscheinlich nach 13 Jahren dauerbetrieb leer.

Leer im eigentlichen Sinne nicht unbedingt, da diese Batterie nur bei einem Stromausfall oder getrennten Netz die Einstellungen sichert. Die Batterie wird chemisch aber zersetzt sein. Das kann man an einer leichten Wölbung gut erkennen. Natürlich wird in diesem Zug auch keine Spannung mehr ausgegeben. Das ist also eine normale Alterung bzw. Verbrauch.

Je nach Gerät und Hersteller kann es unter bestimmten Umständen für die unterschiedlichsten Probleme sorgen, welche man aber vermeiden kann. Ich würde wie bei der USV die Knopfbatterien nach 5 Jahren spätestens ersetzen. Das gilt auch für den PC usw. Ein 10er‑Pack CR2032 Varta Professional kostet gerade einmal knapp 7 € und sind lange haltbar. Ich habe immer welche liegen, und sei es nur für die Küchenwaage, wo sich meine Frau gerne bedient, ohne etwas zu sagen …

Leider werden beim NAS nicht immer die Standard-CR2032-Batterien aufgrund der Mainboardgröße verbaut. Bevor man die Batterien kauft, sollte man sich im Internet informieren. Einfach nach dem passenden Mainboard suchen. Bei Synology gibt es im deutschen Forum eine entsprechende Liste. Neue Geräte unterschiedlicher Hersteller setzten aber meist auf die CR2032.

 

[LukS]

@snoogans
Ich hab hier einen ganzen Vorrat an unterschiedlichen Knopfzellen liegen. Sogar welche mit verschiedenen angelöteten Steckern, weil ich immer wieder alte Laptops (vor allem Dell Notebooks) repariere. Da braucht man die öfter mal.
Also das ist kein Problem.

Die Batterie wird chemisch aber zersetzt sein.

Das hatte ich letztens auch mit einer neuen Knopfzelle die schon länger auf Vorrat lag.
Knopfzelle eingebaut und ich hab mich gewundert, warum der Laptop die Einstellungen immer noch vergisst.
Ausgebaut und die Knopfzelle hat 3,2 Volt gemessen. Wieder in den Laptop eingebaut und gemessen hatte sie aber nur mehr ~1V. Wieder abgesteckt und schon hatte sie weider 3,2 Volt.
Andere neue Knopfzelle und schon ging es wieder.

 

[und tschüss]

Das liegt daran, dass man Batterien unter Last messen/testen muss.

Bei einer einfachen Spannungsmessung kann alles ok sein. Das ist im Auto auch nicht anders und kannst du gerne einmal im Winter austesten. Trotzdem ist es kein Garant dafür, dass dieses auch startet. Mit der langen Lagerung von Batterien ist es immer so eine Sache. Oft erkennt man das aber auch schon am optischen Gesamteindruck.

Ich hatte letzte Woche auch so einen Mini-PC von Lenovo. Den habe ich für meine Mutter fertiggemacht und gleich die Wärmeleitpaste getauscht und innen gereinigt. Auch die Batterie habe ich gemessen, alles ok, mir war aber gleich die kleine Ausbeulung aufgefallen und ich habe dann die Batterie vorsorglich getauscht. Meine Frau brauchte eine neue Batterie für die Küchenwaage und ich habe dann die neue „alte“ Batterie eingebaut. Das hat noch nicht einmal einen Tag funktioniert. Ich konnte die Batterie in der Waage schnell tauschen, zu meiner Mutter hätte ich erst hinfahren müssen, PC vom Monitor abbauen und dann die Batterie austauschen. Mein Bauchgefühl hatte wieder einmal recht.

Auch beim Auto kannst du die Ausdehnung an den beiden Stirnseiten fühlen, oft auch sehen. Messen oder testen musst du die Batterie dann nicht mehr.

 

[LukS]

Ich hab mir jetzt das Urgreen DXP4800 Plus mit 3x 30 TB geholt. Reicht ja vollkommen. Da hatte snogaans oder "und tschüss" schon recht.
In mein altes QNAP TS-459 Pro II habe ich auch einfach 3x30TB gesteckt.

Ich beschäftige mich gerade mit rsync.
Der Plan war jetzt Daten mittels rsync vom Quell NAS auf das Backup NAS zu spiegeln.
Ich habe --inplace und -partial genommen, weil auch sehr große Dateien mit 2-3 TB dabei sind.

rsync -avh --delete --inplace --partial -e ssh '/volume1/Install/Acronis True Image Home' admin@kellerbackup.lan:/share/Install/

Leider hänge ich so im CPU Limit auf dem uralten QNAP NAS (dualcore+Hyperthreading, also bei 25% ist ende):

sent 7.08G bytes  received 1.71K bytes  16.88M bytes/sec
total size is 7.08G  speedup is 1.00

16 MB/s ist jetzt nicht gerade schnell bei einer Gigabit LAN Verbindung zwischen den NAS.
Bei knapp 10 TB die ich jetzt initial synchronisieren will, würde der Kopiervorgang ja 7-8 Tage dauern.

Ich hab jetzt gelesen, dass es schneller sein kann mit NFS zu arbeiten. Also NFS freigaben auf dem Ziel NAS einrichtet und diese auf dem Quell NAS mounted.
Rsync auf dem Quell NAS laufen lassen.
Hat damit jemand Erfahrungen damit? Könnte das schneller sein?

 

[Banned]

rsync -avh --delete --inplace --partial -e ssh '/volume1/Install/Acronis True Image Home' admin@kellerbackup.lan:/share/Install/

Mich leuchtet nicht ein, wie dir --inplace und --partial helfen sollen. Letzteres ist, soweit ich verstehe, dafür, dass die Datei behalten wird, wenn es zu einem Verbindungsabbruch kommt - dass also fortgesetzt werden kann. Ist aber u.U. auch schlecht, wenn eine Datei dann durch so etwas unvollständig ist, aber trotzdem behalten wird. Ersteres verhindert, dass der Datei zwischenzeitig ein temporärer Name zugewiesen wird (mMn völlig überflüssig).
--delete ist m.E. komplett sinnfrei, wenn sich noch gar keine Dateien im Ziel befinden. Verursacht nur unnötige Rechenlast.

RSync ist aber generell wohl nicht so die Rakete.

 

[andy_m4]

Ich hab jetzt gelesen, dass es schneller sein kann mit NFS zu arbeiten.

Den wenigsten Overhead und damit die größte Geschwindigkeit erzielt man, wenn man quasi gar kein Protokoll verwendet und die Daten direkt mit beispielsweise netcat überträgt.
Allerdings ist das dann streamorientiert und das funktioniert zwar gut für eine einzelne Datei, aber für mehrere ist das dann erst mal ungünstig. Aber man kann tar nehmen, um die Daten zu strukturieren.

Man geht auf den Empfänger-Rechner (in Deinem Fall kellerbackup.lan) und startet netcat mit welches auf einem Netzwerkport lauscht:

cd /path/to/destdir
nc -l -p 2222 | tar xvf -

(2222 ist hier eine frei wählbare Portnummer)

Und beim zu senden Rechner macht man dann:

cd /path/to/srcdir
tar cvf - . | nc kellerbackup.lan 2222

Vorteil ist, das man halt nix konfigurieren muss und tar und nc (netcat) auch Tools sind, die fast immer bei Linux verfügbar oder zumindest leicht nachzuinstallieren sind. Außerdem hat man so gut wie gar keinen Protokolloverhead, weil es im wesentlichen blankes TCP/IP ist und nur tar quasi ein schmales Protokoll darstellt.

Es hat aber auch Nachteile. So sollte idealerweise der Transfer in einem Rutsch durchgehen weil man kein Resume hat (die Verbindung sollte also stabil sein). Also mal eben den Transfer unterbrechen um ihn später fortzusetzen ist eher ungünstig.

Aber um eine Grundlage für ein folgendes rsync zu schaffen, wäre es auf jeden Fall eine einfache Möglichkeit.
Um die Datenübertragungsrate zu monitoren, kann man ein pv zwischenschalten. Oder man schaut mit iftop drauf.

 

[Banned]

Oder einfach den Dummy-Weg wählen mit nem Rechner dazwischen.

 

[LukS]

@Banned
Ja, ich weis, beim ersten mal müsste ich das nicht machen, aber das soll später per Cronjob automatisch laufen. Also wollte ich den Befehl gleich so testen, wie er später verwendet wird.
--inplace
weil ich 2-3 TB große Dateien habe, bei denen sich nur wenige GB (10-100GB) ändern. Rsync würde sonst jedesmal 2-3 TB große Temp Dateien anlegen und erst dann kopieren.
--partial
Wegen Verbindungsabrrüchen. Bricht die Verbindung ab, dann löscht rsync ohne partial die gesamte Zieldatei und überträgt sie dann komplett neu. Bei 2-3 TB ist das nicht zielführend.

Bei mir ist definitiv die Verschlüsselung von SSH das Problem, warum die Übertragung auf das alte NAS so langsam ist. 25% CPU last für sshd.

@andy_m4
für das Erstbefüllen ist das sicher eine alternative.
Ich wollte halt gleich den Befehl so machen, dass ich ihn später in einen Cronjob einfügen kann.

Ich werde jetzt mal eine NFS freigeben einrichten und schauen wie schnell da mein altes NAS ist.

 

[andy_m4]

Bei mir ist definitiv die Verschlüsselung von SSH das Problem,

Du kannst rsync auch ohne ssh benutzen.
Dazu musst du auf dem Ziel-NAS rsync als Daemon laufen lassen.
Eine minimale rsyncd.conf sollte da reichen.

Ich wollte halt gleich den Befehl so machen, dass ich ihn später in einen Cronjob einfügen kann.

Ähm. Den Punkt verstehe ich nicht. Wenn Du eh rsync nutzen willst (was ja auch durchaus nachvollziehbar ist), dann musst Du beim Erstbefüllen (ohne rsync) ja sowieso irgendwie was anderes machen.
Oder wie passt das jetzt mit Deiner Idee mit NFS zusammen?

Falls Deine Idee ist, als rsync-Ziel quasi die NFS-Freigabe zu nutzen, so ist das von der Performance her eher ungünstig, da Du dann ja quasi noch einen Layer zwischen hast.

Man könnte auch HTTP nutzen und dann auf dem Quell-NAS einen einfachen Webserver laufen lassen von dem dann das Backup-NAS die Dateien via wget zieht. Das hat dann auch den Vorteil, das Du bei Verbindungsabbrüchen (die ja bei Dir anscheinend ein Problem sind) ein Resume machen kannst.
Und dann reicht ja ein einfacher Webserver wie miniserve.