Häng an deinen rsync-Befehl Folgendes an:
rsync ... >/share/Freigabe/logdatei 2>&1(Freigabe muss durch den Namen einer existierenden Freigabe ersetzt werden.)
Morgen früh kannst du dann sehen, ob Cron den Eintrag zu starten versucht hat und welcher Fehler aufgetreten ist.
Qsync wäre in der Tat das Gegenstück zu Seafile.
Die Frage ist aber, ob du das nicht ohnehin besser mit einer einfachen Dateifreigabe (nfs oder smb) machen kannst. In der Cloud geht das nicht, dort wird so etwas üblicherweise nicht angeboten, aber auf dem eigenen NAS ist das oftmals die bessere Methode, da einmal eingerichtet sehr unkompliziert zu nutzen, und viele Probleme der Synchronisierung (z. B. zeitlicher Versatz) treten da schlichtweg nicht auf.
Es hängt aber auch davon ab, wie oft du von wo aus darauf zugreifst.
Vermutlich war schon das hier
Das Verzeichnis /data existierte nicht. Ich habe es mit mkdir angelegt. Warum, weiß ich nicht.
der Fehler. Das Verzeichnis data existierte schon, aber an einer anderen Stelle. Entweder ist die Konfiguration in my.cnf fehlerhaft oder es ist ein Link verloren gegangen (warum auch immer, hatte ich aber auch schon mal nach einem qts-Uptade).
Den Link kannst du anlegen mit
cd /mnt/ext/opt/mariadb
ln -s /share/CE_CACHEDEV1_DATA/.mariadb10/data dataDas Verzeichnis /mnt/ext/opt/mariadb/dump muss gegebenenfalls vorher entfernt werden (mit rm und rmdir oder mit mv umbenennen), falls es noch existiert.
Rechteprobleme, wenn sie auftreten sollten, kannst du mit chmod lösen. Auf einem privaten NAS, welches nicht von außen erreichbar ist, kannst du großzügig sein, z. B. chmod 777 Datei-oder-Verzeichnis (aber bitte nicht auf einem Firmen-NAS).
Erstmal:
Der User, den du mit mysqldump -u user1 angibst, ist ein reiner Datenbankuser, der nichts mit einem womöglich gleich lautenden Unix/NAS-User zu tun hat, und es braucht auch keinen entsprechenden NAS-User zu geben. Der user1 muss auf der Datenbank die Rechte auf die zu exportierenden Objekte haben. (Hinweis: Für den Dump nimmt man idR. den User "root" - der übrigens nichts mit dem "rein zufällig" gleichlautenden Unix-User root zu tun hat - da nur dieser User garantiert Zugriff auf alle DB-Objekte hat. Mit anderen Usern erstellte Dumps riskieren, unvollständig zu sein.)
Dann schreibt mysqldump überhaupt keine Ausgabedatei, sondern der Dump wird nach stdout geschrieben. stdout muss sinnvollerweise umgeleitet werden, um in eine Datei zu kommen. In deinem Beispiel tust du das, indem stdout in eine Pipe geschickt wird, welche wiederum als Eingabe für gzip dient.
Deine Datei dump.sql.zip gehört folglich dem NAS-User, der gzip gestartet hat.(Diesen NAS-User braucht es nicht als Datenbankuser zu geben.)
Um zu verstehen, warum deine Dump-Datei welchem User mit welchen Rechten gehört, musst du dir anschauen, wann und wie dein Dump-Befehl aufgerufen wird.
Please consult the Knowledge Base to find out how to run mysqld as root!
Und? Hast du das gemacht?
Dann wärst du z. B. hierauf gestoßen. Der Daemon will nicht als root/admin gestartet werden. sudo war also ein Irrweg. Oft liegen solche Probleme an falschen Rechten, dann hilft ein sudo weiter. Hier waren's aber nciht die Rechte, sondern das Verzeichnis hat gefehlt. Mit dem manuell angelegten Verzeichnis solltest du den Daemon noch mal normal starten, d. h. ohne sudo. Klappt das jetzt? Wenn nein, bitte erst einmal selbst nach der Fehlermeldung googlen,
Hier aber nicht. Wenn plötzlich mitten im Synchronisationsjob die Verbindung weg ist, sind Folgefehler wahrscheinlich. Das ist praktisch nicht zu testen, da es an jeder beliebigen Stelle auftreten kann und plötzlich erwartete Steuerungsinformationen fehlen oder eine Komponente im falschen Zustand ist. Da kann ich Qnap auch keinen Vorwurf machen. Wenn ein "unexpected error" im Zusammenhang mit einem anderen Fehler auftritt, kann man den unerwarteten Fehler besten Gewissens ignorieren.
"Connection timed out" heißt idR. dass die Gegenstelle (also das NAS, welches das Ziel für dein Backup ist) nicht mehr geantwortet hat. Das kann ein Problem auf der Gegenseite oder ein Vorfall im Netzwerk sein.
Bei der Verbindung von zwei NAS über das Internet ist oftmals eine (eventuell nur kurzfristige) Unterbrechung des Internetzugangs auf der Seite der Gegenstelle, welche aber zur Folge hat, dass die Gegenstelle eine neue IP bekommt. Der Domain-Name löst bei dir aber noch auf die alte IP auf, entweder weil der DynDNS-Server noch nichts von der IP-Änderung mitbekommen hat, oder weil die alte IP noch im lokalen DNS-Cache deines NAS ist. Damit werden die Anfragen an die falsche IP geschickt, und die Gegenstelle antwortet nicht, was zu genau diesem Fehler führt. Am nächsten Tag sind dann die Caches im NAS und beim DynDNS-Provider gelöscht, und das Backup läuft mit der neuen IP einwandfrei durch.
Der "Unexpected Error" ist nur ein Folgefehler und kann ignoriert werden.
Das Ticket kannst du dir sparen, weil der Fehler weder bei Qnap noch bei deinem NAS liegt.
Wie geht das? DIR kennt es nicht.
ls -l ist dein Freund.
Eine Liste der wichtigsten Befehle gib t es hier bei Ionos (wobei die Liste schon etwas lang ist; da sind auch einige Befehle dabei, die ich noch nie benutzt oder gebraucht habe).
Hat es denn keine fertigen Lösungen für Allerweltsaufgaben wie regelmäßige Datensicherung?
In dem Falle handelt es sich um einen Backupmechanismus eines Drittproduktes. Die MariaDB-App müsste dieses Backup in ihr GUI integrieren.
Aber dein erstes Problem ist, dass der MariaDB-Daemon scheinbar nicht läuft.
Hast du mysqld start mit vorangestelltem sudo probiert? Was ist das Ergebnis?
Eine WD My Book USB-Platte mit 6TB kostet z. B. beim Mediamarkt 140,- Euro. Die reicht für das Backup. Mehr brauchst du nicht auszugeben.
Ein Komplettes Backup der Daten ist nicht vorhanden. [...]. Ich kann auf die schnelle nur kein komplettes Backup anfertigen.
Mach das Backup jetzt!
Du wärst nicht der erste, dem das Raid um die Ohren fliegt, weil während des Rebuilds eine zweite Platte die Grätsche macht.
Ich würde mal auf den virtuellen Switch "Container Network" als Übeltäter tippen. Die Konfiguration des Switches sieht mir auch nicht gesund aus. MMn. müsste der auch am Adapter 1 hängen.
Ich hatte einmal einen Absturz in der Linux-Station (die auf der Container-Station basiert), wo auch komplettes Löschen von Linux- und Containerstation und Neuinstallation der beiden Apps nicht weitergeholfen hat. Auch habe ich es im GUI nicht geschafft, die zerbröselte Konfiguration zu kitten.
Geholfen hat letztlich, den virtuellen Switch komplett zu löschen, Linux- und Containerstation zu entfernen und neu zu installieren. Bei der erneuten Installation wurde der virtuelle Switch wieder angelegt, und diesmal mit einer funktionierenden Konfiguration. Danach lief alles.
Das könnte auch bei dir die Lösung sein. Garantie dafür gebe ich aber nicht.
(Und kurz darauf habe ich die Linux-Station endgültig gelöscht, weil sie nicht meinen Ansprüchen genügt hat. Aber das ist eine andere Geschichte.)
/usr/local/mysql/bin/mysqldump -u [Name eines Nutzers der DB mit allen Rechten] -[Passwort dieses Nutzers] [Name der zu sichernden Datenbank] >dump.sql führt mich zu
Der Dump sollte nicht mit irgendeinem Benutzer erstellt werden, sondern immer mit root, da andere Benutzer üblicherweise nicht auf alle Datenbankobjekte zugreifen dürfen, und dann fällt der Dump auf die Nase. Aber nicht das ist die Ursache für deine Fehlermeldung, sondern dass der Datenbank-Daemon nicht läuft.
root hat übrigens eine Besonderheit gegenüber anderen DB-Zugängen: Die Anmeldung kann idR. nur lokal erfolgen. Wenn du dich mit ssh am NAS angemeldet hast und greifst da auf die DB zu, dann ist das der Fall, nicht aber, wenn du auf dem PC ein Programm startest, das auf die DB zugreift.
/mnt/ext/opt/mariadb/bin/mysqld start endet in
Setz mal ein sudo davor, damit admin der User ist, der die DB startet. Das könnte deine nachfolgende Fehlermeldung erklären. Dein normaler User hat möglicherweise keinen Zugriff auf irgendwelche MariaDB-Verzeichnisse oder Dateien.
Wenn nicht, schau mal, ob es das Verzeichnis
CodeCan't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 2)
überhaupt gibt. (Ich habe MariaDB nicht als Qnap-Package installiert, sondern in einer VM, und da mögen die Pfade anders sein.)
Aber ist es nicht so, daß der Datenbankserver laufen muss, wenn die App auf dem NAS läuft?
Im Prinzip schon, nicht aber, wenn der Start des Daemons aus irgendwelchen Gründen scheitert. App stoppen (nicht deinstallieren!) und wieder starten kann auch dazu führen, dass der MariaDB-Daemon wieder läuft.
Mit den üblichen Backup-Programmen wie Time-Machine, Back-in-Time, Veeam etc. hat man üblicherweise eine Backup-Historie, ohne dass es eines Snapshots bedarf.
Wenn sich der Keller nicht 5 Etagen tiefer befinden würde, wäre das auch meine Option gewesen
Und lass mich raten, es ist nicht daran gescheitert, weil du zu faul zum runtertragen wärest 
In vielen Häusern gibt es Kabelschächte, in die dann auch noch ein LWL-Kabel passt. Manchmal kann auch ein Kabel von Kabelfernsehen dafür zweckentwendet werden. Aber in Mietwohnungen macht man dann den Aufwand doch nicht.
Dann kannste die Dateien ja von Usprungsort wiederherstellen, wenn nicht, dann jst das NAS KEIN Backup.
Im Prinzip richtig, aber dabei geht die Backuphistorie verloren, und die hätte man eigentlich schon ganz gerne. Gut, jetzt könntest du sagen, dann muss man für die Historie ein Backup vom Backup machen, aber es ist durchaus ein Kompromiss, darauf zu verzichten, und im Ernstfall verliert man halt die Historie.
Wenn das RAID 1 mit den beiden SSDs der limitierende Faktor sein sollte,
Zwei SSDs im Raid 1 können lesend 10GbE ausnutzen, schreibend hingegen nicht. Es kann aber andere Bremsen geben, z. B. Prozessorleistung, Dateigröße oder manchmal auch die Messmethode.
Selbst wenn der Qnap QNA-T310G1T Adapter nur "summen" sollte wäre das für mich am lüfterlosen MacBook Air irgendwie uncool.
Das sehe ich übrigens auch so. Es war eine sehr gute Aktion hier, das NAS in den Keller zu verbannen.
Ich werde berichten wo die Reise hingeht
Ja, mach mal.
Das muss nicht am NAS liegen, denn in anderen Anwendungen funktioniert nfs genauso wie bisher auch.
Dein Shield 2017 basiert auf Kodi. Ich würde daher mal suchen nach Problemen, die es unter Kodi mit nfs gibt.
Es könnte auch an Einstellungen für nfs auf dem NAS liegen. Zwischen nfs 3 und nfs 4 gibt es große Unterschiede. Versuch es mal, am NAS nur Version 3 und mal nur Version 4 einzuschalten, ob dir das weiterhilft.
Leider kann ich dir keine konkreteren Tipps geben, da ich das Shield 2017 nicht habe.
iscsi benötigt ein eigenes Volume. Wenn in dem Speicherpool kein Platz mehr vorhanden ist, muss ein bestehendes Volume verkleinert werden. Beim Verkleinern besteht potentiell das Risiko eines Datenverlustes (z. B. durch Stromausfall im falschen Moment). Daher ein Backup der Daten vor dem Verkleinern machen.
iscsi synchronisiert nicht zwischen den Zugriffen durch verschiedene Rechner. Wenn von zwei verschiedenen Rechnern gleichzeitig auf das gleiche iscsi zugegriffen wird, kann es Datenverluste geben.
Wenn iscsi einmal eingerichtet ist und dann nur du darauf zugreifst, gibt es kein besonderes Risiko von Datenverlusten (außer denen, die immer bestehen wie Schadprogrammen oder Fehlbedienungen, aber das betrifft Freigaben genauso).
-ppassword
Da steht jetzt sicher nicht 'password', sondern dein richtiges Passwort?
Die Fehlermeldung tritt aber üblicherweise auf, wenn der MySQL- oder MariaDB-Server (=Daemon) nicht gestartet ist. Siehe z. B. hier.
Die Meldung bedeutet, dass der Befehl mit Super-User-ID ausgeführt werden muss - also mit dem root-Account (admin).
Ein sudo vor dem Befehl tut's auch und ist das Gleiche. (Dr Mike weiß das sicherlich; das ist eine Info für BillBeaver.)
Und es geht um RJ45
Tja, Pech gehabt ...
Nimm einfach einen der von dir erwähnten Adapter von OWC oder Sonnet. Lt. Hersteller sind die tatsächlich lüfterlos. Die Geräuschlosigkeit ist den Aufpreis wert, und eine Umstellung auf sfp+ und Glasfaser/DAC wäre deutlich teurer. Da ich die beiden Adapter nicht kenne, kann ich keine weiteren Aussagen dazu machen, aber entweder er funktioniert oder er funktioniert nicht, das hast du schnell raus.
Glasfaser also SFP nehmen da Lüfterlos!
Du meinst sicherlich sfp+.
sfp ohne Plus gibt es auch. Der Unterschied ist, dass sfp nur Gigabit kann. Heute ist sfp ohne Plus deswegen nicht mehr aktuell, aber gerade, wenn man gebraucht kauft, muss man aufpassen, nicht das ältere sfp zu erwischen. sfp und sfp+ haben denselben Schacht und sind begrenzt kompatibel zueinander, manche Kombinationen funktionieren, andere nicht, aber sobald irgendwo sfp ohne Plus im Einsatz ist, ist die Geschwindigkeit auf Gigabit begrenzt.
