Hyper Backup to another NAS - no shared folder

[bmnnit]

Hi,

i tried to create a backup job to another Diskstation, but it failed because there where no way to choose the shared folder. After some debugging i found out that hyper backup now tries to auth over the webinterface of the destination diskstation. Eh what? I dont want to have that webinterface open to the world and its nowhere in the dokumentation.

This really sucks.

Regards,
Johannes

 

[dimfil]

I believe you need Hyper Backup Vault in the destination NAS and that is supposed to simplify things..

 

[EAZ1964]

And you need the same user on target and source. This user owns both the hbbjob and the target folder.

 

[bmnnit]

And you need the same user on target and source. This user owns both the hbbjob and the target folder.

why to i need the same user?

-- post merged: 26. Jan 2023 --

I believe you need Hyper Backup Vault in the destination NAS and that is supposed to simplify things..

thats what i got, but the first time authentication now needs the destination nas to be reachable via port 5000/5001, there is some sort of authentication done. i think the hyperback on the source side pulls some sort of auth token.

-- post merged: 26. Jan 2023 --

btw i have done setups like this several time. its definitly a new "feature"

 

[EAZ1964]

the user thing, you can find this in the manual.
the HB task owner should be the same as the target folder owner.

Destination | Hyper Backup - Synology Knowledge Center

Synology Knowledge Center offers comprehensive support, providing answers to frequently asked questions, troubleshooting steps, software tutorials, and all the technical documentation you may need.

kb.synology.com

 

[Telos]

why to i need the same user?

The backup data has to have an owner. If that's not the one backing up the data, then the remote owner "owns" the data (and restoring to the original owner is not readily available).

 

[PunchCardBoss]

The backup data has to have an owner. If that's not the one backing up the data, then the remote owner "owns" the data (and restoring to the original owner is not readily available).

Goods to know. Tks @Telos.

I am in the process of configuring a remote NAS Hyper Backup now. Is it your recommendation that a User Name and Password on the backup source NAS running the Hyper Backup task be the same on the receiving (destination) NAS?

Does the user need to have Admin privileges?

Tks in advance for your guidance.

 

[Telos]

I am in the process of configuring a remote NAS Hyper Backup now. Is it your recommendation that a User Name and Password on the backup source NAS running the Hyper Backup task be the same on the receiving (destination) NAS?

Does the user need to have Admin privileges?

If you own both the source NAS and the backup NAS, then it seems easy to me to use the same account on both sides (you can create an account expressly for Hyper Backup if you desire). You must use an administrator account to set up a HB task.

If you are backing up to a friend's NAS, then it's better that you sign in to the destination NAS with an admin account that was created expressly for Hyper Backup - and not the credentials that you (or your friend) uses for NAS management. (I hope that makes some sense).

Check out this video

Set this up on a test folder containing a 2-5 files, and see how backup (2-3 runs with versioned files) and restore works, before plunging into a major backup.

 

[PunchCardBoss]

Set this up on a test folder containing a 2-5 files, and see how backup (2-3 runs with versioned files) and restore works, before plunging into a major backup.

Wanted to thank @Telos for the great suggestions. Mission accomplished.

Hyper Backup Setup & Use Observations...​

1. DESTINATION User only has permissions to "Hyper Backup Vault". No other package permissions are required. (note: I never tested removal of "Hyper Backup Vault" permissions too).
2. DESTINATION User does not need Administrator privileges. Simple user privileges only are sufficient.
3. Adding the "Hyper Backup Vault" FW rule Source = SOURCE NAS (static) IP should add a degree of security for the DESTINATION NAS.
4. Selecting "Enable client side encryption" and adding a complex password means all backup data is encrypted prior to transport and at rest on the DESTINATION NAS.
5. While logged into the SOURCE NAS as an administrator and with either the encryption password or key file, Individual backup files on the DESTINATION NAS are visible and may be restored.

Question....​

1. Is there any value from a security point of view to change the default port #6281 to something more obscure?

For the benefit of others, here is an outline of the steps I followed.​

ON THE DESTINATION NAS:​

1. Installed Hyper "Backup Vault" package
   • Add FW rule to allow "Hyper Backup Vault" at port 6281
   • FW rule Source = SOURCE NAS (static) IP.
2. Create Backup Shared drive on Volume 2
3. Create a USER with limited access
   • Only access to the Backup Shared drive.
   • Only access to specific NAS applications
   • "Hyper Backup Vault"
4. Created router port forward
   1. Port #6281 --> 192.168.X.XX

ON SOURCE NAS:​

