Skip to content
English
Sign in
Contact us
  • There are no suggestions because the search field is empty.

Fix "switching to cache channel" backup log error; which means that the client machine can't reach the storage server endpoint address

What This Error Means

When you see this single error in your backup (and possibly also will be seen in a restore function or a device import function) log:

  • "Could not proceed due to internal error: switching to cache channel : pos: create bucket error - encountered network error when sending http request"

It means that the NovaBACKUP client's FPI modern backup engine (engine.exe is the process name) cannot reach the storage server address ("us1.storage.online-backup.com" being the primary DNS address that it will attempt to utilize there), usually because:

  • Your local client computer cannot resolve via DNS the storage server endpoint URL address value that the 'Cloud Backup' device uses (that is a DNS based address that it must be able to resolve) of "us1.storage.online-backup.com", without the quotes, due to a not good or not robust DNS Server address is being used either on just that single client machine, but more often than not it will affect all computers on that same LAN, is what has been configured on the network adapter card that will attempt the connection via the network adapter that has the active internet connection on it currently (this is by far the most common cause of the stated error and issue). Note: We have seen that out the blue it can happen that your normally ISP provided DNS Server is no longer able to resolve that DNS address, where it was working fine for months or years prior to that to be able to resolve and connect to that same DNS addess. To deal with that we've seen that 80% of our Cloud customers can fix this by replacing their DNS Server address with a better and more robust public DNS Server address, such as Google and CloudFlare public DNS server addresses, on the client machine.
  • If the issue is NOT with your DNS Server not able to resolve the storage server endpoint URL address value, then there is some other network problem that you will need to troubleshoot, that could be due to either a sw or hw Firewall, or a Anti-Virus app, or a VPN client issue (normally on the client machine end), that is causing the client machine to not be able to make the connection to that DNS address value, or there is a VPN connection that for some reason that VPN network adapter does not have a good enough DNS Server specified that would cause it not to be able to resolve that DNS record in the end, to be able to reach the storage server DNS address. Some AV products also have VPN function in them, that you can try to disable, of you can uninstall or entire AV app, at least temporarily, along with disabling the sw Firewall, and VPN client connection and the network adapter that most modern VPN clients will install as well. Try to isolate your network adapter to a single network adapter on the client machine to be able to make troubleshoot network and/or DNS resolution issues easier to handle.

Quick Fixes (Try These First!)

Step 1: Check if you can even "ping" and "nslookup" the 'Cloud Backup' device type device's storage server endpoint URL address value (which is always a DNS address, that always equates to the "URL" variable value inside a 'Cloud Backup' device type device in that case

We have seen that defining better or more robust publicly accessible DNS Server address(s) (such as Google DNS and CloudFlare DNS Servers) on your primary internet network adapter card we have seen will fix about 80% of the stated error cases!

  1. Disable all software and hardware based Firewalls, and Anti-Virus app functions, and VPN connections (and VPN network adapters). Then see if you can pass a "ping" test and a "nslookup" test with the storage server endpoint URL (DNS address value) that you will discover in Step 2. Note: The majority of our customers that utilize our own hosted and managed NovaBACKUP Cloud Backup devices utilize the "us1.storage.online-backup.com" URL (DNS address value). If you can't pass a "ping us1.storage.online-backup.com" command via a Command Prompt or PowerShell session on the backup client machine that is producing a backup log with the stated error in it, then that is the problem, due to the address can't be resolved via DNS on that machine, which we require to be able to resolve via DNS on the NIC (the network interface card that is connected to the internet).

  2. Verify for sure what the 'Cloud Backup' device type device's storage server endpoint address "URL" value is, which is the URL that is always in DNS format (not in IP address format), that is utilized by your 'Cloud Backup' device type device, in order to know what that address that you will perform "ping", and "nslookup", and PowerShell TCP tests on is:

    • Open the NovaBACKUP client app
    • Go to the Device tab
    • Click Properties on your 'Cloud Backup' device type device, and the majority of the time that would be called "NovaBACKUP Cloud Storage" in that case, to check what the  "URL" field value is there (which equates to the "Storage Server Address" DNS address value, but you would have to make sure to remove the "http://" or the "https://" prefix in that addess keep in mind). Note: Only unmanaged 'Local Backup' devices can have their Properties viewed via the client GUI. If the "Properties" button is grayed out for that device in the "Device" tab after you did select your backup device, that is due to that device is a "Managed" 'Local Backup' device, that was created via the CMon UI, so in that case you can use the CMon web UI to view the Properties of that backup device there (in the "Agent > Devices" tab), and then once the 'Cloud Backup' device type device is viewed there it will tell you what the "URL" variable value is there.

  3. Do a "ping" test to the now known and verified in Step 2 storage server endpoint URL (DNS address) value:

    • Start a Admin Command Prompt or a Admin PowerShell session, go to Start Menu and type in the word "cmd" or "PowerShell" there without the quotes and right click and run either of those standard apps with Admin rights.
    • Type in the command "ping storage.server.address" without the surrounding quote characters, for whatever the actual storage server endpoint URL (DNS address format) equates to, that you were able to know and confirm about what that value was in Step 2 above. Note: In most cases for most of our own managed NovaBACKUP Cloud Backup customer's that DNS address value will equate to "us1.storage.online-backup.com", without the surrounding quotes (do not include the "http://" or "https://" portion or prefix of the text in the "URL" variable value, that you were required to record in Step 2 above). If the "ping" result is a failure to resolve that DNS address value, or it fails to ping that address then that is the problem. If it passes then it is due to another problem, that is outside of the scope of this KB article here. Continue on or skip to the "In Windows go to the Start Menu and type in "Control Panel" and then go to "Control Panel > Network Connections .." paragraph in this same section, where you will be manually adding at least one public DNS server address to your primary NIC (network adapter) in that step.
    • Type in the command "nslookup storage.server.address" for whatever the actual storage server DNS address equates to, that you were able to know about what that value is in Step 2. Note: In most cases for most customer's that DNS address value will equate to "us1.storage.online-backup.com", without the surrounding quotes. If the "nslookup" result is failed, or it fails to resolve that address then that is the problem. If it passes then it is due to another problem, that is outside of the scope of this KB article here.
    • Find out via the "nslookup" command that you ran above, for the first two lines in the command output, which network interface adapter is attempting the "nslookup" command to that DNS addess, that should be stated in that first part of the output in that case, in the first two lines of text in that output. Make note of which network adapter that is, as that is the network adapter that you will be modifying next for the Properties of it, to manually add at least one good and robust public DNS Server address to it (which we often see can fix the stated issue).
    • In Windows go to the Start Menu and type in "Control Panel" and then go to "Control Panel > Network Connections" and in that dialog locate the primary NIC (network interface card) that is the network adapter that your internet traffic is currently routing through, which should be the network adapter name that is displayed in the first two lines of the "nslookup" command output in that case, and then do a right-click properties on that network adapter.
    • Right-click Properties on the "TCP/IPv4 Parameters" part of that network adapter to view and edit the Properties of it.
    • Go to "DNS Server Settings" setting in that dialog, and if it is already  set to "Use Automatic DNS Servers", then open an "Admin Command Prompt" session on that client machine and issue the command "ipconfig /all" to confirm and record the "DNS Servers" address(s) on the internet connected network adapter, that are already address(es) that are present coming from your DHCP Server right now, before you make any changes next, and after at least 1 x DNS Server address in that variable value has been recorded for the actual IP address value that already was being utilized on that network adapter , then switch it to use  "Manual DNS Servers" and define these additional public DNS Server addresses there, from the top down, in this exact order:

      8.8.8.8
      4.4.4.4
      1.1.1.1
      and then add the already prior recorded "DNS Servers" variable value, for the at least 1 x existing DNS Server IPv4 address that you already did have record (that was seen in the "ipconfig /all" command output) and be sure to move that entry down to the bottom of the order whatever the original DNS Server address was when you first edited this property, so that the original first DNS Server address is now to be located AT THE BOTTOM of this list, in that exact order, as if you do end up leaving the first DNS Server address at the top of the order of DNS Server addresses, the issue may still persist in that case we have seen.
    • Now retry the first "ping" command in this Step 1. It may work now to be able to resolve that address to accurately ping it, to resolve to a "wasabi" address and show the ping results under the command output as normal, instead of failing to ping which you likely did see before at the start of this step first part of it.

  2. Perform a PowerShell TCP test to the storage server DNS address:

    • Note: This is just an additional test, other than the "ping" and "nslookup" command tests that were both detailed in Step 1 already, that you probably already have done by this point, but that would not be required to do by now, to see if for sure the connection to the storage server DNS address can be made from the client machine.

    • The reason that the error "Could not proceed due to internal error: switching to cache channel : pos: create bucket error - encountered network error when sending http request" in a Cloud Backup log (to our hosted Cloud Storage device) is seen is almost always that the Agent itself cannot connect to our Cloud Storage server's DNS address ("us1.storage.online-backup.com"). That normally is due to some sort of firewall or DNS issue on the client/Agent end.

      The following PowerShell TCP command should be able to connect, if it doesn't it means there is an issue on the network side (90% of the time it is DNS related we've found).

      Please run this connection test to our "us1.storage.online-backup.com" Storage Server DNS address, that the Cloud Backup device uses.

    • Go to Start Menu and type in PowerShell, and run it, and paste this command in (and make sure to modify the storage server DNS address portion of the statement to replace that text with your actual storage server's URL address that you found out about of had verified already during Step 1:

      test-netconnection -Port 443 -ComputerName us1.storage.online-backup.com -InformationLevel "Detailed"

      In addition run the ping command "ping us1.storage.online-backup.com" to see if it fails to ping or if it can resolve to a valid IP.

      If the test-netconnection command last output line of text shows "TcpTestSucceeded : True" then it passed. If the output shows "TcpTestSucceeded : False" then it did NOT pass. If the test did NOT pass, check to see what the "InterfaceAlias" line of text shows, that will state what network adapter was used, and if it is a VPN or other such adapter, disconnect the VPN & retry the tests. If the output shows "TcpTestSucceeded : False" then disable the SW & HW firewall and retry, and if it still fails then add these public DNS Servers to the main (LAN & WiFi) network adapter's DNS Server settings, by editing the adapter(s), and do a properties on the "TCP/IPv4" section, then click "Use the following DNS server addresses:" and specify these DNS Server IPs manually (Google & CloudFlare public DNS Server IPs):

      8.8.8.8, 4.4.4.4, 1.1.1.1

      Then save the changes and retry the same PowerShell TCP test & ping commands again. If both commands work it was due to the Firewall or the DNS Server settings, to resolve our DNS address. You can leave the DNS Servers manually config'd on that same network adapter, or you can on your internet router add at least 1 of the 3 above public DNS Server IPs in as a DNS Server address, and then change your main network adapter back to using automatic DNS Server settings, and run the same test again (possibly after a PC reboot, or after disabling that network adapter and re-enable it).

Step 2: Optional (this will only work for unmanaged 'Cloud Backup's device type devices) Verify if the "Check credentials" button function in that same 'Cloud Backup' device type device in question can pass the connection test now (which only works for unmanaged 'Cloud Backup' devices though, that were not created via the CMon UI)

In the Device tab in the client GUI, locate that same 'Cloud Backup' device type device in question, then do a "Properties" on it, or double-click it, or do a right-click "Properties" on it, and then if the device can be viewed (only unmanaged devices can do that, and get there that way via the client GUI, and the CMon doesn't currently have a way to run a "Check credentials" function) then click the "Check credentials" button function there, and if it passes the test it will show a green checkmark which means it was able to connect and is good!

Step 3: Run the Backup Again

After making a valid connection via "ping", "nslookup", and "PowerShell TCP test" works, you will try running your backup job again. It should be able to get past that error now.

If Simple Fixes Don't Work

  • Disable via the Windows "Control Panel > Network Adapters" dialog, all network adapters on the client machine other than the either primary LAN network adapter or the primary Wi-Fi adapter, that connects to the Internet. Then perform the "ping" command first, and the "nslookup" command second, and the "PowerShell TCP test" third. Then run the additional "nslookup" command which is: "nslookup google.com" without the quotes, to nslookup that extremely popular DNS addess, which in that case must be able to resolve properly to be able to get to Google's website, that really all DNS Servers should be able to resolve properly for that DNS addess to resolve to a valid IP address, and in the first two lines of that command output it should tell you which network adapter has the active Internet connection, and which DNS Server address was utilized there; that way you can know which NIC is the active one that will be the NIC that attempts to resolve other DNS addresses after that, which will help you to know which NIC to configure the various good and robust public DNS Server addresses on, to add the various (already stated) public DNS Server addresses on that same NIC next, and then try the 3 x stated "ping", "nslookup", and "PowerShell TCP test" commands again after that.
  • Disable any and all Firewall functions, on your HW & SW Firewalls. You may need to check with your network administrator beforehand, to inform them of this KB article (as often they can assist quicker or know something that can help you here).
  • Disconnect from any VPN client app connections, and/or uninstall your VPN client app. VPN client, and sometimes the VPN client can be bundled in with or built in to the Anti-Virus products so be aware of that (we know that "Norton 360 Premium" does enable a VPN by default).
  • Uninstall the Anti-Virus app, and reboot after that, if it isn't "Windows Defender" (as we haven't seen any issues with that latter app).

When to Contact Support

Contact support if:

  • Simple fixes don't work and you're still getting errors
  • You're uncomfortable deleting backup files manually
  • Multiple backup jobs are showing the same errors
  • Hardware issues are suspected (failing drives, network problems)

Information to Provide

When contacting support, include:

  • Your NovaBACKUP version
  • Type of backup device (local drive, NAS, etc.)
  • Available storage space
  • Complete error messages from the backup log