Kopia backs up to Backblaze B2 best through its s3 repository type pointed at B2’s S3 endpoint. It does everything the native b2 type does, adds Object Lock, and avoids the deprecation warning that kopia repository create b2 prints. For most people that means a private bucket, a key scoped to it, and a retention policy you have read.
Our lab had no paid B2 bucket, so only the rejected-key replies come from live Backblaze. The successful runs used the same commands against a SeaweedFS S3 endpoint with Object Lock, plus --disable-tls for its plain HTTP. We checked this in October 2026 on Ubuntu 26.04 with Kopia 0.23.1. Windows readers can follow our Kopia guide for Linux and Windows.
How does Kopia store backups in B2?
Kopia encrypts, compresses and packs everything on your machine, and B2 only ever receives opaque blobs under one prefix in one bucket. The layout below is the one this guide builds.
Because encryption happens before upload, Backblaze never holds the key. That is also why the repository password is the one thing you cannot lose: nobody, Backblaze included, can decrypt a Kopia repository without it.
Should you use the s3 or the b2 repository type?
Use kopia repository create s3 with B2’s S3 endpoint. The native provider still connects, but Kopia’s own help text now labels it deprecated, and Kopia’s ransomware protection docs state that for Backblaze, Object Lock only works through the S3 storage engine. Picking b2 today means migrating later and giving up locked blobs in the meantime.
The installed binary says the same thing, so you can check it on your own machine before deciding:
kopia repository create b2 --help 2>&1 | head -3The output opens with a blank line, and the usage summary under it carries the tag:
usage: kopia repository create b2 --bucket=BUCKET --key-id=KEY-ID --key=KEY [<flags>]
Create repository in a B2 bucket [DEPRECATED]Here is how the two compare on the points that change what you configure:
| Point | s3 provider + B2 endpoint | Native b2 provider |
|---|---|---|
| Status in current Kopia | Supported | Deprecated, warns on every create |
| Credentials | --access-key / AWS_ACCESS_KEY_ID = B2 keyID | --key-id / B2_KEY_ID |
| Endpoint flag | Required: s3.<region>.backblazeb2.com | Not used |
Object Lock (--retention-mode) | Yes | No |
| Point-in-time connect | Yes (--point-in-time) | No |
The rest of this guide uses the s3 provider. If you already run a native b2 repository, it keeps working for now; the native command is shown in the errors section so you can recognise its warning.
What do you need before you start?
You need a B2 account, a Linux machine to back up and about ten minutes. The bucket and key come first because Kopia refuses to create a repository it cannot write to. Check these before running anything:
- You can sign in to the Backblaze web console with B2 Cloud Storage enabled.
- The machine runs Ubuntu 26.04 or 24.04 (any Debian-family release works with the same apt repository).
- Outbound HTTPS on port 443 reaches
s3.<region>.backblazeb2.comfrom that machine. - You have somewhere safe to store a long repository password, such as a password manager.
If you only want local snapshots of the operating system itself, a cloud repository is the wrong tool; Timeshift handles system restore points on the same box, and Kopia to B2 then covers your files offsite.
How do you create the B2 bucket and application key?
Create a private bucket first, then a key restricted to that bucket. A bucket-scoped key matters because the key ends up in Kopia’s config file on every machine you back up, and a leaked account-wide key exposes every bucket you own. These steps follow the Backblaze application key documentation:
- In the web console, open B2 Cloud Storage > Buckets > Create a Bucket, name it (we use
kopia-devbox-backups) and keep it Private. Turn on Object Lock here if you plan to use the optional locking section. - Copy the Endpoint shown on the bucket card, for example
s3.us-west-004.backblazeb2.com. The region inside it depends on your account. - Open Application Keys > Add a New Application Key, choose the bucket under Allow Access to Bucket(s) and leave the access type at Read and Write.
- Save the keyID and applicationKey immediately. B2 shows the applicationKey only once.
Leave the bucket lifecycle setting alone for now. B2 defaults to keeping every version of every file, and the retention section below explains when to change that and when not to.
Install Kopia on Ubuntu
Kopia publishes its own apt repository, which tracks releases closely, so there is no reason to use a distro package or a manual binary. Add the signing key first:
sudo install -d -m 0755 /etc/apt/keyrings
curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpgRegister the stable channel and install the CLI:
echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update
sudo apt install -y kopiaConfirm the binary runs and reports its version.
kopia --versionThe release number and its build hash come back. Anything older than the release on the Kopia GitHub page means apt is still reading a stale package list.
0.23.1 build: 72ec08fd8edb86c67ed27099bf1b955e1f308ffa from: kopia/kopiaRun every Kopia command from here on as the user whose files you are backing up, not with sudo. Kopia stores its connection in that user’s home directory, and a repository connected as root is invisible to your normal account.
How do you create a Kopia repo on B2?
Export the bucket, endpoint and key once, then run one create command. Kopia reads the standard AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables for the s3 provider, and for B2 those take the keyID and applicationKey you saved. Keeping them in variables also keeps the secret out of your shell history:
export B2_BUCKET="kopia-devbox-backups"
export B2_ENDPOINT="s3.us-west-004.backblazeb2.com"
read -rp "B2 keyID: " AWS_ACCESS_KEY_ID; export AWS_ACCESS_KEY_ID
read -rsp "B2 applicationKey: " AWS_SECRET_ACCESS_KEY; echo; export AWS_SECRET_ACCESS_KEYSwap the endpoint for the one on your bucket card. The variables only live in this shell, so re-run the block if you reconnect before the repository is created. Now create the repository. The --prefix puts this machine’s data under its own folder, which lets several machines share one bucket without stepping on each other:
kopia repository create s3 \
--bucket="${B2_BUCKET}" \
--endpoint="${B2_ENDPOINT}" \
--prefix=devbox/ \
--description="devbox to B2"Kopia asks for a new repository password twice (our lab set KOPIA_PASSWORD, so the prompts are absent below). It then prints the format it chose and the default policy it applied:
Initializing repository with:
block hash: BLAKE2B-256-128
encryption: AES256-GCM-HMAC-SHA256
key derivation: scrypt-65536-8-1
splitter: DYNAMIC-4M-BUZHASH
Connected to repository.
Retention:
Annual snapshots: 3 (defined for this target)
Monthly snapshots: 24 (defined for this target)
Weekly snapshots: 4 (defined for this target)
Daily snapshots: 7 (defined for this target)
Hourly snapshots: 48 (defined for this target)
Latest snapshots: 10 (defined for this target)
Ignore identical snapshots: false (defined for this target)
Compression disabled.Two lines deserve attention. encryption: AES256-GCM-HMAC-SHA256 confirms the repository is encrypted with a key derived from your password through scrypt, so nothing extra is needed to turn encryption on. Compression disabled. is the default, and on text-heavy data it costs you storage you pay for every month, which the next section fixes. The endpoint takes a bare host name; adding https:// fails with an error covered at the end of this guide.
Check the connection Kopia saved.
kopia repository statusThe lines that matter are the config path, the identity snapshots are recorded under, and the format. The full output also prints a storage config block with your bucket, prefix and endpoint (secret masked) and several epoch lines, which we trimmed here:
Config file: /home/harrison/.config/kopia/repository.config
Description: devbox to B2
Hostname: devbox
Username: harrison
Read-only: false
Format blob cache: 15m0s
Storage type: s3
Storage capacity: unbounded
Hash: BLAKE2B-256-128
Encryption: AES256-GCM-HMAC-SHA256
Splitter: DYNAMIC-4M-BUZHASH
Format version: 3
Content compression: true
Password changes: trueHostname and Username become the snapshot source (harrison@devbox). If you rebuild this machine later under a different name, connect with --override-hostname so its old snapshots still belong to it.
How do you set retention for Kopia snapshots on B2?
Set the keep-* counts on the global policy, and decide them before the first snapshot because they also decide your B2 bill. Kopia keeps a snapshot if any rule claims it, so the counts overlap rather than add up. The defaults keep 48 hourly snapshots, which is pointless for a machine backed up once a night. We dropped hourly, kept two weeks of dailies and a year of monthlies, and turned on zstd compression in the same command:
kopia policy set --global \
--keep-latest 10 --keep-hourly 0 --keep-daily 14 \
--keep-weekly 8 --keep-monthly 12 --keep-annual 2 \
--compression zstdKopia echoes each change, then runs a first full maintenance pass on the empty repository.
Setting policy for (global)
- setting "number of annual backups to keep" to 2.
- setting "number of monthly backups to keep" to 12.
- setting "number of weekly backups to keep" to 8.
- setting "number of daily backups to keep" to 14.
- setting "number of hourly backups to keep" to 0.
- setting "number of latest backups to keep" to 10.
- setting compression algorithm to zstd
Running full maintenance...Ignore rules belong in the same policy, because every cache folder or build artifact you skip is storage you never pay for. These three patterns cover the usual offenders on a developer machine:
kopia policy set --global --add-ignore "*.tmp" --add-ignore node_modules --add-ignore .cacheRead the result back with kopia policy show --global. The retention and file rules should match what you set:
Retention:
Annual snapshots: 2 (defined for this target)
Monthly snapshots: 12 (defined for this target)
Weekly snapshots: 8 (defined for this target)
Daily snapshots: 14 (defined for this target)
Hourly snapshots: 0 (defined for this target)
Latest snapshots: 10 (defined for this target)
Ignore identical snapshots: false (defined for this target)
Files policy:
Ignore cache directories: true (defined for this target)
Ignore rules: (defined for this target)
*.tmp
.cache
node_modules
Read ignore rules from files: (defined for this target)
.kopiaignoreThe two policies keep this much side by side, per snapshot source:
| Rule | Kopia default | This guide |
|---|---|---|
| Latest | 10 | 10 |
| Hourly | 48 | 0 |
| Daily | 7 | 14 |
| Weekly | 4 | 8 |
| Monthly | 24 | 12 |
| Annual | 3 | 2 |
| Compression | off | zstd |
Kopia’s retention only removes snapshots from its own index. The blobs those snapshots used disappear later, over the next full maintenance cycles (every 24 hours by default), because garbage collection waits out safety margins before it deletes packs from the bucket. On B2 a delete through the S3 API leaves a hidden older version behind, and the bucket default is Keep all versions of the file, so without a lifecycle rule those versions are billed forever. Set the bucket’s lifecycle to Keep prior versions for this number of days (we would use 30) under Buckets > Lifecycle Settings. That gives you a month to recover from a bad delete and a bill that shrinks when retention expires snapshots. The Backblaze lifecycle rules page lists the exact behaviour of each option. Before the first snapshot, confirm the policy and the bucket agree:
kopia policy show --globallists 0 hourly and 14 daily snapshots.- The ignore rules show
*.tmp,.cacheandnode_modules. - The bucket’s Lifecycle Settings read Keep prior versions for this number of days, not Keep all versions.
If any line differs, fix it now. Every snapshot taken under the wrong policy stays billed until it expires.
Take the first snapshot
Pass every folder you want protected in one command. Each path becomes its own snapshot source with its own retention history:
kopia snapshot create ~/projects ~/DocumentsEach source reports its root object and snapshot ID. Keep the IDs handy, because restores take them as input.
Snapshotting harrison@devbox:/home/harrison/projects ...
Created snapshot with root k5e9ddd560d4759d61cdbf0f4a9ad06fa and ID 6a5a6f40b2fd817528d0172f4ba92294 in 1s
Snapshotting harrison@devbox:/home/harrison/Documents ...
Created snapshot with root k15d57e8c6019c31cd0cb34c330d06ec5 and ID 1fcbf957555e84f3dc19020155fe06e9 in 0sOur test set was 36.9 MB, 200 text files plus a 30 MB database file, and the first snapshot took 1.6 seconds of wall time against a local endpoint. Over the internet the first upload is bound by your uplink, not by Kopia. The second run is the one that tells you deduplication works: after editing one file we snapshotted ~/projects again and it finished in 0.29 seconds, because only the changed chunk and new metadata went up. Check these before you schedule anything:
- Each source printed a
Created snapshotline with its own ID. - A second run after a small edit finishes much faster than the first.
kopia snapshot list --allshows both sources.
A second run that takes as long as the first usually means an ignore rule or a cache folder is churning, so look there before the timer goes in.
Is the data in the B2 bucket really encrypted?
Yes, and you can prove it rather than trust it. We wrote a file containing a unique marker string, turned compression off for that folder so compression could not hide the text by accident, and snapshotted it. Then we listed the bucket and searched the raw data of the storage backend for the marker. A short boto3 script in our lab listed the bucket (first lines and totals shown, six more _log entries trimmed); kopia blob list or the B2 console file browser shows the same names on your bucket:
devbox/_log_20261024075006_5500_1792828206_1792828206_1_febe9a43f49be4c4bda479a39659aed4
devbox/kopia.blobcfg
devbox/kopia.maintenance
devbox/kopia.repository
objects: 28
by type: {'_': 7, 'kopia.blobcfg': 1, 'kopia.maintenance': 1, 'kopia.repository': 1, 'p': 4, 'q': 7, 'x': 7}Each prefix letter tells you what a blob holds, which helps when you browse the bucket in the B2 console and wonder what is using the space.
- Blobs starting with
phold packed, encrypted file contents and make up nearly all of your bill. - Blobs starting with
qhold packed directory listings and snapshot metadata. - Blobs starting with
xare the indexes Kopia reads to find content without listing every pack. - Blobs starting with
_logare Kopia’s own encrypted operation logs.
A recursive grep for the marker found it once in the source folder and zero times in the data directory of the object store. File names, folder names and contents are all inside encrypted packs, so a leaked key exposes ciphertext only. B2’s own server-side encryption is optional and adds nothing to this, since the data is already encrypted before it leaves your machine.
The weak spot is on the client. After connecting, Kopia keeps the repository password next to its config so scheduled runs never prompt:
ls -la ~/.config/kopia/Kopia on Linux does not use the desktop keyring unless you pass --use-keyring, so on servers and desktops alike the password lands in a 36-byte file readable only by you:
-rw------- 1 harrison harrison 796 Oct 24 07:50 repository.config
-rw------- 1 harrison harrison 36 Oct 24 07:50 repository.config.kopia-password
-rw------- 1 harrison harrison 133 Oct 24 07:50 repository.config.update-info.jsonAnyone with your account on this machine therefore has the key, and repository.config holds the B2 secret as well. That is acceptable for a personal box with full-disk encryption; on a shared server, run Kopia under a dedicated user. Either way, store the password somewhere off the machine, because losing this disk and the password together means the backup in B2 is unreadable.
How do you schedule nightly snapshots?
Use a systemd timer that runs kopia snapshot create --all. The --all flag re-snapshots every source this user has snapshotted before, so new folders join the schedule after their first manual snapshot with no unit edits. Our systemd timers guide covers the timer syntax in more depth. Create the service:
sudo vim /etc/systemd/system/kopia-backup.serviceSet User= to your own login so the job finds your Kopia config:
[Unit]
Description=Kopia snapshot of all sources to Backblaze B2
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
User=harrison
ExecStart=/usr/bin/kopia snapshot create --all
Nice=10
IOSchedulingClass=idleThen create the timer that triggers it every night.
sudo vim /etc/systemd/system/kopia-backup.timerPersistent=true runs a backup that was missed while the machine was powered off as soon as it boots again, which matters on a laptop that is shut down overnight:
[Unit]
Description=Run the Kopia B2 backup every night
[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true
[Install]
WantedBy=timers.targetEnable the timer, then trigger the service once by hand instead of waiting for tonight:
sudo systemctl daemon-reload
sudo systemctl enable --now kopia-backup.timer
sudo systemctl start kopia-backup.service
sudo journalctl -u kopia-backup.service --no-pager -n 12 -o catA healthy run lists every source and ends with Deactivated successfully:
Starting kopia-backup.service - Kopia snapshot of all sources to Backblaze B2...
Snapshotting harrison@devbox:/home/harrison/projects ...
Created snapshot with root k729b717a70944865ab5c14abc9fe7070 and ID d1f6863c3e8d7d26d5a4a784b9f5e8e8 in 0s
Snapshotting harrison@devbox:/home/harrison/Documents ...
Created snapshot with root k15d57e8c6019c31cd0cb34c330d06ec5 and ID dfe2a2b28986704aba30a441be653665 in 0s
Snapshotting harrison@devbox:/home/harrison/enc-test ...
Created snapshot with root k253277229f2bee97db9522151762b8ed and ID 969f01d04646882a285b370e72ef94ee in 0s
kopia-backup.service: Deactivated successfully.
Finished kopia-backup.service - Kopia snapshot of all sources to Backblaze B2.
kopia-backup.service: Consumed 348ms CPU time over 481ms wall clock time, 87M memory peak.The enc-test source in that log is the folder from our encryption check, so your list will only show your own folders. The service ran without a password prompt because it reads the saved password file. If it fails with an authentication error after you rotate the B2 key, reconnect once as the same user with the new key and the timer picks it up. systemctl list-timers kopia-backup.timer shows the next run time.
How do you restore files from B2?
List the snapshots, pick an ID, and restore either the whole tree or a single path inside it. Start with the list, because the tags in brackets tell you which retention rule is holding each snapshot:
kopia snapshot list --allThe newest snapshot of each source carries every tag, while older ones survive only on latest-N unless they are the newest in some daily, weekly or monthly bucket:
harrison@devbox:/home/harrison/Documents
2026-10-24 07:50:08 UTC k15d57e8c6019c31cd0cb34c330d06ec5 13 KB drwxrwxr-x files:2 dirs:1 (latest-1,daily-1,weekly-1,monthly-1,annual-1)
harrison@devbox:/home/harrison/projects
2026-10-24 07:50:07 UTC k5e9ddd560d4759d61cdbf0f4a9ad06fa 36.9 MB drwxrwxr-x files:201 dirs:4 (latest-2)
2026-10-24 07:50:09 UTC kcd5880d134414e3083b3b03d8f87d43f 36.9 MB drwxrwxr-x files:201 dirs:4 (latest-1,daily-1,weekly-1,monthly-1,annual-1)Restore a full snapshot into a new folder rather than over the original, so you can compare before you overwrite anything. The list above shows root object IDs (the k... values); we restored by snapshot ID instead, pulling the newest one for the source like this:
kopia snapshot list ~/projects --json | jq -r '.[-1].id'It returns the ID of the newest snapshot, which in our run was 85ff7162c1bdb549c4ed5025bc7330af, the second ~/projects snapshot. Install jq with apt if it is missing, then restore with that ID:
kopia snapshot restore 85ff7162c1bdb549c4ed5025bc7330af /tmp/restore-projectsAll 201 files came back. The count matches the snapshot list above, so nothing was skipped on the way down.
Restoring to local filesystem (/tmp/restore-projects) with parallelism=8...
Restored 201 files, 4 directories and 0 symbolic links (36.9 MB).A diff -r against the live folder showed one difference, Only in /home/harrison/projects/webapp/src: build.tmp. That is the ignore rule doing its job, not a lost file, and it is a good habit to diff a test restore so you know exactly what your policy leaves out.
For one file, append its path to the snapshot ID. This is the restore you will run most often:
kopia restore 1fcbf957555e84f3dc19020155fe06e9/invoice-2026-10.txt /tmp/invoice-2026-10.txtOnly the packs holding that file are fetched and decrypted, so a small restore costs very little B2 download traffic.
Restoring to local filesystem (/tmp/invoice-2026-10.txt) with parallelism=8...
Restored 1 files, 0 directories and 0 symbolic links (31 B).Both restores in one terminal, with the snapshot list above them:
Restores are also the only real test of a backup, so verify a sample of file contents now and then. kopia snapshot verify --verify-files-percent=10 downloads and checks a tenth of the files. On our repository it read 21 files across 214 objects with no errors. A test restore has passed when all three of these hold:
- The restored file count matches the
files:value inkopia snapshot list. - A
diff -ragainst the live folder shows only paths your ignore rules skip. - The
kopia snapshot verifyrun finishes with no errors.
Every percent you verify is B2 download traffic, so keep the sample small on large repositories. Run it after a key or policy change rather than on every nightly job.
Can Kopia lock B2 backups against ransomware?
Yes, with Object Lock, and this part is optional. It needs a bucket with Object Lock enabled and a new repository, because retention mode is chosen at create time. Locked blobs cannot be deleted by anyone, including you with your master key, until their retain-until date passes. That protects you from malware that steals the key from repository.config and tries to wipe the bucket, at the cost of paying for locked data until it expires. We created a second repository under its own prefix in compliance mode for 30 days. Give it its own --config-file, because create also connects, and without the flag it replaces your main connection in ~/.config/kopia/repository.config and the nightly timer would quietly start backing up to the empty locked repository:
kopia repository create s3 \
--bucket="${B2_BUCKET}" \
--endpoint="${B2_ENDPOINT}" \
--prefix=devbox-locked/ \
--retention-mode=COMPLIANCE \
--retention-period=30d \
--config-file="$HOME/.config/kopia/locked.config"Locks are applied once, at upload, so a blob that stays in use longer than 30 days would lose its protection. Kopia can push the date forward during full maintenance:
kopia --config-file="$HOME/.config/kopia/locked.config" maintenance set --extend-object-locks trueWith lock extension on, the full maintenance interval must stay at least one day shorter than the retention period, and Kopia checks it. When we tried a 30-day full interval on the 30-day repository, it refused with the error shown in the troubleshooting section. The default 24-hour interval is fine. Snapshots go to the locked repository only when you name its config file, so take one now:
kopia --config-file="$HOME/.config/kopia/locked.config" snapshot create ~/DocumentsTo schedule it, add the same command (with your full home path in place of $HOME and ~) as a second ExecStart= line in kopia-backup.service. A Type=oneshot service runs them in order but stops at the first one that fails. Prefix the original line as ExecStart=-/usr/bin/kopia snapshot create --all if a failed main run should not skip the locked one. The locked repository also starts with Kopia’s default policy (compression off, 48 hourly snapshots). Repeat the policy set --global command from the retention section with the same --config-file before locked data piles up for 30 days. We then used a small boto3 script to ask the storage API for the retention of one locked blob and to delete that exact version:
The blob reports mode: COMPLIANCE with a retain-until date 30 days out, and the versioned delete came back AccessDenied. On your own bucket, check the Kopia side of the setup with these:
- The locked repository was created with
--retention-mode=COMPLIANCEand--retention-period=30d. - The
maintenance set --extend-object-locks truecommand forlocked.configwas accepted. kopia repository statuswithout--config-filestill shows your original prefix.
If ransomware ever does hide your snapshots, disconnect and reconnect with --point-in-time=<timestamp before the attack>, which the s3 provider supports and the native b2 one does not. Pair Object Lock with the 30-day lifecycle rule from the retention section so hidden versions do not pile up; Backblaze documents that lifecycle deletion does not happen while a version is locked. A Read and Write key from the web console can still hide locked blobs, which point-in-time recovery undoes, and Kopia’s ransomware page shows how to create a key without delete rights through the B2 CLI if you want to close that gap too.
Kopia Backblaze B2 errors and their fixes
These came from our runs. Two are replies from the live Backblaze endpoints to a deliberately invalid key, and the deprecation warning and endpoint error are printed by Kopia itself before or without reaching B2:
Each one maps to a single cause.
“The key ‘004a…’ is not valid”
B2 rejected the keyID in AWS_ACCESS_KEY_ID. The usual causes are a typo, a deleted key, or pasting the applicationKey into the keyID slot. The full message reads can't connect to storage: error retrieving storage config from bucket "kopia-devbox-backups": The key '004a1b2c3d4e5f60000000001' is not valid. Run echo "${AWS_ACCESS_KEY_ID}" to confirm it matches the keyID on the Application Keys page, and create a new key if you no longer have its secret.
“Endpoint url cannot have fully qualified paths.”
The --endpoint value included a scheme, as in https://s3.us-west-004.backblazeb2.com. Kopia’s S3 client rejects it locally before any request leaves the machine. It wants the bare host name and adds HTTPS itself, so drop the https:// prefix.
“The B2 storage provider is deprecated” followed by “unauthorized:”
The first line is the warning every kopia repository create b2 prints now; the second is B2’s native API rejecting the key. Fix the key the same way as above, but better still, create the repository with the s3 provider and the same keyID and applicationKey.
“invalid repository password”
Connecting with the wrong password prints error connecting to repository: unable to create format manager: invalid repository password. The B2 key is fine in this case, since Kopia read the format blob and failed to decrypt it. Only the original password opens the repository; there is no reset.
“The repo RetentionPeriod must be 24h0m0s greater than the Full Maintenance interval”
You set --full-interval too close to the Object Lock period, so locks could expire between maintenance runs. Keep the full interval at least a day shorter on the locked repository, for example kopia --config-file="$HOME/.config/kopia/locked.config" maintenance set --full-interval 24h on a 30-day lock.
Setup checklist before you trust it
A backup you have not restored from is a hope, so walk through this list once after setup and again after any key or machine change:
kopia repository statusshowsStorage type: s3and your B2 endpoint.kopia policy show --globalshows the retention counts andzstdcompression you chose.- The bucket lifecycle setting keeps prior versions for a fixed number of days, not forever.
systemctl list-timers kopia-backup.timerlists a next run, and the last journal entry ends in success.- A single-file
kopia restoreinto/tmpreturns the content you expect. - The repository password is stored off this machine, where you can reach it if the disk dies.
If you are still choosing a tool, our Borg, Restic and Kopia comparison measures all three on the same dataset, and the Restic to S3 walkthrough shows the equivalent setup if you prefer Restic.
