Ich kann also absolut nicht logisch nachvollziehen, was da beinahe 2 Wochen lang abgegangen ist... leider.
Das könnte vielleicht die neue Security Center Funktion "Unusual File Activity Monitoring" sein.
Bei mir meldete die nach dem Update:
"Generating data... Completion time:"eine Woche später. =:-O
Was die da generiert - keine Ahnung. Woher die Schätzung kommt, dass das eine Woche dauern würd - auch keine Ahnung.
Tja, solche Träume hatte ich auch mal. Ist aber wohl illusorisch.
Na ja, so ganz egal ist es nicht.
Schlaueren Botnets ist es egal, ob das NAS offen im Internet steht, da kontaktiert der Bot seinen C&C-Server mittels ausgehender Verbindung vom NAS aus.
fehlerfreien Version 21
Mutige Aussage! 
wenn es aber schon ein Backupmedium geben sollte (was wohl nicht der Fall ist)
Nun, genau das ist mein Punkt:
Wenn es jetzt noch kein Backupmedium gibt, sollte das als allererstes erstellt werden.
Notwendig ist das so oder so.
Man spart nichts, wenn man das Backup auf nach der Migration verschiebt.
Die Reihenfolge: erst Backup, dann Migration, verursacht keine Mehrkosten oder -aufwände.
Sie hat aber erhebliche Vorteile.
daher auch jetzt die Migration von den Single Disks zu Raid1... Und dann Backup wenn alles Ready ist
Ich würde wärmstens empfehlen das umzudrehen.
Erst Backup, dann Migration.
Im übrigen läuft HBS-3 vollkommen zuverlässig.
Ist das ironisch gemeint?
Ich benutze die QNap beruflich und bin eigentlich darauf angewiesen, dass ein Backupprogramm zuverlässig arbeitet und kein Eigenleben führt.
Dann ist HBS3 meiner Erfahrung und Einschätzung nach nicht das richtige für dich.
Deiner Beschreibung nach hast du aktuell zwei völlig voneinander getrennte Netze aufgebaut:
Jetzt willst du den "weiteren Rechner" von Netz 1 auf Netz 2 umhängen, damit er 10G Netzwerkgeschwindigkeit bekommt, aber er soll trotzdem weiterhin die Fritzbox erreichen, damit er Internet-Zugang hat.
Habe ich das soweit richtig verstanden?
Grundsätzlich gibt es dafür drei Lösungsmöglichkeiten:
Wie jede der drei Lösungen im Detail zu konfigurieren ist, hängt davon ab, wie deine jetzige Lösung im Detail konfiguriert ist.
Wichtigste Information dazu: welche IP-Adressen verwendest du aktuell?
Ich vermute, die Fritzbox hat die Standard-Adresse 192.168.178.1 und die Geräte in Netz 1 bekommen ihre IP-Adressen per DHCP von der Fritzbox.
Wie sieht das in Netz 2 aus? Wo kommen da die IP-Adressen her und in welchem Bereich liegen sie?
Das sieht nach einem Alternate Data Stream aus. Zone.Identifier dürfte das Mark of the Web sein. Warum HBS3 dafür bei dir plötzlich eine Warnung auswirft, weiß ich allerdings nicht. Bei mir tut es das nicht.
Bei mir ist durch das Update zumindest nichts schlechter geworden. Ob das gelegentliche "Hängenbleiben" der lokalen Sicherungsjobs bei 5%, bevor irgendwelche Daten übertragen wurden, weiterhin auftritt, muss sich noch zeigen.
Äh, doch, die großen Hoster machen das ganz anders.
Die großen Hoster haben so etwas wie hochverfügbare Virtualisierungsinfrastrukturen, SDNs, Firewallcluster, SOCs, Incident Response Teams usw.
Da würde keiner auf die Idee kommen, ein NAS direkt vom Internet erreichbar zu machen (egal über welche Ports) und eine Webseite darauf zu hosten, geschweige denn ASP.NET über Mono zu betreiben.
Klingt für mich völlig normal.
(Im Gegensatz zu dem Krempel, den mir Youtube anschließend andienen wollte - das ist ja echt nicht normal, was da mittlerweile für Müll angeboten wird!)
Na, dann mach mal. Vielleicht funktioniert Dropbox dann bei dir auch nicht mehr. :-p
Die erste Benachrichtigung, die ich erhielt, nachdem alles wieder funzte, war, dass das Admin-Passwort "aus Sicherheitsgründen" auf die Cloud-Key umgestellt wurde.
Die Meldung lautet, dass das Standard-Admin-Passwort auf den Cloud Key umgestellt wurde.
Das Standardpasswort ist das, was gilt, solange du kein eigenes Passwort gesetzt hast oder nachdem du es per 3 s Reset gelöscht hast.
Ja, ein sshd-Prozess müsste laufen und auf Port 22 horchen:
[~] # ps aux | grep sshd
7268 admin 8032 S sshd: admin [priv]
7366 admin 7688 S sshd: admin@pts/4
8663 admin 456 S grep sshd
17049 admin 4416 S /usr/sbin/sshd -f /etc/config/ssh/sshd_config -p 22
[~] # netstat -lntp | grep -e :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 17049/sshd
tcp 0 0 :::22 :::* LISTEN 17049/sshd
[~] # /etc/init.d/login.sh restart bringt auch nichts.
Was heißt "bringt nichts"? Was war die Ausgabe?
Was gibt getcfg LOGIN "SSH Enable" aus?
In der Meldung steht doch ausdrücklich, dass das Standardpasswort des Benutzers "admin" geändert wurde. Das sollte doch eigentlich klar genug sein. Das Standardpasswort ist das Passwort, das standardmäßig gilt, solange man kein eigenes Passwort gesetzt hat. (Bzw. dieses durch einen 3s-Reset gelöscht hat.) Ein Passwort, das ich selber gesetzt habe, ist eben kein Standardpasswort und damit nicht betroffen.
ExFAT würde ich meine Sicherungen auch nicht anvertrauen wollen.
Meine externen Sicherungen gehen abwechselnd auf NTFS-formatierte Platten, die ich notfalls direkt an einen Windows-PC anschließen kann, und ext4, was das native Format von QTS ist und dem ich deshalb mehr vertraue.
Ich habe auch das Gefühl, dass das Problem mit dem endlosen Hängenbleiben der Jobs bei 5%, während HBS3 die alten Backup-Versionen aufräumt, bei NTFS-Platten häufiger auftritt als bei ext4.
Dafür habe ich aber keine harten Belege.
Warum sollte eine Versionierung überhaupt (extern) im Backup veranlagt sein und nicht auf dem Quellsystem selbst?
Das sind muMn zwei von einander völlig unabhängige Funktionalitäten.
Versionierung auf dem Quellsystem heißt, ich mache die Änderungsgeschichte meiner Dateien nachvollziehbar.
So etwas braucht man im Dokumentenmanagement (Stichwort Revisionssicherheit) oder in der Softwareentwicklung (Stichwort Change Management).
Versionierung im Backup ist im Prinzip Deduplizierung: ich will häufige Backups, um im Falle eines Falles möglichst genau den Stand zu einem bestimmten Zeitpunkt wiederherstellen zu können, aber ich will nicht x identische Kopien von Dateien im Backup haben, an denen sich überhaupt nichts getan hat.
Wie gesagt, bei mir kopiert HBS3 nur veränderte Dateien, und es dauert trotzdem manchmal ewig.
Aber mal ganz direkt gesagt: "inkrementelles Backup" ist keine Anforderung, sondern eine technische Umsetzung.
Die Frage ist: wofür willst du inkrementelles Backup? Welche Anforderung willst du damit erfüllen?
Wenn ich deine Antwort richtig interpretiere, ist diese Anforderung: das Backup soll schnell fertig sein.
Damit ist HBS3 schon mal raus, denn dessen Backup-Jobs dauern meiner Erfahrung nach unkalkulierbar lang: mal sind sie in 5 Minuten durch, mal stehen sie nach 10 Stunden immer noch bei 5%.
Um zu evaluieren, welches andere Backup-Programm infrage kommt, müsstest du dir jetzt noch über deine weiteren Anforderungen klar werden: wohin willst du sichern, wie oft willst du sichern, wodurch soll das Backup gestartet werden, was soll passieren, wenn das Backup-Medium nicht zur Verfügung steht, wie willst du vom Erfolg oder Misserfolg der Sicherung informiert werden, wie weit zurück möchtest du Sicherungen verfügbar halten, wie gut müssen sie gegen unbefugte Zugriffe abgesichert sein, willst du im Falle eines Totalausfalls des QNAP mit einem anderen System an die Sicherung drankommen - von den Antworten auf solche Fragen hängt schlussendlich ab, ob eine angebotene Alternative für dich besser ist als HBS3.
(Eine weitere Anforderung von dir scheint zu sein: du willst nachvollziehen können, was das Backup-Programm eigentlich genau macht. Aber ich fürchte, diese Anforderung erfüllt kein Backup-Programm, das du nicht selber programmiert hast. Selbst beim simplen nativen rsync sitzt man manchmal rätselnd davor, was das Ding jetzt eigentlich tut und warum.)
