NAS to NAS - target folder unsichtbar
- sam2016
- Erledigt
-
Hatte ich auch. Bei mir war es ein Groß/kleinschreibproblem beim Benutzernamen.
benutzername ist halt was anderes als Benutzername.
Zudem mußt Du darauf achten, im Dialog, wo Du die Adresse des anderen NAS angibst gibt es unten einen Verbindungstest Button. Wenn der Test schon nicht läuft, ist irgendwas faul. Normalerweise sollte der von 10 an rückwärts zählen und dabei die Geschwindigkeit messen. -
Verwende zur Synchronisierung RTRR, das ist wesentlich schneller als NAS to NAS. Das habe ich letztens bei der Einrichtung der Synchronisierung zwischen 253pro und TAS-168 festgestellt. NAS to NAS ist nur bei Verwendung einer älteren NAS notwendig, die kein RTRR kann (z.B. bei meiner TS-109).
-
Wieso wird die IP neu vergeben ? Du kannst dem NAS doch eine feste IP im Netzwerk zuweisen.
Ich machs bei einer Firma genau so. Zwei NAS mit festen IP's. Der QNAP sichert die Daten auf den anderen NAS via RSync.
Der Vorteil: An den Backup NAS kommt ein Trojaner nicht dran, weil das Backup Verzeichnis für diesen nicht zugänglich ist.
Der QNAP kann aber via Port und Passwort und RSync darin schreiben. Klappt bisher auch wunderbar. Blöd ist halt nur, das diese QNAP Backup Software nur ein Verzeichnis pro Backupauftrag kann, aber auch dafür habe ich schon eine Lösung. -
Die VPN Implementation ist auch unbrauchbar da die Ziel-IP mit jedem Unterbrechen der Line neu vergeben wird und wirklich unweigerlich eine neue IP vergeben wird was NAS2NAS und auch RTRR via Tunnel unmöglich macht.
Die Problematik kenne ich ebenfalls. Ich habe es so gelöst, dass der Ziel-Nas VPN-Server ist und auf dem VPN-Klienten der Sicherungsjob läuft.
-
Wieso wird die IP neu vergeben ?
wenn du die interne qnap VPN funktion nutzt stösst du drauf. dem gerät wird nach line interrupt durch den provider eine neue IP gegeben da die alte noch nicht als unbenutzt registriert wurde, das dauert ein paar sekunden und solange ist die alte eben noch als "nicht verfügbar" gesperrt, so wird zwangsweise jedesmal eine neue vergeben. man kann das auch nicht verhindern indem man nur ein IP erlaubt, da setzt sich das system einfach drüber weg.
Die Problematik kenne ich ebenfalls. Ich habe es so gelöst, dass der Ziel-Nas VPN-Server ist und auf dem VPN-Klienten der Sicherungsjob läuft.
ja, das leuchtet ein. ich bin noch zu unsicher was wie funktioniert und ob überhaupt. von meinen 3 ts-251 ist einer schon als production server im betrieb, da kann ich nicht beliebig rumexperimentieren. hätte ich aber auch selbst drauf kommen können. danke jedenfalls für den tip!
welche backup-lösung nutzt du denn? RTRR? und wo stelle ich da diese "reverse-backup" funktion ein?
-
@sam2016
Ich nutze das interne VPN des QNAP udn nein, ich stoße da auf kein Problem mit den IP's.
"Line Interrupt durch den Provider", was auch immer das heißen soll. Ich vermute mal, Du meinst die Zwangstrennung alle 24h, die irgendwann mal vor 4 oder 5 Jahren abgeschafft wurde.
Allerdings weiß ich nicht, was die mit deinen INTERNEN IP's zu tun haben soll.
Oben in deinen Bildern sieht man deutlich, das Du für das externe Gerät eine LOKALE IP auf dem Adressbereich 192.168.2.x angegeben hast. Diese bleibt auch immer die selbe, egal was dein Provider macht. Da kann der überhaupt nicht dran.
Wenn Du jetzt die IP meinst, mit der Du die VPN Verbindung aufbauen willst, dafür gibt es ausreichend DynDNS Dienste im Internet, die von den heutigen Routern auch problemlos unterstützt werden.Vielleicht holst Du mal ein weniger weiter aus, wie sich dein Problem den genau darstellt. Aus dem bisher geschriebenen kann ich keines ableiten.
-
Ich nutze das interne VPN des QNAP udn nein, ich stoße da auf kein Problem mit den IP's.
"Line Interrupt durch den Providerich nutze den openVPN server weil ich den kenne, da tritt das problem auf, wie ja auch kollege phoneo bestätigt. wie sich die anderen server verhalten weiss ich nicht. wie bereits oben erwähnt ist das problem mittels fritz-vpn gelösst.
was die zwangsabschaltung angeht verhalten sich die diversen anbieter wohl nicht einheitlich, bei uns wird alle 24h getrennt. das wäre aber auch egal da immer mal der strom am router ausfallen kann, sei es nur dass jemand versehentlich den stecker zieht oder die sicherung fliegt. ich bin dann nicht immer vor ort um das neu zu konfigurieren. aber wie gesagt: fritz hats gelösst. -
Ich arbeite noch mit Rsync über VPN (früher noch per SSH) zwecks Datentransfer zwischen zwei Standorten. Auf dem Backup-Nas liegen die Daten einmal als 1:1 Spiegel und werden mit rsnap zusätzlich inkrementell gesichert. Da die Internetverbindung providerbedingt manchmal Störungen hat, habe ich den Zwischenschritt über den Spiegel gewählt. Bei Störungen wird dann im schlechtesten Fall der Spiegel nicht komplett aktualisiert, die inkrementellen Backups aber immer sauber und vollständig geschrieben.
Das ist historisch so gewachsen. Würde ich heute starten, würde ich auch RTRR nutzen. Wie zuverlässig die "reverse-backup" Funktion ist, kann ich allerdings nicht beurteilen. Weiß auch leider nicht, wo man die konfiguriert. rsnap ist momentan aber auch nicht ohne Probleme nutzrbar, der Entwickler muss noch die Installationsroutine nacharbeiten.Nachtrag: "Backup Versioning" ist noch im Beta-Status und im QNAP-Store unter Beta Lab zu finden.
-
rsnap ist momentan aber auch nicht ohne Probleme nutzrbar, der Entwickler muss noch die Installationsroutine nacharbeiten.
ja danke für den tip!!! ich war grad dabei mit rsnap eine inkrementelle sicherung einzurichten um gegen die verschlüsselungsviren abgesichert zu sein. aber wenn das nicht funktioniert bin ich erstmal ratlos - wie schwerwiegend sind denn die bugs in rsnap?
-
rsnap läuft stabil und ich würde bei der aktuellen Problematik nicht von Bugs reden, zumindest nicht was den Backup-Prozess angeht. Es ist wohl eher ein Installationsbug:
Für rsnap war bisher immer als Installationsvoraussetzung das IPKG-Paket (Optware) erforderlich. Dieses Paket wird nicht weiter gepflegt und hat bekannte Sicherheitslücken. Mittlerweile hat sich ein anderes Paket, entware-ng etabliert. rsnap ist vermutlich noch nicht richtig auf das neue Paket umgestellt. Ich erwarte jedenfalls sehnsüchtig ein Update, Lutz! @frosch2Noch ein klärender Hinweis zur IP-Diskussion.
Die QNAP-Nas und die Fritz-Router nutzen OpenVPN in unterschiedlichen Modi. Die Fritzboxen erstellen eine VPN-Verbindung im Bridging: Die Subnetze der Standorte werden gebrückt, so dass alle Netzteilnehmer sich untereinander über lokale IP-Adressen (z.B. 192.168.x.x) ansprechen können.
Die QNAPs dagegen erstellen eine VPN-Verbindung im Routing-Modus. Das ist in erster Linie eine Punkt-zu-Punkt-Verbindung zwischen zwei Geräten. Hier wird ein virtuelles Subnetz im Adressraum 10.8.0.X aufgebaut. -
Nachtrag: "Backup Versioning" ist noch im Beta-Status und im QNAP-Store unter Beta Lab zu finden.
ich ab das jetzt installiert, und laut info soll es sich ja ins RTRR integrieren. Ich habe draufhin einen neuen RTRR Job konfiguriert, aber nirgends die option Versionskontrolle entdecken können. Wo versteckt sich das bitte? oder muss das nas neu gestartet werden? ist doch linux, sollte eigentlich nicht nötig sein oder?
OK, ich habs gefunden, man muss zuerst einen auftrag erstellen, DANACH auf bearbeiten gehen und dann erscheint rechts oben der reiter version control - aber ausgegraut, also nicht zugänglich :((
Unter Qsync Central station ist version control enabled.
Unter File Station wo es neben "Erlaubnis" als reiter (rechts im Bild) erscheinen sollte taucht es aber nicht auf.
