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