1. Install "Hyper Backup" package and launch
2. Select "Remote NAS Device" as backup location
3. Follow setup wizard
   1. Select 1 of 5 shared drives that did not have lots of data in it as a test
   2. Select all Source NAS packages
   3. Assign "Enable backup schedule" and "Data integrity check schedule"
   4. Select "Enable client side encryption" and assign 24 character password
      1. Download password file to local PC and save on backup USB drive
   5. Disable "Enable backup rotation" (don't need it for now)
4. Run manual backup. Finished in less than 5 minutes.
   1. Test backup: used encryption password to inspected DESTINATION backup folder and individual files from SOURCE NAS login --> SUCCESS
5. Modify settings to include all desired Shared drives on Source for backup.
6. Run manual backup --> SUCCESS
7. Check to make sure backup ran at time of backup schedule --> SUCCESS

 

[Gerard]

Question....​

1. Is there any value from a security point of view to change the default port #6281 to something more obscure?

Created router port forward
4. Port #6281 --> 192.168.X.XX

I usually do a custom port forward on the router to the service port (in this case 6281). Others can correct me if I’m wrong, but if you have people out there specifically knowing hyperbackup is port 6281 and chooses to specifically scan the internet for that port, than not only do they know the port but they would know it’s a HB service because that’s what the default port is.

 

[Telos]

I usually do a custom port forward to the service port (in this case 6281).

Only to clarify Gerard's post. When setting up your backup task, obfuscate the port... Such as:

Since the Vault port cannot be changed (AFAIK), use a forwarding rule such as:

Incoming port 16888 is forwarded to NAS IP:6281 (If your source NAS external IP is fixed, you can add that IP to the incoming constraints).

 

[PunchCardBoss]

I usually do a custom port forward on the router to the service port (in this case 6281).

Incoming port 16888 is forwarded to NAS IP:6281 (If your source NAS external IP is fixed, you can add that IP to the incoming constraints).

Makes good sense.

So, now I need to figure out how to do that on my router. I have never done a port-to-port translation (if that is the correct term). It sounds like NAT (Network Address Translation)? Or can it be done through port forwarding like this?

This happens to be an Asus RT-AX88U GUI.

In this case, 16888 would be the entry on the SOURCE NAS "Hyper Backup" settings for Port Number of the DESTINATION NAS. And the above route port forward rule would be on the router in front of the DESTINATION NAS pointing to "Hyper Backup Vault".

 

[Gerard]

@PunchCardBoss That fw rule looks right, please edit the post and obscure the source nas ip. Once this works, I'd suggest to also changing the external port number to something that wasn't used here as an example.

Also, regarding the source nas ip, is that a static public ip or dyanmic from your isp? If dynamic, when/if that IP changes that connection will be blocked due to having a new ip address.

I essentially are doing the same that you are, using an OPNsense route, the only difference is that the OPNsense router allows DDNS names in addition to the use of ip address. For me, my remote site are dynamic public ips, having the ability to utilize the DDNS name is awesome because it allows only that site in and whenever the public ip changes, I won't have to worry about updating the ip on the fw rule. I wish more firewalls (such as a synology router) would implement this, I'd change over in a heartbeat.

 

[Telos]

That should work fine... until the source NAS IP changes. Port forwarding is the right way to do that.

 

[PunchCardBoss]

Also, regarding the source nas ip, is that a static public ip or dyanmic from your isp? If dynamic, when/if that IP changes that connection will be blocked due to having a new ip address.

YES. The SOURCE IP in my case is a fixed (static) IP from the ISP.

That fw rule looks right

Wow! Got it right first time. Yes, I will change the obfuscated value. I only used @Telos' value to be consistent with this thread.

Very much appreciate your advise @Gerard. I'm a living example that "old dogs CAN learn new tricks" - from good and willing teachers like you and @Telos. And for the record, I did learn my 1st programming language (Fortran) on punch cards in 1973. But this networking stuff is all new to me.

 

[Gerard]

Wow! Got it right first time. Yes, I will change the obfuscated value. I only used @Telos' value to be consistent with this thread.

Don’t forget to remove the photo which is showing the source nas public ip. Redact it and you can repost it for others to reference, but try and redact it.

 

[PunchCardBoss]

Don’t forget to remove the photo which is showing the source nas public ip

It is not the real IP address of the SOURCE NAS static IP. It is just a made up value for "show and tell" purpose of this thread. Nonetheless, I have edited my pic (above) and blocked out important areas and deleted the original pic from my profile so as to avoid confusion.

But thanks for reminding others not to reveal real public (or private) IP addresses EVER in this forum.