Appendix ¶
Encryption and key management ¶
The user's password is used to derive two 192-bit keys (the
"L" and "R" keys) via
PBKDF2-SHA512
, with hard-coded parameters for
repeatable output.
-
The L-key is used to log in to the Authentication Role server in
place of the real password; the server stores only a
bcrypt(sha512)
hash of this L-key. - The R-key never leaves the client, and is used to encrypt secret keys stored within the user's profile on the server.
This means that one password can be used for all client-side account operations, while preventing servers from uncovering client-only secrets.
When Cloud Backup sets up a Storage Vault for the first time, it generates two high-entropy random keys (the 256-bit "A" and 128-bit "E" keys). All user data in the Storage Vault is stored encrypted with the A-key using AES-256 in CTR mode, and authenticated using Poly1305 in AEAD (encrypt-then-MAC) mode.
The permanent A-key is stored inside the Storage Vault, encrypted with the E-key. The E-key is then encrypted with the R-key and stored in the user's profile on the Authentication Role server. When a backup is performed, the client uses its password to derive the private R-key, to decrypt the E-key from the vault, to decrypt the A-key for data storage. This extra level of indirection enables some key rotation scenarios, as a new E-key can be generated without needing to re-encrypt all the data in the Storage Vault.
If the Storage Vault is for a Storage Role bucket, a high-entropy
random 128-bit PSK is used to gate access to the bucket. The
Storage Role server stores only a bcrypt(sha512)
hash
of this PSK. The client encrypts this PSK with the R-key and
stores it in the user's profile on the Authentication Role server.
Importing backup settings from other products ¶
Cloud Backup supports importing settings from certain other third-party backup products.
In all cases, only user configuration settings are read from the other product.
- Existing backed-up data is not converted to Cloud Backup's format; you must back up the data again using Cloud Backup.
- Historical logs are not imported.
Ahsay OBM/ACB 6.x or compatible ¶
Ahsay, OBM, and ACB are trademarks of Ahsay Systems Corporation Limited.
Cloud Backup can import settings from an installed version of Ahsay OBM/ACB 6.x, subject to the following notices and conditions:
-
Ahsay backupsets are imported as Cloud Backup Protected Items.
-
Backupset types
-
File
- Source selection/deselection is supported.
- Macro selections (desktop, documents etc) are not supported.
- Inclusion/exclusion filters are not supported.
- MySQL
-
Microsoft SQL Server
- The "All instances" option is not supported. Your Ahsay backupset must have selected specific instances for backup.
- Other backupset types are not supported.
-
File
-
Pre/post commands
- Pre/post commands are imported as applying to the Protected Item, not to the Storage Vault nor the Schedule.
-
Retention policies
-
Basic retention policies (
DAYS
/JOBS
-type) are supported. - Advanced retention policies will be treated as "keep forever".
-
Basic retention policies (
-
Schedule
- Daily, Weekly and Custom schedules are supported.
- Monthly schedules for a specific day of the month are supported.
- Monthly schedules for a variant day of the month (e.g. Second Tuesday, Last Weekday) are not supported.
-
"Extra Local Copy"
- "Local Copy" will be imported as a new or existing Local Path Storage Vault in Cloud Backup.
- The "Skip Offsite Backup" option is correctly imported.
-
Backupset types
CrashPlan ¶
CrashPlan and Code42 are trademarks of Code42 Software, Inc.
Cloud Backup can import settings from an installed version of Code42 CrashPlan, subject to the following notices and conditions:
-
CrashPlan backupsets are imported as Cloud Backup Protected
Items.
-
Backupset types
-
File
- Sources selection/deselection is supported.
- Regular expression exclusions are supported.
-
File
-
Retention policies
-
CrashPlan and Cloud Backup employ fundamentally
different retention systems. Cloud Backup makes a
best-effort attempt to translate the CrashPlan retention
policy into a set of Cloud Backup retention rules, with
some caveats:
- Cloud Backup uses a minimum retention period based on the schedule window.
- CrashPlan retention for the last week will be interpreted as multiple daily policies for periods shorter than 24 hours.
- CrashPlan retention for the last week will be interpreted as single or multiple weekly policies for periods greater than 24 hours, depending on the configured value.
- Retention for larger time periods will be configured as single or multiple daily, weekly or monthly rules dependent on the configured value, populated out for periods of a week, three months, a year, and indefinitely.
- Weekly retention policies are treated as one backup per week, on the first day of the week, for the specified number of weeks.
- Monthly retention policies are treated as one backup per month, on the first day of the month, for the specified number of months.
- Indefinite retention policies are implemented as one backup per month, on the first day of the month, for over a million years.
-
CrashPlan and Cloud Backup employ fundamentally
different retention systems. Cloud Backup makes a
best-effort attempt to translate the CrashPlan retention
policy into a set of Cloud Backup retention rules, with
some caveats:
-
Schedule
-
CrashPlan and Cloud Backup employ fundamentally
different scheduling systems. Cloud Backup translates a
CrashPlan schedule to multiple schedule rules, with some
caveats:
- CrashPlan allows a number of very small schedule windows, down to a minute. For the sake of performance, Cloud Backup enforces a minimum schedule window of 30 minutes for imported schedules.
- Cloud Backup will generate a schedule rule for each time that a CrashPlan backup would have run in its specified window(s).
- The "Skip if already running" option is automatically enabled for imported schedules, to prevent overlapping backup with small schedule windows.
-
CrashPlan and Cloud Backup employ fundamentally
different scheduling systems. Cloud Backup translates a
CrashPlan schedule to multiple schedule rules, with some
caveats:
-
Local destinations
- If any local destinations are configured for CrashPlan, Cloud Backup will automatically import these using the same location on disk, backing up to a subdirectory within the specified path.
- The folder containing Cloud Backup's local vault data will be labelled with a unique ID. If it is necessary to identify which folder belongs to Cloud Backup, we recommend checking the modify date for the folder. The Cloud Backup data folder can also be distinguished by the format of the unique ID - CrashPlan uses a numerical ID for its folder, while Cloud Backup uses a hyphenated GUID with a mixture of numbers and letters.
-
Backupset types
Other products ¶
Future versions of Cloud Backup will support importing configuration from other products.
Using Cloud Backup behind a network proxy ¶
Cloud Backup can be used behind an HTTP or SOCKS proxy.
Proxy settings are controlled by environment variables named
HTTP_PROXY
and HTTPS_PROXY
(case
insensitive).
Multiple programs use this configuration method, so the environment variable may already be present for other software on the machine.
On Windows, the environment variable should be set systemwide, to ensure that any settings also apply to background services. You can do this either
- with the
setx
command, or -
in the GUI from
SystemPropertiesAdvanced.exe
> "Environment Variables" button > "System variables" section
On Linux, environment variables can be set system-wide (e.g. in
/etc/environment
or
/etc/profile.d/my-custom-proxy.sh
), or for the
root
user running Cloud Backup (e.g. in
/root/.profile
), or in your startup script for Cloud
Backup (e.g. in /etc/rc.local
).
The HTTP_PROXY
environment variable should be set to
a string of the form
https://username:password@my.proxy.host.com/
or
http://my.proxy.host.com/
or
socks5://username:password@my.proxy.host.com/
. This
matches the normal format on Linux; however some Windows
applications write this variable without the protocol. Please
ensure that the protocol is present.
Your proxy software must support websockets in order for Cloud Backup's live-connection functionality to work correctly.
A future version of Cloud Backup will provide GUI settings to configure the network proxy.
Troubleshooting "tls: oversized record received" error ¶
The tls: oversized record received
error may occur
when making an HTTP proxy connection to an HTTPS proxy server (or
possibly vice-versa). Please double-check the environment variable
and the proxy server URL.
Suppressing Before / After command failures ¶
When a command-line program displays some output, the output is
either sent to stdout
("fd 1", for normal
messages) or stderr
("fd 2", for error
messages).
Cloud Backup will mark a Before/After command as a warning if
there was content on stderr
, or, if the command had a
non-zero exit code.
If you are certain that the command cannot fail, you can
-
redirect stderr messages to go to stdout instead, by adding
2>&1
to the end of your command -
override the command exit code, by adding to the end of your
command
- Windows:
&exit 0
- Linux and macOS:
; exit 0
- Windows:
The above information is not Cloud Backup-specific; more
information about 2>&1
and stdout redirection
can be found online, e.g.
https://support.microsoft.com/en-nz/help/110930/redirecting-error-messages-from-command-prompt-stderr-stdout
.