What's New in Retrospect – Retrospect Backup 19 + Retrospect Virtual 2022 + Retrospect Cloud Storage

Troubleshooting Cloud Backups

Cloud Backup



title: "Troubleshooting Cloud Backups" created_at: 2017.10.10 updated_at: 2019.04.04 category: Cloud Backup --- :toc: macro :toc-title:

Retrospect for Windows and Retrospect for Mac both support cloud backups to more than a dozen different storage providers including Amazon S3, Google Cloud Storage, and Dropbox. Multiple simultaneous backups will saturate any connection. Retrospect is designed to handle intermittent connection issues.

If you do see bandwidth saturation issues or want to diagnose backup errors, there are a couple options for troubleshooting:


Bandwidth Test

Use Speedtest.net or Google’s "Internet speed test" for an evaluation of your current network speeds. Note that this is your maximum current network speed, so Retrospect and your cloud service may be less than this.

Cyberduck

Use Cyberduck or another free tool to verify that you can connect to your cloud account.

Logging

Turn "Engine" logging to 5 and "Foundation" logging to 6, and send the resulting operations log to Support. See Advanced Logging Options for more information.

Instrumentation

You can monitor Retrospect’s network usage to understand the bandwidth usage compared to the speed test.

Windows: Open Task Manager and click on the Performance tab for Retrospect.

Mac: Open Activity Monitor and select Networking or use a third party tool like iStatMenu.

Retrospect’s current architecture prevents simultaneous backup and cloud upload, so you will see the network usage drop after each RDB file is uploaded while the next one is filled with data. This delay should only be between 15 and 60 seconds, depending on the internal network and hardware involved. You can see those gaps in the screenshots above. With a 6 Mbps upload link, this drop in performance will lead to a 5% reduction in the maximum bandwidth usage.

Time Skew

Difficulties with accessing or setting up a cloud backup set could indicate an underlying time setting issue on a machine. If the time is off by even a minute compared to the NTP-specified time, the cloud provider might return an error. See examples below from operations_log.utx:

Unable to access backup-set-1: (RequestTimeTooSkewed)
Server Response: The difference between the request time and the current time is too large.
Unable to create bucket retrospect-backups: (RequestTimeTooSkewed)
The difference between the request time and the current time is too large.

The resolution is to update the time on the machine to ensure it matches. See https://time.is/. We have had customers where their machines were set to automatically update, but they needed to manually set the time.


Last Update: 04 April, 2019