Synology Hyper Backup Destination Offline over Tailscale

Use the current task state, message, logs, and Version List rather than elapsed time alone.[11][12]

• It cannot connect to the remote destination → Was reachability tested from the source NAS itself?
• Still running, with no error shown → This is a slow-task workflow, not a connection failure
• Suspended, quota, Restore Only, or another explicit state → This is a different troubleshooting state
• I have not checked → Check the task state, message, logs, and Version List

Record the current task state and message and inspect the task logs and Version List when available. A non-connection state is a stronger boundary than elapsed time.[11][12]

Continue this workflow only for a connection failure to the remote destination.[11]

• A connection failure to the remote destination → Was reachability tested from the source NAS itself?
• Running, with no error shown → This is a slow-task workflow, not a connection failure
• Suspended, quota, Restore Only, or another explicit state → This is a different troubleshooting state

A task that is still running without an error needs the taking-longer-than-expected diagnosis. Preserve the state, message, and logs and follow the link in Next actions.[14][11]

Suspension, quota, integrity-check, and Restore Only states have their own workflows. Preserve the exact state, message, and log entry and use the matching diagnosis; no path is implied here.[11][12]

A destination that opens from a laptop or phone is comparative evidence only. It does not establish that the source NAS has a working Tailscale path to the destination.[2][5]

• Yes, from the source NAS or an equivalent vantage point → Is the destination NAS listed in the tailnet?
• Only from a laptop, phone, or another client → Client reachability is comparative evidence only
• I cannot test from the source NAS → Establish a source-NAS observation first

Do not recreate the task based on a laptop or phone result. Test peer visibility and the Tailscale path from the source NAS context before changing task settings, routes, or firewall rules.[2][5]

Record which side was actually tested and what was observed. An untested source path is unknown, not a confirmed Tailscale or Hyper Backup cause.[5]

Compare tailscale status with the Machines page of the admin console from the testing context.[2][5]

• Yes, the destination NAS is listed → Does tailscale ping to the destination Tailscale IP succeed?
• No, it is missing → Resolve peer membership or policy first
• I have not checked → Check the expected tailnet and peer

Run tailscale status and compare the destination NAS with the Machines page. Confirm the expected tailnet and authentication state.[2][5]

A listed destination proceeds to the Tailscale path check; a missing destination stays with membership, authentication, and policy diagnosis.[2][5]

• Yes, the destination NAS is listed → Does tailscale ping to the destination Tailscale IP succeed?
• No, the destination NAS is missing → Resolve peer membership or policy first

A missing peer is not yet a Hyper Backup service-port problem. Verify authentication, the expected tailnet, and whether the effective tailnet access policy permits the peer to appear, including the documented re-authentication flow after a package reinstall.[1][2][5]

Use the destination Tailscale IP for this discriminator, tested from the source NAS context. A path result is separate from destination service reachability.[2][4]

• Yes → Which address does the Hyper Backup task use?
• No → Is the source NAS on DSM 7 without outbound Tailscale access?
• I have not tested it → Run the Tailscale path check

Run tailscale ping with the destination Tailscale IP from the source NAS context. Record whether it succeeds and whether the path is direct or relayed.[2][4]

A successful path check continues to address and service-port diagnosis; a failed check stays with source-side outbound access, peer, policy, or firewall diagnosis.[5][4]

• Yes, it succeeds → Which address does the Hyper Backup task use?
• No, it fails → Is the source NAS on DSM 7 without outbound Tailscale access?

On DSM 7, inbound Tailscale connections are allowed by default, but other NAS applications need the documented TUN procedure for outbound access. On DSM 6, Tailscale runs as root and this step is not required.[1]

• DSM 7 source, TUN procedure not yet applied → Apply the conditional DSM 7 outbound procedure
• DSM 6 source, or TUN already applied → Stay in the Tailscale path and control-plane branch
• Source system is not established → Record the source system before a change

This branch applies only because the failing direction is outbound from an application on a DSM 7 source NAS. Follow the Tailscale Synology outbound-connections procedure as a separate change, then retest the same path observation. Do not use this branch for inbound failures or DSM 6 systems.[1]

Check client version, authentication, incoming-connection preference, and the tailnet access policy before changing a Hyper Backup setting. A failed path check does not identify which control is responsible.[5][8][6]

Record the source DSM version, Tailscale version, and whether the outbound TUN procedure was applied. An unestablished system is unknown, not a confirmed cause.[1]

Read the configured destination address in the task. Compare it with the destination Tailscale IP from status output.[11][2]

• The destination Tailscale IP → Does TCP 6281 (Vault) respond on the destination Tailscale IP?
• A MagicDNS name → Does the same service work by IP but fail by MagicDNS name?
• A LAN address, another hostname, or unknown → Compare the task address with the Tailscale IP

Test the same destination service by Tailscale IP and note whether the configured address is a LAN address, another hostname, or unestablished. Keep the service and port constant so only the address changes.[2][9][1]

A LAN address is a different path from the Tailscale IP test; confirm with the Tailscale IP before changing anything else.[2][9][10]

• Tailscale IP works, name fails → This is a name-resolution branch
• Both fail → Does TCP 6281 (Vault) respond on the destination Tailscale IP?
• The task uses a LAN address → Retest with the destination Tailscale IP

Compare the same service and port so that hostname resolution is the only changed variable.[2][9][10]

• Yes, only the name fails → This is a name-resolution branch
• No, both fail → Does TCP 6281 (Vault) respond on the destination Tailscale IP?
• I am not sure → Compare the task address with the Tailscale IP

Keep the working IP path unchanged. Inspect the testing context's Tailscale DNS preference and local, upstream, and tailnet DNS settings before changing the task address.[8][10]

A LAN address failure does not describe the Tailscale path. Confirm the destination Tailscale IP from status output and repeat the service-port test with it before changing task settings.[2][1]

For a remote Synology NAS destination, TCP 6281 is the primary documented service port for Hyper Backup Vault. Test that port from the source NAS context using tailscale nc. If it responds, the Vault service is reachable on that port, but for a DSM 7+ destination this does not establish that all required services are available; TCP 5000 (HTTP) and TCP 5001 (HTTPS) are also listed as documented ports and may be needed for the backup workflow.[2][3][14][13][15]

• Yes, 6281 responds → The tailnet path and Vault port 6281 are available
• No, 6281 is blocked or closed → Inspect the service, policy, and DSM firewall
• I have not tested it → Identify the configured destination service port

Read the port from the task destination settings. For a remote Synology destination, the primary documented service port is TCP 6281 for Hyper Backup Vault. Do not assume other services share that port, and note that DSM 7+ destinations also list TCP 5000 (HTTP) and TCP 5001 (HTTPS) as documented ports.[14][13][15][20]

Run tailscale nc with the destination Tailscale IP and that exact port, then choose the observed result.[2][3]

• Yes, the port responds → The tailnet path and Vault port 6281 are available
• No, the port is blocked or closed → Inspect the service, policy, and DSM firewall

TCP 6281 responds on the destination Tailscale IP, which establishes that the Vault service is reachable on that port. For a DSM 6 destination this is sufficient for the service-port check. For a DSM 7+ destination, the official Synology service-ports reference also lists TCP 5000 (HTTP) and TCP 5001 (HTTPS); proceed to verify the destination DSM version.[11][13][15][2]

• Destination runs DSM 7 or later → Test TCP 5000 (HTTP) on the destination Tailscale IP
• Destination runs DSM 6 → DSM 6 documented port is available
• Destination DSM version is not established → Check the destination DSM version

On the destination, open DSM Control Panel > Info Center > General to check the DSM version. Alternatively, inspect the Hyper Backup Vault package version. DSM 6 and DSM 7+ have different documented port requirements for the remote NAS backup workflow.[13][15]

