Copy-file-by-id command

Copy a file version to the given bucket (server-side, not via download+upload). Copies the contents of the source B2 file to destination bucket and assigns the given name to the new B2 file, possibly setting options like server-side encryption and retention.

Warning

Setting file retention mode to ‘compliance’ is irreversible - such files can only be ever deleted after their retention period passes, regardless of keys (master or not) used. This is especially dangerous when setting bucket default retention, as it may lead to high storage costs.

By default, it copies the file info and content type, therefore --contentType and --info are optional. If one of them is set, the other has to be set as well.

To force the destination file to have empty fileInfo, use --noInfo.

By default, the whole file gets copied, but you can copy an (inclusive!) range of bytes from the source file to the new file using --range option.

Each --info entry is in the form a=b, you can specify many.

The maximum file size is 5GB or 10TB, depending on capability of installed b2sdk version.

To request SSE-B2 or SSE-C encryption for destination files, please set --destinationServerSideEncryption=SSE-B2/SSE-C. The default algorithm is set to AES256 which can be changed with --destinationServerSideEncryptionAlgorithm parameter. Using SSE-C requires providing B2_DESTINATION_SSE_C_KEY_B64 environment variable, containing the base64 encoded encryption key. If B2_DESTINATION_SSE_C_KEY_ID environment variable is provided, it’s value will be saved as sse_c_key_id in the uploaded file’s fileInfo.

To access SSE-C encrypted files, please set --sourceServerSideEncryption=SSE-C. The default algorithm is set to AES256 which can by changed with --sourceServerSideEncryptionAlgorithm parameter. Using SSE-C requires providing B2_SOURCE_SSE_C_KEY_B64 environment variable, containing the base64 encoded encryption key.

Setting file retention settings requires the writeFileRetentions capability, and only works in bucket with fileLockEnabled=true. Providing --fileRetentionMode requires providing --retainUntil which has to be a future timestamp, in the form of an integer representing milliseconds since epoch. Leaving out these options results in a file retained according to bucket defaults.

Setting legal holds requires the writeFileLegalHolds capability, and only works in bucket with fileLockEnabled=true.

If either the source or the destination uses SSE-C and --contentType and --info are not provided, then to perform the copy the source file’s metadata has to be fetched first - an additional request to B2 cloud has to be made. To achieve that, provide --fetchMetadata. Without that flag, the command will fail.

Requires capability:

  • readFiles (if sourceFileId bucket is private)

  • writeFiles

b2 copy-file-by-id [-h] [--fetchMetadata] [--contentType CONTENTTYPE]
                   [--range RANGE] [--info INFO | --noInfo]
                   [--destinationServerSideEncryption {SSE-B2,SSE-C}]
                   [--destinationServerSideEncryptionAlgorithm {AES256}]
                   [--sourceServerSideEncryption {SSE-C}]
                   [--sourceServerSideEncryptionAlgorithm {AES256}]
                   [--fileRetentionMode {compliance,governance}]
                   [--retainUntil TIMESTAMP] [--legalHold {on,off}]
                   sourceFileId destinationBucketName b2FileName

Positional Arguments

sourceFileId
destinationBucketName
b2FileName

Named Arguments

--fetchMetadata

Default: False

--contentType
--range
--info

Default: []

--noInfo

Default: False

--destinationServerSideEncryption

Possible choices: SSE-B2, SSE-C

--destinationServerSideEncryptionAlgorithm

Possible choices: AES256

Default: “AES256”

--sourceServerSideEncryption

Possible choices: SSE-C

--sourceServerSideEncryptionAlgorithm

Possible choices: AES256

Default: “AES256”

--fileRetentionMode

Possible choices: compliance, governance

--retainUntil
--legalHold

Possible choices: on, off