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