Visit Open-E website
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: File replication across a WAN - can't get it to work

  1. #1

    Default File replication across a WAN - can't get it to work

    Scenario. I have a DSS on an internal server serving files to users. I setup another internal server with DSS to test file replication (rsync). File replication worked fine. I rent a server in a data centre, install DSS and fully setup shares etc etc. On the internal DSS, I can setup the replication job and choose the share from the remote DSS with no problem. Every time I run the replication job it fails with destination does not exist. I check the firewall that is protecting the internal DSS and there are no errors or requests from the external DSS being blocked. I browse the forums and see mention of needing to open a tcp port from the outside to the internal address of the DSS which I do but this doesn't make any difference. Hard to understand why this would needed anyway since replication is being intiated from the internal DSS which can make any outbound connections that it likes. I also use rsync quite a bit to make a copy of internal server files on remote rync servers with no problem at all. What is special about the way that rsync works on DSS that causes this to fail? Please, please can anyone help? I have checked and double checked every setting and can see no issues and as mentioned, when done between two servers within the same network, it also works fine. Many, many thanks

    Before you point out how very insecure this arrangement is, I have restricted access to specific IPs and turned off all unnecessary protocols etc.

  2. #2

    Default

    Just to make sure that I understand, are you using the Data Replication (rsync) over a WAN?
    If so make sure you have the port 873 on the firewall.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  3. #3

    Default

    Hi, I did try this but it made no difference. I opened tcp/873 from the public IP of the hosted DSS and pointed it to the internal address of the source DSS. I am a Cisco Certified Network Professional, so I am pretty sure that I know how to this.

    I would be grateful if you could explain why the destination DSS needs to initiate a connection to the source DSS when it is the source DSS that is pushing data to the hosted DSS?

    As also stated, I already use rsync for backup of linux internal servers to hosted servers without any problems.

    Thanks,

    Martin

  4. #4

    Default

    The Destination does not need to initiate a connection. If your able to see the Shares of the Destination and your Snapshot is assigned to that NAS Logical Volume then it should work as it is that easy as you have it setup on the other servers internally.

    What does the rsync logs say on the Source server? We might want to see the logs from both systems so you might want to submit a support ticket.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  5. #5

    Default

    Tood, I did reply to this thread before, but it seems that it was not accepted, so here goes again...

    Please can explain why port 873 should be open to allow traffic from the public to reach the DSS on an internal network when it is the internal DSS that is replicating with a DSS on a public network. This just does not make sense. At the moment, it seems that I will have to configure a generic Linux with rsync running and use this as a backup destination rather than DSS, but I would prefer to use another DSS for this role.

    Thank you

  6. #6

    Default

    As stated in the manual "In order to perform data (file) replication over the Internet you have to configure the firewall port to 873." We have certain security measures. Again send the logs to support and we can review them.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  7. #7

    Default

    Todd,

    Could you tell me which exact log contains more information on why the rsync replication fails please. I have looked through and can not see which one it is. Thanks

  8. #8

    Default

    The log file is located in the GUI STATUS -> Hardware -> Function: Logs then click on the Download button. Then use a program like WinRAR to open the ..tar.gz file then search in the main dir listings for the rsync.log other logs you should look at to make sure all is ok is the Tasks, dmesg2, critical errors there are a few others and how to understand them we have a video on our website as with many other videos that you can learn logs.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  9. #9

    Default

    Todd,

    Have now got to the bottom of this, by dedicating a whole public IP address to the internal DSS using static NAT/PAT. It turns out that after the internal DSS (the source DSS on an internal IP address) initiates the replication, that the remote DSS sends an icmp packet back to the source DSS. Once this is allowed, the replication starts fine. The tcp/873 is utterly irrelevant in this scenario.

    Surely someone at Open-E knows this perfectly well. Why did I have spend so many hours discovering this for myself?

    I hope this post can help someone else...

  10. #10

    Default

    Martin,

    I was assuming that your where RTFMing from the manual "reading the fine manual"
    This is why I was mentioning the port 873 as this is clearly mentioned in the manual as I stated SEE top page of 107 in 3rd note
    down from the top explaining what to do w/ WAN replication. In the future let me know that you did not read the manual about a certain function that you are inquiring about, I am Cisco certified as well and those tests days are long over but reading the manual was critical when learning the functions.

    Adding another note: The forum is community based so forum moderators are assisting outside of their normal work hours so it is out of our free interest to help and assist.
    Last edited by To-M; 01-03-2015 at 01:37 AM.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •