{"id":1856,"date":"2022-09-21T15:32:06","date_gmt":"2022-09-21T15:32:06","guid":{"rendered":"https:\/\/www.dev-metal.ch\/?p=1856"},"modified":"2022-09-23T20:07:03","modified_gmt":"2022-09-23T20:07:03","slug":"synchronisation-hc4-nas-nach-qnap-ts-109","status":"publish","type":"post","link":"https:\/\/www.dev-metal.ch\/?p=1856","title":{"rendered":"Synchronisation HC4 NAS nach Qnap TS-109"},"content":{"rendered":"<p><a href=\"https:\/\/www.dev-metal.ch\/?p=73\" target=\"_blank\" rel=\"noopener\">Hier<\/a> habe ich beschrieben, wie man einen rsync-job von eine Thecus NAS nach Qnap TS-109 einrichten kann. Mittlerweile ist mein Thecus NAS Geschichte. Stattdessen l\u00e4uft das NAS, basierend auf einem <a href=\"https:\/\/www.dev-metal.ch\/?p=1659\" target=\"_blank\" rel=\"noopener\">Odroid HC4<\/a> in meinen 4 W\u00e4nden.<\/p>\n<p>Das HC4 NAS verf\u00fcgt zwar \u00fcber ein Raid1. Aber die wichtigsten Daten sollen 1:1 noch auf ein weiteres Backup NAS (TS-109) kopiert werden.<\/p>\n<p>Damit Rsync funktioniert muss ein Ger\u00e4t als Server und eines als Client agieren. Dabei stellt der Client als Initiator eine Verbindung zum Server her und l\u00e4dt Files herunter oder transferiert Files zum Server.<\/p>\n<h1>HC4 NAS (Rsync Server)<\/h1>\n<p>Das HC4 wird als RSYNC Server installiert (im Sinne eines Dienstes):<\/p>\n<pre>sudo apt-get install rsync<\/pre>\n<p><span id=\"RSYNC_auf_Thecus_konfigurieren_Source-Daten\">Nach der Installation von rsync m\u00fcssen zwei Dateien erstellt werden.<br \/>\n<\/span><\/p>\n<h3>Konfigurations-Datei<\/h3>\n<pre>sudo vi \/etc\/rsyncd.conf<\/pre>\n<p>Diese mit folgendem Inhalt bef\u00fcllen:<\/p>\n<pre>pid file = \/var\/run\/rsyncd.pid\r\nlock file = \/var\/run\/rsync.lock\r\nlog file = \/var\/log\/rsync.log\r\n#hosts allow = 192.168.2.254:255.255.255.0\r\nhosts allow = 192.168.1.101\r\n\r\n[testData]\r\npath = \/mnt\/test123\r\ncomment = RSYNC FILES\r\nread only = true\r\ntimeout = 300\r\nuid = sys\r\ngid = nogroup\r\n#auth users = rsync1\r\n#secrets file = \/etc\/rsyncd.secrets<\/pre>\n<p>Der rsync-Zugriff erfolgt in diesem Falle \u00fcber den user \u201csys\u201d. Hier kann ein beliebiger User konfiguriert werden. Es ist aber wichtig, dass dieser User auch entsprechende Rechte auf dem lokalen Ordner (\/mnt\/test123) besitzt. Es k\u00f6nnen beliebig viele solcher \u201crsync-shares\u201d erstellt werden. Es ist damit auch m\u00f6glich nur einzelne Unterverzeichnisse zu synchen:<\/p>\n<p>auth users<br \/>\nHier kommen die Benutzer, die Zugriff auf dieses Modul haben werden. Diese Benutzer m\u00fcssen nicht unbedingt auf dem System vorhanden sein. Dies sind rsync-Benutzer, die in der Secrets-Datei aufgef\u00fchrt sein sollten, die in der n\u00e4chsten Zeile der Konfigurationsdatei beschrieben wird.<\/p>\n<p>secrets-Datei<br \/>\nDas ist die Datei, in der die rsync-Benutzer erstellt werden und die f\u00fcr den Rsync-Server zum Lesen verf\u00fcgbar ist.<\/p>\n<h3>Secrets-Datei<\/h3>\n<p>Wenn man die Autentifizierung anwenden m\u00f6chte, muss entsprechend noch die Secrets-Datei erstellt werden.<\/p>\n<p>Die Secrets-Datei wird in \/etc mit dem Namen rsyncd.secrets erstellt und enth\u00e4lt die Paare aus Benutzernamen und Passwort, welche von rsync gepr\u00fcft werden.<\/p>\n<pre>sudo vi \/etc\/rsyncd.secrets<\/pre>\n<p>Mit folgendem Inhalt bef\u00fcllen<\/p>\n<pre> rsinc1:beispielPassword<\/pre>\n<p>Wie wir sehen, ist das Passwort direkt als Text und unverschl\u00fcsselt abgelegt. Deswegen ist es eine gute Idee nach Erstellung dieses Files den Zugriff nur noch f\u00fcr Root zu erlauben:<\/p>\n<pre>sudo chmod 0640 \/etc\/rsyncd.secrets<\/pre>\n<h3>Starten des Rsync-Server Dienstes<\/h3>\n<pre>sudo rsync --daemon<\/pre>\n<p>Es folgt keine weitere Meldung von rsync. Man kann aber \u00fcberpr\u00fcfen, ob der rsync daemon l\u00e4uft:<\/p>\n<pre>ps -ef | grep rsync-----\r\nroot 821310 1 0 17:23 ? 00:00:00 rsync --daemon<\/pre>\n<p>Auch das Log best\u00e4tigt, dass alles ok ist:<\/p>\n<pre>$ tail \/var\/log\/rsync.log\r\n2022\/09\/22 17:23:20 [821310] rsyncd version 3.2.3 starting, listening on port 873<\/pre>\n<p>RSYNC beim Booten starten<\/p>\n<pre>sudo systemctl enable rsync<\/pre>\n<p>Zus\u00e4tzlich:<br \/>\nDieser Service soll nach dem mounten der btrfs Shares durchgef\u00fchrt werden. Deswegen setze ich das \u201cAfter Target\u201d auf \u201cAfter=runlevel4.target\u201d<\/p>\n<pre>sudo vi \/etc\/systemd\/system\/multi-user.target.wants\/rsync.service\r\n\r\n...\r\nAfter=runlevel4.target\r\n...<\/pre>\n<h1>Qnap TS-109<span id=\"RSYNC_auf_Qnap_TS-109_konfigurieren_Target-Data\"> (Rsync Client)<\/span><\/h1>\n<p>Das Qnap TS-109 ist das Zielger\u00e4gt bzw. das &#8222;target&#8220; wohin die Dateien aus dem HC4 kopiert werden sollen.\u00a0 Es initiiert in der Rolle als &#8222;Client&#8220; eine Verbindung zum Rsync Server und kopiert anschliessend die Daten:<\/p>\n<ul>\n<li>Login \u00fcber das Qnap TS-109 Webinterface<\/li>\n<li>Erstellen der Zielverzeichnisse. z.B. \u201cBackupHC4\/test123\u201d, etc.<\/li>\n<li>Das Qnap TS-109 liefert bereits ein SSH-Login Plugin mit. Dieses aktivieren.<\/li>\n<li>Login \u00fcber SSH<\/li>\n<li>Das Qnap TS-109 liefert ebenfalls bereits rsync out of the box mit.<\/li>\n<li>Nun k\u00f6nnen auf dem Qnap TS-109 rsync Befehle gegen das HC4 ausgef\u00fchrt werden.<br \/>\nFolgender Befehl kopiert alle Daten aus dem HC4 Source-Verzeichnis \/mnt\/test123 in das Qnap TS-109 Zielverzeichnis \/share\/HDA_DATA\/BackupHC4\/test123\/.<br \/>\nParameter delete = gel\u00f6schte Dateien werden auch in der Sicherung gel\u00f6scht<br \/>\nParameter stats = zeigt einen ausf\u00fchrlicheren Report am Ende einer \u00dcbertragung an.<\/li>\n<\/ul>\n<pre class=\"\">rsync -a --delete --stats hc4IP::testData \/share\/HDA_DATA\/BackupHC4\/ralwet_data<\/pre>\n<h2><span id=\"Backup_automatisieren\">Backup automatisieren<\/span><\/h2>\n<p>Nun, da rsync funktioniert ist es Zeit das ganze automatisiert, in regelm\u00e4ssigen Zeitabst\u00e4nden auszuf\u00fchren.<\/p>\n<ul>\n<li>copy_all.sh File unter \/mnt\/HDA_ROOT erstellen<\/li>\n<\/ul>\n<pre>cd \/mnt\/HDA_ROOT\r\nvi copy_all.sh<\/pre>\n<p>Script:<\/p>\n<pre class=\"\">#!\/bin\/sh\r\n#\r\n# called by cron to backup the HC4 NAS to the Qnap TS-109 via rsync\r\necho \"start backup via rsync : `date`\"\r\necho \"syncing folder : test\"\r\nrsync -a --delete --stats hc4IP::testData \/share\/HDA_DATA\/BackupHC4\/ralwet_data\r\necho \"end backup via rsync : `date`\"\r\necho \"+++++++++++++++++++++++++++++++++++++++++++++++++\"<\/pre>\n<p>File ausf\u00fchrbar machen<\/p>\n<pre>chmod +x copy_all.sh<\/pre>\n<p>Nun die crontab des Qnap TS-109 anpassen (\u201ccrontab -l\u201d listet die aktuellen Eintr\u00e4ge auf)<\/p>\n<pre>vi \/etc\/config\/crontab\r\n<\/pre>\n<p>folgenden Eintrag hinzf\u00fcgen. Das Script wird nun jeden Sonntag um 1:00 Uhr ausgef\u00fchrt. Die Logdatei wird in das Root-Verzeichnis des Backups geschrieben.<\/p>\n<pre class=\"\">0 1 * * 0 \/mnt\/HDA_ROOT\/copy_all.sh &gt;&gt; \/share\/HDA_DATA\/BackupHC4\/rsync.log 2&gt;&amp;1\r\n<\/pre>\n<p>crontab neu laden<\/p>\n<pre>crontab \/etc\/config\/crontab\r\n<\/pre>\n<p>cron restarten<\/p>\n<pre>\/etc\/init.d\/crond.sh restart<\/pre>\n<h1>Links<\/h1>\n<ul>\n<li><a href=\"https:\/\/rsync.samba.org\/how-rsync-works.html\" target=\"_blank\" rel=\"noopener\">https:\/\/rsync.samba.org\/how-rsync-works.html<\/a><\/li>\n<li><a href=\"https:\/\/www.experiencingit.net\/linux\/install-and-configure-rsync-daemon\/\" target=\"_blank\" rel=\"noopener\">https:\/\/www.experiencingit.net\/linux\/install-and-configure-rsync-daemon\/<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Hier habe ich beschrieben, wie man einen rsync-job von eine Thecus NAS nach Qnap TS-109 einrichten kann. Mittlerweile ist mein Thecus NAS Geschichte. Stattdessen l\u00e4uft das NAS, basierend auf einem Odroid HC4 in meinen 4 W\u00e4nden. Das HC4 NAS verf\u00fcgt zwar \u00fcber ein Raid1. Aber die wichtigsten Daten sollen 1:1 noch auf ein weiteres Backup [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[10],"tags":[],"class_list":["post-1856","post","type-post","status-publish","format-standard","hentry","category-techdocs"],"modified_by":"ralph","_links":{"self":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/1856","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1856"}],"version-history":[{"count":20,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/1856\/revisions"}],"predecessor-version":[{"id":1876,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/1856\/revisions\/1876"}],"wp:attachment":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1856"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}