The add command connects another storage to the current repository.
Like the init command, if the storage has not been initialized before, a storage configuration file derived from the command line options will be created.
If the add-ed storage has already been initialised before, then the command line options will be ignored and existing options are used.
Click here for a list of related forum topics.
Quick overview
SYNOPSIS:
duplicacy add - Add an additional storage to be used for the existing repository
USAGE:
duplicacy add [command options] <storage name> <snapshot id> <storage url>
OPTIONS:
-encrypt, -e encrypt the storage with a password
-chunk-size, -c <size> the average size of chunks (default is 4M)
-max-chunk-size, -max <size> the maximum size of chunks (default is chunk-size*4)
-min-chunk-size, -min <size> the minimum size of chunks (default is chunk-size/4)
-iterations <i> the number of iterations used in storage key derivation (default is 16384)
-copy <storage name> make the new storage compatible with an existing one to allow for copy operations
-bit-identical (when using -copy) make the new storage bit-identical to also allow rsync etc.
-repository <path> specify the path of the repository (instead of the current working directory)
-key <public key> the RSA public key to encrypt file chunks
Usage
duplicacy add [command options] <storage name> <snapshot id> <storage url>
Example
Add an encrypted webdav storage with the name webdav-storage, the path webdav://username@server//path/to/storage, the snapshot name my-documents-snap and copy all settings from the existing default storage.
duplicacy add -e -copy default -bit-identical webdav-storage my-documents-snap webdav://username@server//path/to/storage
Options
-chunk-size, -c <size>
The average size of a chunk.
Example
duplicacy add -c 4M # the average chunk size is 4MB
-max-chunk-size, -max <size>
The maximum size of a chunk.
Example
duplicacy add -max 16M # the maximum chunk size is 16MB
-min-chunk-size, -min <size>
The minimum size of a chunk.
Example
duplicacy add -min 1M # the minimumchunk size is 1MB
-iterations <i>
The -iterations option specifies how many iterations are used to generate the key that encrypts the config file from the storage password.
-copy <storage name>
The -copy option is required if later you want to copy snapshots between this storage and another storage.
Two different storage are copy-compatible if they have the same chunk size, the same maximum chunk size, the same minimum chunk size, the same chunk seed (used in calculating the rolling hash in the variable-size chunks algorithm), and the same hash key.
If the -copy option is specified, these parameters will be copied from the existing storage rather than from the command line.
-bit-identical
The -bit-identical option is used along with the -copy option and will copy the IDKey, ChunkKey and FileKey to the new storage from the old one. In this case the names of the chunks generated by Duplicacy during backup will be identical in the source and new storage.
This has the effect that you can rclone the chunks folder for example from local (source) to Google Drive (new storage), and then only do backups on Google Drive, and the existing chunks will be identical (same name, same size) as if the backup was run locally.
The -bit-identical option does not copy the encryption option. It is possible to have an encrypted source and an unencrypted new storage, or vice versa. The -e option determines whether or not the new storage will be encrypted.
This means of course, that the added storage can have a different password from the source.
Example
duplicacy add -copy default -bit-identical
-repository <path>
There’s a huge discussion about this option here: "repository" init and add options
-key <public key>
The -key option enables RSA encryption.
Notes
Each storage name must be unique in order to distinguish it from other storage.
Never -bit-idential from unencrypted to encrypted
Please note that when the -bit-identical option is used to make a new encrypted storage compatible with an unencrypted one, it is possible to replace the new config file with the standard config file (which contains keys with standard values) and the new storage will become unencrypted. Therefore, the -bit-identical option should never be used to copy the config file for a new encrypted storage from an unencrypted storage.
Only rclone if -bit-identical is used
Rclone is only feasible when -copy -bit-identical is used. Otherwise you will just create chunks which are not used in the backups! (storage space, time, and electricity will be wasted)
This happens because new chunks have different names in the 2 storage.
(Help needed: there should be a topic about this → please link it if you know which was)