DSM 7+ lists TCP 5000 (HTTP) and TCP 5001 (HTTPS) in addition to Vault port 6281. DSM 6 Vault uses port 6281 alone.[15][20]

• DSM 7 or later → Test TCP 5000 (HTTP) on the destination Tailscale IP
• DSM 6 → DSM 6 documented port is available

For a DSM 7+ destination, the documented Hyper Backup Vault port list includes TCP 6281, TCP 5000 (HTTP), and TCP 5001 (HTTPS). The Vault port 6281 is already confirmed; now test TCP 5000 on the destination Tailscale IP using tailscale nc. A Vault port 6281 success does not establish that the management ports are reachable.[2][3][15][20]

On DSM 7+, the official Synology service-ports reference lists TCP 5000 (HTTP) as a required port for Hyper Backup Vault. If it does not respond, continue at the service layer: the Tailscale path is proven, Vault is proven on 6281, but a required management port is not available.[20][13]

• Yes, TCP 5000 responds → Test TCP 5001 (HTTPS) on the destination Tailscale IP
• No, it is blocked or closed → Vault port 6281 works but TCP 5000 is not reachable

TCP 5000 is confirmed. Now test TCP 5001 (HTTPS) on the same destination Tailscale IP using tailscale nc. The official service-ports reference lists both 5000 and 5001 as required for Hyper Backup Vault on DSM 7+.[2][3][20]

TCP 5001 is the second management port listed in the official Synology service-ports reference for Hyper Backup Vault on DSM 7+. If both 5000 and 5001 respond, all documented Vault ports (6281, 5000, 5001) are confirmed. If only one management port responds, continue at the service layer.[20][13]

• Yes, TCP 5001 responds → All documented DSM 7+ Vault ports are available
• No, it is blocked or closed → Only one management port responds

For a DSM 6 destination, TCP 6281 is the only documented port for Hyper Backup Vault. The service-port check is complete. Continue with the task's own destination account and configuration following the official task documentation. Do not change Tailscale routing based on this result alone.[11][15][20][2]

TCP 6281, TCP 5000 (HTTP), and TCP 5001 (HTTPS) all respond on the destination Tailscale IP. These are the three ports listed in the official Synology service-ports reference for Hyper Backup Vault on DSM 7+. Continue with the task's own destination account and configuration following the official task documentation. Do not change Tailscale routing based on this result alone.[11][15][20][2]

The Tailscale path, Vault port 6281, and one management port (5000 or 5001) are proven, but the second management port is not reachable. The official Synology service-ports reference lists both TCP 5000 and TCP 5001 as required for Hyper Backup Vault on DSM 7+. Verify on the destination that the other management service is enabled, running, and not blocked by the DSM firewall or tailnet policy. Do not declare Tailscale the cause or conclude that all documented ports are available based on this partial observation alone.[20][13][17][6][5]

Verify that Hyper Backup Vault is running on the destination and Preview the tailnet rule for port 6281. On DSM 7+, also check whether TCP 5000 (HTTP) and TCP 5001 (HTTPS) are enabled and reachable; the official Synology service-ports reference lists all three ports for Hyper Backup Vault on DSM 7+. On DSM 7, inspect the first matching firewall rule; DSM 6 controls must be verified separately. A silent port continues at this service layer and does not declare Tailscale the cause.[13][15][7][5][17]

The Tailscale path and Vault port 6281 are proven, but TCP 5000 (HTTP) on the destination is not reachable from the source NAS. On DSM 7+, the official Synology service-ports reference lists TCP 5000 as a required port for Hyper Backup Vault. Verify on the destination that the DSM HTTP service is enabled, running, and not blocked by the DSM firewall or tailnet policy. Do not declare Tailscale the cause or recreate the task based on this partial-port observation alone.[20][13][17][6][5]