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. You can replace those by setting the metadataDirective to replace.

--contentType and --info should only be provided when --metadataDirective is set to replace and should not be provided when --metadataDirective is set to copy.

--contentType and --info are optional. If not set, they will be set based on the source file.

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.

Requires capability:

  • readFiles (if sourceFileId bucket is private)

  • writeFiles

b2 copy-file-by-id [-h] [--metadataDirective {copy,replace}]
                   [--contentType CONTENTTYPE] [--range RANGE] [--info INFO]
                   [--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

--metadataDirective

Possible choices: copy, replace

--contentType
--range
--info

Default: []

--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