Backups.
Kopia is a new open source backup utility with basically all modern features.
Cross-platform, deduplication, encryption, compression, multithreaded speed,
native cloud storage support, repository replication, snapshots mounting,
GUI version, server version,...
Written in golang.
Embedded webGUI for server mode is done in React. KopiaUI comes packaged with electron.
- cli - Command line.
You call the kopia binary passing some commands, it executes stuff, done.
Deployment requires extra work - scripts with configs, scheduling. - Kopia Server - kopia binary runs in server mode.
Runs in the background, with its web server answering at url:localhost:51515
Web GUI makes the management easier than using cli. Additionally in server mode kopia can serve as a centralized repository for other machines that run kopia instances.
Deployment requires extra work similar to cli, but actual use is through web GUI. - KopiaUI - GUI version.
Kopia that comes packaged with electron to provide the feel of a standalone desktop app.
Good for simple deployment where average user just wants to backup stuff.
Benefits over cli or server is easier setup, management and multiple repo connecting at once.
Drawback is that it runs under one user and only when that user is logged in. - Kopia in Docker - Kopia Server running in docker
Can fulfill two needs:- Backup docker-host stuff to a cloud or a mounted network storage. Managed through webgui instead of cli.
- A centralized kopia repository where other machines on the network, that also use kopia, backup their data.
Official Getting Started Guide
Official Features
Advanced Topics
The above linked documentation is well written and worth a look if planning serious use.
- Kopia is a single ~35MB binary file.
- Backups are stored in a repository that needs to be created first, and is always encrypted.
- Before any action, Kopia needs to be connected to a repo as repos store most of the settings(policies), and commands are executed in their context. Multiple machines can be connected simultaneously.
- Snapshots, is the term used by Kopia for targets(paths) that are being backed up.
- Policy - settings for repo/backup behaviour, stuff like backups retention, what to ignore, logging, scheduling(server/UI), actions before and after backup,...
- Policies are stored inside a repo and can apply at various levels and
can inherit from each other
- Global policy, the default that comes predefined during repo creation, can be edited like any other.
- Per user@machine policy
- Snapshot level policy, only applying for that one path.
- Maintenance is automatic.
- Retention of backups - here's
how it works under the hood.
- Restore from backups is most easily done by mounting a snapshot.
Web GUI versions have button for it, cli version can dosudo kopia mount all /mnt/temp &
- Tasks section in gui gets wiped when Kopia closes, info on snapshots run history and duration then has to be find in logs
- Logs rotate with max age 30 days or max 1000 log files, 5000 content log files
Useful to search in cli-logs are the termskopia/server snapshotting
andkopia/server finished
- Compression is good and
should be set before backup starts. My go-to is
zstd-fastest
. If backups feel slows2-default
is less cpu heavy but with worse compression. Useful command:kopia content stats
- During snapshots Kopia uses local cache, location varies depending on the OS.
Default max size is 5GB, but it gets swept periodically every few minutes.
Useful commands arekopia cache info
andkopia cache clear
- ..
cli version of kopia will be used to periodically backup to a mounted network storage.
The backup script will be periodicly executed using systemd-timers.
For arch linux, kopia is on AUR yay kopia-bin
- repo creation
sudo kopia repo create filesystem --path /mnt/mirror/KOPIA/docker_host_kopia
sudo kopia repo connect filesystem --path /mnt/mirror/KOPIA/docker_host_kopia
sudo kopia repo status
If the path used during creation does not exists, kopia will create it in full.
After creation the repo is connected, so connnect command is just demonstration.
- the policy info and change
sudo kopia policy list
sudo kopia policy show --global
sudo kopia policy set --global --compression=zstd-fastest --keep-annual=0 --keep-monthly=12 --keep-weekly=8 --keep-daily=14 --keep-hourly=0 --keep-latest=3
- manual backup run
sudo kopia snapshot create /home/spravca/docker /etc
sudo kopia snapshot list
Since the connection exists with a repo, all that is needed is target that should be backed up.
- mounting backups
sudo kopia mount all /mnt/tmp &
- mounts all snapshots
sudo kopia snapshot list
sudo kopia mount k7e2b0a503edd7604ff61c68655cd5ad7 /mnt/tmp &
sudo umount /mnt/tmp
In linux, passing multiple paths separated by space seems to work fine.
So both /home
and /etc
are set to be backed up.
/opt/kopia-backup-home-etc.sh
#!/bin/bash
# initialize repository
# sudo kopia repo create filesystem --path /mnt/mirror/KOPIA/docker_host_kopia
# adjust global policy
# sudo kopia policy set --global --compression=zstd-fastest --keep-annual=0 --keep-monthly=12 --keep-weekly=8 --keep-daily=14 --keep-hourly=0 --keep-latest=3
REPOSITORY_PATH='/mnt/mirror/KOPIA/docker_host_kopia'
BACKUP_THIS='/home /etc'
KOPIA_PASSWORD='aaa'
kopia repository connect filesystem --path $REPOSITORY_PATH --password $KOPIA_PASSWORD
kopia snapshot create $BACKUP_THIS
kopia repository disconnect
make the script executable
sudo chmod +x /opt/kopia-backup-home-etc.sh
Usually cron is used, but systemd provides better logging and control,
so better get used to using it.
Heres
some discussion on unit files.
ntfy can be used for notifications,
more info here
sudo micro /etc/systemd/system/kopia-home-etc.service
kopia-home-etc.service
[Unit]
Description=kopia backup
Wants=network-online.target
After=network-online.target
ConditionACPower=true
# OnFailure=ntfy@failure-%p.service
# OnSuccess=ntfy@success-%p.service
[Service]
Type=oneshot
# Lower CPU and I/O priority.
Nice=19
CPUSchedulingPolicy=batch
IOSchedulingPriority=7
IPAccounting=true
PrivateTmp=true
Environment="HOME=/root"
ExecStart=/opt/kopia-backup-home-etc.sh
sudo micro /etc/systemd/system/kopia-home-etc.timer
kopia-home-etc.timer
[Unit]
Description=Run kopia backup
[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=10min
Persistent=true
[Install]
WantedBy=timers.target
sudo systemctl enable --now kopia-home-etc.timer
systemctl status kopia-home-etc.timer
journalctl -u kopia-home-etc.timer
- see history
- files are placed in
/etc/systemd/system
- the name of mount and automount files MUST correspond with the path
replacing/
with a-
, but otherwise it must be the mounting path in the name - for mounting that does not fail on boot if there are network issues,
and mounts the target only on request - enable
automount
file, notmount
file, so:
sudo systemctl enable mnt-mirror.automount
mnt-mirror.mount
[Unit]
Description=3TB truenas mirror mount
[Mount]
What=//10.0.19.11/Mirror
Where=/mnt/mirror
Type=cifs
Options=rw,username=kopia,password=aaa,file_mode=0644,dir_mode=0755,uid=1000,gid=1000
[Install]
WantedBy=multi-user.target
mnt-mirror.automount
[Unit]
Description=3TB truenas mirror mount
[Automount]
Where=/mnt/mirror
[Install]
WantedBy=multi-user.target
KopiaUI does not really need a guide. It's simple and just works for normal use.
But since we are here...
- Download latest release
- Extract it somewhere, lets say
C:\Kopia
- Run it, click through repo creation
- set global policy
- recommend setting compression,
zstd-fastest
- set schedule
- retention rules
- recommend setting compression,
- select what to backup
- Right click tray icon and set to "Launch at startup"
- done
It will now start on users login, and executes at set schedule.
While KopiaUI seems like the way to go because of the simple deployment and use, it has a drawback. The scheduled backups works only when user is logged in. Which for many deployments feel like it introduces unnecessary uncertainty, or is not even viable when servers often run with no user logged in.
Kopia always running in the background, but also webgui to manage it in.
- Download this repo,
delete everything except
kopia_backup/kopia_server_deploy_service_win
folder. - Run
DEPLOY.cmd
as admin, it will:- Removes powershell scripts restriction.
- Creates folder
C:\Kopia
and copies files there. - Uses shawl to create Kopia service.
- Places
kopia.url
on the current user's desktop.
- One should check content of
C:\Kopia\kopia_server_start.cmd
that's where credentials are set, default:admin // aaa
- Visit in browser
localhost:51515
- Setup new repo through webgui.
- set global policy
- recommend setting compression,
zstd-fastest
- set schedule
- retention rules
- recommend setting compression,
- Select what to backup.
Kopia should now run on boot and be easy to manage through web GUI.
Be it creating backup jobs, mounting old snapshots to restore files,
or just looking around if all works as it should.
All relevant files are in C:\Kopia
, from binaries, repository.config
, to logs.
Kopia server runs in insecure mode, so no https and no actual server for other machines on network to use, just local deployment.
Before shawl, task scheduler was used.
This matushorvath/Kopia as Windows Service
guide helped move beyond that. It contains more info if one would want to
actually run as server repository for other machines.
Also use of nssm is popular.
All relevant files are in C:\Kopia
, from binaries, repository.config
, to logs.
A scheduled task is imported that executes a powershell script
C:\Kopia\kopia_backup_scipt.ps1
at 21:19.
The script connects to a set repo and backup set targets.
This approach is bit more hands on than having a gui, but for daily use one
can easily get by with the commands: kopia snap list -all
and kopia mount all K:
Note that mount command should be executed in non admin terminal. Weird
windows thing.
Also at the moment cli is the only way I know how to make kopia actions work, so that VSS snapshots can be used.
- Download this repo,
delete everything except
kopia_cli_deploy_win
folder. - Run
DEPLOY.cmd
- Removes powershell scripts restriction.
- Creates folder
C:\Kopia
and kopies there
kopia.exe
,kopia_backup_scipt.ps1
and the VSS ps1 before and after files. - Adds
C:\Kopia
to the system env variable PATH. - imports a task schedule
- Read
kopia_backup_scipt.ps1
and follow the instructions there.
Which should be to just to create repo before running the script. - edit the scheduled task to the prefered time, default is daily at 21:19
- run scheduled task manually
- check if it worked
kopia snap list --all
The script is set to save logs in to C:\Kopia
.
Volume Shadow Copy Service freezes the state of the disk in time and makes
this snapshot available to use.
This is what allows backup of open files that are in use.
Here's some youtube video on VSS.
To make use of this feature edit kopia_backup_scipt.ps1
changing
$USE_SHADOW_COPY = $false
to $USE_SHADOW_COPY = $true
Note the use of --enable-actions
which is required for before/after actions
to work.
To test if its working, one can execute command vssadmin list shadows
to see current VSS snapshots and then execute it again during the backup.
Just something to have note of, if decided to switch to heavy scoop use.
- open terminal as admin
Set-ExecutionPolicy Bypass
iex "& {$(irm get.scoop.sh)} -RunAsAdmin"
scoop install sudo --global
sudo scoop install kopia --global
/mnt/
└── mirror/
/home/
└── ~/
└── docker/
└── kopia/
├── kopia_config/
├── kopia_cache/
├── kopia_logs/
├── some_data/
├── kopia_repository/
├── kopia_tmp/
├── .env
└── docker-compose.yml
/mnt/mirror/...
- a mounted network storage sharekopia_config/
- repository.config and ui-preferences.jsonkopia_cache/
- cachekopia_logs/
- logssome_data/
- some data to be backed upkopia_repository/
- repository locationkopia_tmp/
- temp used for snapshots.env
- a file containing environment variables for docker composedocker-compose.yml
- a docker compose file, telling docker how to run the containers
The data to be backed up are mounted in read only mode.
To be able to mount snapshots, extra privileges are required and fuse access.
services:
kopia:
image: kopia/kopia:latest
container_name: kopia
hostname: kopia
restart: unless-stopped
env_file: .env
privileged: true
cap_add:
- SYS_ADMIN
security_opt:
- apparmor:unconfined
devices:
- /dev/fuse:/dev/fuse:rwm
ports:
- "51515:51515"
command:
- server
- start
- --tls-generate-cert
- --disable-csrf-token-checks
- --address=0.0.0.0:51515
- --server-username=$USERNAME
- --server-password=$KOPIA_PASSWORD
volumes:
# Mount local folders needed by kopia
- ./kopia_config:/app/config
- ./kopia_cache:/app/cache
- ./kopia_logs:/app/logs
# Mount local folders to snapshot
- ./some_data:/data:ro
# Mount repository location
- /mnt/mirror/kopia_repository:/repository
# Mount path for browsing mounted snaphots
- ./kopia_tmp:/tmp:shared
networks:
default:
name: $DOCKER_MY_NETWORK
external: true
.env
DOCKER_MY_NETWORK=caddy_net
TZ=Europe/Bratislava
# KOPIA
USERNAME=admin
KOPIA_PASSWORD=aaa
All containers must be on the same network.
Which is named in the .env
file.
If one does not exist yet: docker network create caddy_net
Caddy is used, details
here.
To function as a repository server, Kopia must be setup with https,
which is achieved by using --tls-generate-cert
flag and removal
of --insecure
flag.
So now Kopia sits behind Caddy, but caddy needs to be told the traffic is https and to ignore that the certificate is not valid.
Caddyfile
kopia.{$MY_DOMAIN} {
reverse_proxy kopia:51515 {
transport http {
tls
tls_insecure_skip_verify
}
}
}
- visit kopia.example.com
- create new repository as
Local Directory or NAS
, set path to/repository
, set password
Now this container can do backups of mounted stuff in to other mounted places or cloud, while managed through webgui.
To also make it function as a repository server a user account needs to be added. The users are stored in the repo.
- exec in to the container
docker container exec -it kopia /bin/bash
- add user@machine and set the password
kopia server user add user1@machine1
- on another machine test with koppiaUI, on the first run:
- Pick
Kopia Repository Server
- Server address:
https://kopia.example.com:443
- Trusted server certificate fingerprint (SHA256)
can be left empty, or if you put something there, it gives you error where it tells you fingerprints of the server to pick from. - In advanced option one can override user@machine with the one set when exec-ed in to the docker container. Or exec again there and add another one.
- Pick
- check kopia docker container logs, I like using ctop to see container runtime logs, or the ones mounted in logs directory
- DNS issue, check
nslookup kopia.example.com
if on the machine is getting correct iP - Make sure you use port 443 in server address.
Backblaze B2 is still cheapest I believe. 10GB free.
- Register.
- Create a new bucket for kopia repository.
- note bucket name
- Add a new application key with the access enabled to the new bucket.
After filling the info the site one time showsapplicationKey
- note keyID
- note applicationKey
- in Kopia add new repository
Backblaze b2
fill in the required information: Bucket Name, KeyID and the Key. - Set global policy.
- Recommend setting compression,
zstd-fastest
. - Set schedule.
- Retention rules.
- Recommend setting compression,
- Pick what to backup.
- Done.
In few minutes one can have reliable cloud backup that compresses the data
and deduplicates.
Save the repo password set plus all the info used.
Might be worth to check bucket settings, Lifecycle. I think it should be set to
Keep only the last version of the file
For cli just follow the official documentation.
To restore files go in to Snapshots > Time > Start time > Mount as Local Filesystem.
The snapshot will be mounted as Y: