Coder Social home page Coder Social logo

kiwix / borg-backup Goto Github PK

View Code? Open in Web Editor NEW
13.0 6.0 2.0 153 KB

Backup easily your system with Bitwarden, BorgBase and Docker

License: GNU General Public License v3.0

Dockerfile 12.48% Shell 51.67% Python 35.85%
backup bitwarden borg borgbase docker borgmatic

borg-backup's Introduction

Kiwix's backup companion

CodeFactor Docker License: GPL v3

A Docker image to easily backup your services' data into BorgBase.

What's this?

This tool is a Docker image that you launch along your other Docker services, sharing the data volume with it (read-only).

Example:

# running your imaginary service
docker run -v /data/www:/var/www/html -d nginx
# running your backup companion
docker run -v /data/www:/storage:ro ghcr.io/kiwix/borg-backup backup --name nginx --every 1h

In this example, the content of /data/www on the host will be securely backed-up to BorgBase every hour.

How it works

There are three main components to this tool:

  • BorgBase is an affordable backup hosting service. We use it to store encrypted backups. You can use the free plan which is limited to two repositories or use a paid plan.
  • Bitwarden is a secured password management service. We only use features from the free plan.
  • Borg is an FOSS backup tool that creates and transmits encrypted backups.

In BorgBase, everything revolves around the concept of a repository. It's a place (~folder) in which your data goes (encrypted). For every datasource that you want to backup, you'll have one BorgBase repository and one companion container.

This tool generates an SSH keypair for your repo, configures BorgBase to allow backups using this key (with append-only restriction) and stores the keypair in your Bitwarden account so you don't have to worry much about credentials.

What do I need?

  • Mandatory: One BorgBase account (free or paid)
  • Mandatory: A Bitwarden accounts (a master)
  • Optional: A second Bitwarden account (a backuper one without the credential to create/read BorgBase repositories)

Accounts setup (to do once)

This is the annoying part. You'll have to manually create a couple of accounts and do some manipulations. This is a one-time thing, no matter how many repos you'll setup.

BorgBase

  1. Create an account at BorgBase (or reuse one)
  2. Once logged it, go to Acounts » API then New Token.
  3. Choose a name (kiwix-backup?) and make sure you select Create only (important!)
  4. Securely keep a reference to that created token, you'll need that every time you setup a new repository.

Bitwarden

In order to store what we need in Bitwarden (SSH keypairs, BorgBase token) but without exposing our Bitwarden token to the backup companion, we'll use two different accounts:

  • one that is used solely to setup repo. That's the master account.
  • one that is used when backing-up. This backuper one will have read-only access to the items in the vault.

Note: You can use only one account if you want. But using two accounts is safer. That said, it doesn't mean the read-only account should be considered public. Keep it safe!

  1. Create one master Bitwarden account (email/password)
  2. Create an Organization from that account's UI
  3. Create a single Collection to be shared accross this organization
  4. Invite a member to this organization, with:
  • the email adress you'll use to create that second Bitwarden account in a minute
  • choosing User mode
  • choising selected-collections only
  • check the collection you created earlier
  • check read-only (but not hide password)
  1. using the invitation link your received on that email address, create one backup Bitwarden account (email/password)
  2. login to Bitwarden UI using master account and confirm membership

We'll be using an API Key to connect to your read-only bitwarden account so from the bitwarden UI, goto Settings and View API Key. Note the value for client_id and client_secret. Those will be referred to later as BW_CLIENTID and BW_CLIENTSECRET.

Usage

Every repository or service you want to backup needs to be initialized once before you start backing-up your data. This is a quick step that is separated from the backup one in order to keep your master Bitwarden credentials from being moved around.

Setting up

This command is intended to be run from your local machine so you don't have to insert your credentials on any other system.

This tool is interactive and will ask for your Bitwarden master API ClientID, API Secret, password and your BorgBase token (both you should have created in Accounts setup).

docker run -it ghcr.io/kiwix/borg-backup setup-new-repo \
    --name <repo-name> \
    --bitwarden <bitwarden-master-email> \
    --alert-days <nb-days>
    --quota <max-storage>
    --region <region>

Choosing a repo-name

We suggest you use reverse-FQDN notation for your repo names as the Bitwarden matching is done using a search query meaning that if you have two repositories named my-service and my-service2, the first one will fail, receiving two results instead of one.

Optional values:

  • <nb-days>: periodicity of BorgBase e-mail alert in day(s) (default : 1)
  • <max-storage>: quota in MB (default: no quota)
  • <region>: BorgBase server region (eu or us) (default : eu)

That's it. You should now have a repoitory ready to receive backups.

Backing-up

The following is unattended and should be configured along your service. It runs forever, backing-up at the given interval.

docker run -v <some-folder>:/storage:ro \
    -e BW_CLIENTID=<bitwarden-readonly-apikey-clientid> \
    -e BW_CLIENTSECRET=<bitwarden-readonly-apikey-secret> \
    -e BW_PASSWORD=<bitwarden-readonly-password> \
    ghcr.io/kiwix/borg-backup backup --name <repo-name> --every <period>
  • <repo-name> is the repository name configured in the setup step.
  • <period> is the interval to launch backup on: units are m for minutes (1-30), h for hours (1-30), d for days (1-14), M for months (1-6).

Other parameters can be configured via Docker environment variables:

  • Retention options:
    • KEEP_WITHIN: keep all archives less than this old (no used by default)
    • KEEP_DAILY: keep last archive of this many latest days (default: 7)
    • KEEP_WEEKLY: keep last archive of this many latest weeks (default: 5)
    • KEEP_MONTHLY: keep last archive of this many latest months (default: 12)
    • KEEP_YEARLY: keep last archive of this many latest years (default: 1)
  • Databases backup:
    • DATABASES: DSNs of the database to backup.

Database DSN should be in the form: type://user:password@host:port/dbname. It only supports mysql, postgresql and mongodb. dbname can be all to backup all databases of that host/connexion.

Note: Bitwarden will send you a New Device Logged In From Linux email every time you launch that container.

Single back-up

If you want to rely on your own scheduling tool, you can use the single-backup command which just runs the backup once and exits.

Note that contrary to the regular backup command, there is no interactive request for missing credentials. As for invalid credentials, this will simply fail the container.

docker run -v <some-folder>:/storage:ro \
    -e BW_CLIENTID=<bitwarden-readonly-apikey-clientid> \
    -e BW_CLIENTSECRET=<bitwarden-readonly-apikey-secret> \
    -e BW_PASSWORD=<bitwarden-readonly-password> \
    ghcr.io/kiwix/borg-backup single-backup --name <repo-name>

Custom command back-up (cli-mode)

If you need to execute a command to prepare your backup data you can enable cli-mode.

By setting the CLI_MODE variable, you are instructing the tool to run your passed command and, should it succeed, start a single-backup.

  • It requires passing all backup-related conf via environment variables.
  • It can be combined with regular data (/storage or databases).
  • It is restricted to single-backup. Container exits after your command and single-backup finishes.
docker run \
    -e BW_CLIENTID=<bitwarden-readonly-apikey-clientid> \
    -e BW_CLIENTSECRET=<bitwarden-readonly-apikey-secret> \
    -e BW_PASSWORD=<bitwarden-readonly-password> \
    -e BORGBASE_NAME=<repo-name> \
    -e CLI_MODE=y \
    -v $HOME/.kube/config:/root/.kube/config:ro \
    ghcr.io/kiwix/borg-backup kube-dump all > /storage/

Note: kube-dump is installed in the image.

Restoring data

Using the extract tool

Your backups are composed of archives or versions of your data. Use this tool to list and extract them with ease.

docker run \
    -v /data/temp:/restore:rw \
    -e BW_CLIENTID=<bitwarden-readonly-apikey-clientid> \
    -e BW_CLIENTSECRET=<bitwarden-readonly-apikey-secret> \
    -e BW_PASSWORD=<bitwarden-readonly-password> \
    ghcr.io/kiwix/borg-backup restore --name <repo-name> --list

This will list all the available archives. Note the name of the one you'll want to extract.

docker run \
    -v /data/temp:/restore:rw \
    -e BW_CLIENTID=<bitwarden-readonly-apikey-clientid> \
    -e BW_CLIENTSECRET=<bitwarden-readonly-apikey-secret> \
    -e BW_PASSWORD=<bitwarden-readonly-password> \
    ghcr.io/kiwix/borg-backup restore --name <repo-name> --extract "<archive-name>"

This will extract the content of the archive into /restore (which you should have mounted accordingly on the host).

--extract accepts a special value of latest that gets the lasted archive from the list.

Manually

As your backup as just regular borg backups, you can follow these docs to restore your data manually.

Restoring requires your SSH keypair stored in bitwarden. In your Bitwarden vault, you'll find one item for each of your repository. In this item, you'll find:

  • username: that's your SSH public key. Save it as ~/.ssh/<myrepo>.pub
  • password: that's your SSH private key. Save it as ~/.ssh/<myrepo>
  • BORGBASE_TOKEN: that's your borgbase token. You don't need it for restoring.

You can now list, retrieve and extract any borg archive using regular tools.

FAQ

Can I specify multiple folders to backup?

Yes, just mount them as subfolders inside /storage:

docker run \
    -v /data/media/images:/storage/images:ro \
    -v /data/attachments:/storage/attachments:ro \
    ghcr.io/kiwix/borg-backup backup --name myservice --every 1h

Can I backup both a database and files at the same time?

Yes, if you specify DATABASES env, it's added on top of the mounted volume.

⚠️ There is an important constraint when backing up both databases and files: your /storage mounted volume must be a single volume. You can not mount any other folder under /storage and expect its files to be included. Those will silently be ignored.

If you would like to mount several volumes inside /storage and also backup databases, there is a trick: you can do it by setting the CROSS_FS_GLOB envrionment variable. Note that there are two catches:

Can I backup several databases at the same time?

Yes, beside the all trick mentionned above, if you need to backup a list of databases or databases on different hosts or of different kinds, just concatenate the DSNs into the DATABASES env, separating them with |||.

-e DATABASES="mysql://root:root@db:3306/all|||mysql://user:pass@prod:3306/clients"

Can I replace BorgBase with another host?

No, at the moment, we use their API so it can't be replaced with another service.

What if my Bitwarden is compromised?

Don't panic! If your read-only Bitwarden credentials are compromised, you won't loose any data:

  • Bitwarden items can't be modified by this account
  • The SSH keypairs stored in Bitwarden are now compromised but it can only do much on BorgBase:
    • append new data to your repos (but cannot delete those you backed-up)
    • read backuped data (check and delete those if that happened)

You should now manually remove the keypairs from BorgBase and remove post-incident archives from your repo (read this documentation on append-only first).

Can I use a single Bitwarden account?

Yes, but we highly discourage it.

The sole account is thus the read-write one (master) and it means it it gets compromised, one could delete items from your Bitwarden account. As your SSH keypairs are only stored in Bitwarden, loosing them mean you won't be able to retrieve nor decrypt your backups.

borg-backup's People

Contributors

florentk avatar kelson42 avatar rgaudin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

Forkers

msgpo heartshare

borg-backup's Issues

Handle repo quota error

When the number of allowed repo on borgbase is exhausted, the setup-new-repo tool fails with:

Cannot connect to BorgBase : 'NoneType' object is not subscriptable

This is because the API request forbids the creation of the repo with the following response

{'data': {'repoAdd': None},
 'errors': [{'locations': [{'column': 5, 'line': 12}],
             'message': 'Over quota or too many repos.',
             'path': ['repoAdd']}]}

This type of error is to be expected and should be handled properly and reported clearly.

Setup is unclear

README says it's using bitwarden and borgbase but there's no explanation about how it uses them nor how to setup.

docker run -d -v <barckupdir>:/storage \
       -e BW_EMAIL=<your_bitwarden_login_mail> \
       -e BW_PASSWORD=<your_bitwarden_master_password> \
       -e BORGBASE_NAME=test_borg \
       -e BORGBASE_KEY=<borgbase_api_token> \
       -ti backup-docker

BW email and password are easy to understand but what about BORGBASE_NAME. Is it a borgbase repository name? Should it already exist or will it be created?
The BORGBASE_KEY is a borgbase token but which kind should be created? Read-only, Create-only, Full Access ?

Document repo name restrictions

We store SSH keypairs (and borgabse API token) into bitwarden on individual items named after the borgbase repo name.

So if the repo is named mysql, we create a mysql item in the vault/collection.

When retrieving this item on future runs, we use the --search feature of bitwarden cli's list command (there is no exact name matching).

This means that for this mysql repo, we'll search for mysql. If there are multiple items matching mysql (say mysql and mysql2), then the process stops because it can't find a single result.

It's important we communicate that limitation on the documentation so users use non-clashing repo names.

You are not logged in error during backup process

Hey Team, I'm having authentication errors when trying to run backups. The Setting up stage seems to work. It has created a Borgbase repo and the read only Bitwarden user has access to the ssh-ed25519 key etc. However, when I try and run the backup it attempts to log in multiple times before failing. I have double checked the password, removed any special characters, and tried with and without double quotes (it's 64 characters long, is there a possible issue using a long password?).

$ docker run -v /dir/to/backup:/storage:ro \
>     -e BITWARDEN_EMAIL="[email protected]" \
>     -e BITWARDEN_PASSWORD="readonly-password" \
>     kiwix/borg-backup backup --name backup_name --every 1h
Start initialization ...
Could not find dir, "/root/.config/Bitwarden CLI"; creating it instead.
Could not find data file, "/root/.config/Bitwarden CLI/data.json"; creating it instead.
You are not logged in.? client_id: Please try again ...
You are not logged in.? client_id: Please try again ...
You are not logged in.? client_id: Please try again ...
You are not logged in.? client_id: Please try again ...
You are not logged in.? client_id: Please try again ...
Unable to log in your Bitwarden account. Please check your credentials.

Any ideas what I'm doing wrong? Did I miss read something? Cheers Team!

Doesn't stop on borgmatic error

Tested database backup with incorrect configuration (hostname for instance). Borgmatic thus failed to run and properly reported that in its log file (/dev/shm/borgmatic.log) but there's zero feedback to container user…

ERROR 2005 (HY000): Unknown MySQL server host 'db2' (-2)
[email protected]:repo: Error running actions for repository
Command '('mysql', '--host', 'db2', '--port', '3306', '--protocol', 'tcp', '--user', 'root', '--skip-column-names', '--batch', '--execute', 'show schemas')' returned non-zero exit status 1.
/root/.config/borgmatic/config.yaml: Error running configuration file

summary:
/root/.config/borgmatic/config.yaml: Error running configuration file
[email protected]:repo: Error running actions for repository
Command '('mysql', '--host', 'db2', '--port', '3306', '--protocol', 'tcp', '--user', 'root', '--skip-column-names', '--batch', '--execute', 'show schemas')' returned non-zero exit status 1.

Don't require master bitwarden password

Current implementation requires the master credentials of the bitwarden account for every backup.

We need to separate the sub-account/token creation process so that the backup is launched using limited credentials

setup-new-repo should ask for borgbase key interactively

In the same way we request bitwarden credentials to be passed on cli, we should ask for borgbase token as well.

CLI should be clear enough and indicate that it wants Bitwarden credentials first (echo before calling bw login), then ask for borgbase token

Known hosts config not set properly

Testing PR #30, I had to manually accept the fingerprint of the host during the first connection.

I believe we might have introduced a regression when refactoring the commands as this used to work fine

[email protected]:repo: Initializing repository
The authenticity of host 'box-eu8.borgbase.com (95.217.115.47)' can't be established.
ECDSA key fingerprint is SHA256:McOX8rDSCr2eHvhBi2Z1ogxsaF01WagS0U3r4vG1Oh0.
Are you sure you want to continue connecting (yes/no)? yes

Improve stdout feedback

Last stdout feedback for all runs is Init Borgmatic ... We should probably have at least another log indicating that this initialization succeeded (or failed) and that cron takes over.

Follow documentation

This wiki page is a documentation of the tool as we want it for the initial release.

We want the tool to behave as described and that means tweaking a few things:

  • backup on a separate command #18
  • specify repo-name and periodicity as params #19
  • setup-new-repo should ask for borgbase key interactively #20
  • harmonize param names #21
  • use DSN to backup database instead of multiple fields #22
  • allow backing-up multiple databases #23
  • allow backing-up multiple folders (was documentation)
  • add a tool to restore/extract a backup #24
  • configure borgmatic periodicity #25
  • make sure borgmatic commands don't overlap #26
  • configure borgbase alertdays based on periodicity #27

Periodic failures

On our large download backup, the backup stops working every 2 months and requires to be restarted. Borg base alerts informs us.

Logs mentions a connection issue but given the number of layers there are, logs are frequently useless.

Configuration:

BORGBASE_NAME=download
BITWARDEN_PASSWORD=*******
BITWARDEN_EMAIL=******
BACKUP_HOUR=2
BACKUP_MINUTE=0
KEEP_WITHIN=0H
KEEP_DAILY=7
KEEP_WEEKLY=5
KEEP_MONTHLY=12
KEEP_YEARLY=1
QUOTA=0
REGION=eu
ALERT=1
PERIODICITY=1d
BACKUP_DAY=1
DATABASES=
MAX_BORGMATIC_RETRY=10
WAIT_BEFORE_BORGMATIC_RETRY=5

Here's the tail of the log

M /storage/openzim/release/libzim/feed.xml
M /storage/openzim/release/feed.xml
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
[email protected]:repo: Running consistency checks
Remote: Starting repository check
Remote: packet_write_wait: Connection to 65.21.33.81 port 22: Broken pipe
Connection closed by remote host
[email protected]:repo: Error running actions for repository
Command 'borg check --prefix {hostname}- --info [email protected]:repo' returned non-zero exit status 2.
/root/.config/borgmatic/config.yaml: Error running configuration file

summary:
/root/.config/borgmatic/config.yaml: Error running configuration file
[email protected]:repo: Error running actions for repository
Remote: Starting repository check
Remote: packet_write_wait: Connection to 65.21.33.81 port 22: Broken pipe
Connection closed by remote host
Command 'borg check --prefix {hostname}- --info [email protected]:repo' returned non-zero exit status 2.

Need some help? https://torsion.org/borgmatic/#issues
[email protected]:repo: Pruning archives
Keeping archive: download__backup__2021-07-20T02:00:40 Tue, 2021-07-20 02:00:42 [05e109f47cdabf316764a0b364a3adead675200a8ee482119b85dc63d16e38d9]
Keeping archive: download__backup__2021-07-19T02:00:13 Mon, 2021-07-19 02:00:15 [1949cc1def2dff8d7a82544a3bfb53a1774e1f0f3581174c4805add9e5ee3360]
Keeping archive: download__backup__2021-07-18T02:00:33 Sun, 2021-07-18 02:00:35 [b55f59819bf147a0c6b09a11de9e0e20483754eed30e73072f3564b5e17be8b8]
Keeping archive: download__backup__2021-07-17T02:00:16 Sat, 2021-07-17 02:00:18 [022630cb7db2a35a71afde80d23e62a842db7654d6d353e388c3d384457e220c]
Keeping archive: download__backup__2021-07-16T02:00:17 Fri, 2021-07-16 02:00:19 [9f8675681dd627010dbe72e1d8a822c3a6a7daa299b5893518838a716e6bb901]
Keeping archive: download__backup__2021-07-15T02:00:30 Thu, 2021-07-15 02:00:32 [cf314a498013c72c14166cc10b0e8e19dec5a45f455c2e02f62147b6e21065c6]
Keeping archive: download__backup__2021-07-14T02:00:38 Wed, 2021-07-14 02:00:40 [2eb19a6f256abf34f838b62d0221b78029d2339e055b5381c630cf8d1c1d6019]
Pruning archive: download__backup__2021-07-13T02:00:29 Tue, 2021-07-13 02:00:32 [25418a95bc2fb698119d2fd5084c877d778244a30da703fad7ece94c3b4b0585] (1/1)
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
Keeping archive: download__backup__2021-07-11T02:00:10 Sun, 2021-07-11 02:00:11 [e07405e3f376e2e36097a37573897ad99afd192c0c623bacddc446cc9956f3b0]
Keeping archive: download__backup__2021-07-04T02:00:14 Sun, 2021-07-04 02:00:16 [12dcaaf12fc33eb79fecc3dec2d925eb41e614bea69e4a5e4d087ad42cf04bd4]
Keeping archive: download__backup__2021-06-30T02:00:31 Wed, 2021-06-30 02:00:33 [513c6714e5d7834e989fae4dbca9844b873d04c6f920298394dfdeebb2cf47d8]
Keeping archive: download__backup__2021-06-27T02:00:28 Sun, 2021-06-27 02:00:29 [718e41af436a75f3050fdbdcf5e889520933a1142b7c1149bee6fdfcd1481d5d]
Keeping archive: download__backup__2021-06-20T02:00:15 Sun, 2021-06-20 02:00:16 [47d59aa9cfc9f539214d7e674dc9c658af30f2bae9c1ba2184566fb2e438da06]
Keeping archive: download__backup__2021-06-13T02:00:17 Sun, 2021-06-13 02:00:18 [de186b99a4f1cc4908315d97b081fcbb8027e65b4a27bb890081ff854693693f]
Keeping archive: download__backup__2021-05-31T02:00:19 Mon, 2021-05-31 02:00:20 [8ccbccd160fc7aec5bb98c6ec1bfd3be46b7a434bc828eb9981715a4f62713b9]
Keeping archive: download__backup__2021-04-30T02:00:31 Fri, 2021-04-30 02:00:35 [6269745493856f09aec0503d9998573f015379db6ca6d5bfd8d17cb657590f4b]
Keeping archive: download__backup__2021-03-31T02:00:14 Wed, 2021-03-31 02:00:15 [f7d129c53127055953b848cafc84dfcb7bbf57aaf8ec6ae512844af19e017944]
Keeping archive: download__backup__2021-02-28T02:00:40 Sun, 2021-02-28 02:00:48 [516ad18252ddbffa126adce29de587e79d481ac8f88000d76763bd050c10615d]
Keeping archive: download__backup__2021-01-31T02:00:21 Sun, 2021-01-31 02:00:23 [d792c3fcb404d68fcd9beed1894e515f9212a0d70b1c29d50b3e5d4a019cca17]
Keeping archive: download__backup__2020-12-31T02:03:27 Thu, 2020-12-31 02:04:08 [709e198f3a9f53baed68fb3dcd82f85a6de520f24923ddfd63ed1a5be6d95029]
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
[email protected]:repo: Creating archive
Creating archive at "[email protected]:repo::download__backup__{now}"
M /storage/kiwix/archive/.htaccess
M /storage/kiwix/other/.htaccess
M /storage/kiwix/dev/.htaccess
M /storage/kiwix/release/.htaccess
M /storage/kiwix/release/kiwix-android/2.5.0/feed.xml
M /storage/kiwix/release/kiwix-android/2.5.1/feed.xml
M /storage/kiwix/release/kiwix-android/2.5.2/feed.xml
M /storage/kiwix/release/kiwix-android/2.5.3/feed.xml
M /storage/kiwix/release/kiwix-android/2.3/feed.xml
M /storage/kiwix/release/kiwix-android/feed.xml
M /storage/kiwix/release/browsers/chrome/feed.xml
A /storage/kiwix/release/browsers/firefox/feed.xml
M /storage/kiwix/release/browsers/feed.xml
M /storage/kiwix/release/browsers/edge/feed.xml
M /storage/kiwix/release/kiwix-js-windows/feed.xml
M /storage/kiwix/release/feed.xml
M /storage/kiwix/release/kiwix-desktop-macos/feed.xml
M /storage/kiwix/release/kiwix-desktop/feed.xml
M /storage/kiwix/release/kiwix-hotspot/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v1.0.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.4/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.6/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.7/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.5/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/master/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.1/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.2/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.8/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.1.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.1.1/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.3/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.1/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.0.2/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.7/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.8/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.2.0/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.2.1/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.2/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.1/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.3/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.5/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.6/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.3/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.4/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.5/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.4.6/feed.xml
M /storage/kiwix/release/kiwix-hotspot/v2.3.4/feed.xml
M /storage/kiwix/release/libkiwix/feed.xml
M /storage/kiwix/release/kiwix-tools/feed.xml
M /storage/openzim/release/zimwriterfs/feed.xml
M /storage/openzim/release/zim-tools/feed.xml
M /storage/openzim/release/libzim/feed.xml
M /storage/openzim/release/feed.xml
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
Remote: Storage quota: 879.21 GB out of 3.96 TB used.
[email protected]:repo: Running consistency checks
Remote: Starting repository check
Remote: packet_write_wait: Connection to 65.21.33.81 port 22: Broken pipe
Connection closed by remote host
[email protected]:repo: Error running actions for repository
Command 'borg check --prefix {hostname}- --info [email protected]:repo' returned non-zero exit status 2.
/root/.config/borgmatic/config.yaml: Error running configuration file

summary:
/root/.config/borgmatic/config.yaml: Error running configuration file
[email protected]:repo: Error running actions for repository
Remote: Starting repository check
Remote: packet_write_wait: Connection to 65.21.33.81 port 22: Broken pipe
Connection closed by remote host
Command 'borg check --prefix {hostname}- --info [email protected]:repo' returned non-zero exit status 2.

Need some help? https://torsion.org/borgmatic/#issues
[email protected]:repo: Pruning archives
Remote: write: Connection reset by peer
Connection closed by remote host. Is borg working on the server?
[email protected]:repo: Error running actions for repository
Command 'borg prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 1 --prefix download__backup__ --info --list [email protected]:repo' returned non-zero exit status 2.
/root/.config/borgmatic/config.yaml: Error running configuration file

summary:
/root/.config/borgmatic/config.yaml: Error running configuration file
[email protected]:repo: Error running actions for repository
Remote: write: Connection reset by peer
Connection closed by remote host. Is borg working on the server?
Command 'borg prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 1 --prefix download__backup__ --info --list [email protected]:repo' returned non-zero exit status 2.

Need some help? https://torsion.org/borgmatic/#issues
[email protected]:repo: Pruning archives
Remote: ssh_exchange_identification: read: Connection reset by peer
Connection closed by remote host. Is borg working on the server?
[email protected]:repo: Error running actions for repository
Command 'borg prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 1 --prefix download__backup__ --info --list [email protected]:repo' returned non-zero exit status 2.
/root/.config/borgmatic/config.yaml: Error running configuration file

summary:
/root/.config/borgmatic/config.yaml: Error running configuration file
[email protected]:repo: Error running actions for repository
Remote: ssh_exchange_identification: read: Connection reset by peer
Connection closed by remote host. Is borg working on the server?
Command 'borg prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 1 --prefix download__backup__ --info --list [email protected]:repo' returned non-zero exit status 2.

Need some help? https://torsion.org/borgmatic/#issues

allow backing-up multiple databases

We should support backing-up multiple databases as this is supported in borgmatic. For that we'll have multiple DSNs in the database env with a separator and we'll loop over it to generate the borgmatic conf.

I propose ||| as the separator as this needs to not be in any value of the DSN

backup on a separate command

As we have a setup-new-repo command for the setup step, we should backup on a dedicated command (backup). That would:

  • Be more clear
  • Allow a simple Usage help on launch without the command
  • Cleaner as it removes need for a smart entrypoint doing stuff conditionnaly

Unable to exit on incorrect credentials

If the user is unable to provide valid bitwarden credentials, setup-new-repo is stuck in a loop which eventually becomes unsolvable as Bitwarden replies Rate limit exceeded. Try again later.
It should respond correctly to ^C and exit in this case.

Worsen by #46 as an incorrect email leads to this.

harmonize param names

We should make sure params and envs are always referred to the same way. We don't want to abbreviate bitwarden (BW) nor borgbase (BB) in param and env names neither.

Note: those params have changed recently so that might be correct already but requires a check.

specify repo-name and periodicity as params

For clarity, we should distinguish important and actionnable switches from the configuration/authentication.

backup should thus get --name <repo-name> and --every <period> as cli params instead of environ.

Equally, setup-new-repo should use --name <repo-name> as cli param

OrganizationId and CollectionId should be fetched automatically

Standard use case (following documentation) is probably to have a single Organization and Collection on the master bitwarden account.

So in this case the setup-new-repo tool should automatically gather the Ids and setup accordingly instead or requesting manual entry. If there are multiple orgs or collections, we should ask to pick an id of course. We could also have an option to disable sharing.

Actually, I think the most practical would be something like this:

Scenario 1

Sharing your credentials to an Organization and Collection:
You belong to a single organization: Kiwix Backup (reg) - 9f386a8-febd-46f4-9cb6-ac4100a8339e
Do you want to share credentials with “Kiwix Backup (reg)”? [y/n]
OK, Shared with Kiwix Backup (reg)
# Following only displayed if answer to above question is yes
Your organization (Kiwix Backup (reg)) only have a single Collection: Default Collection - f889465c-f322-4768-9665-ac4100a833a3
Do you want to share credentials with “Default Collection”? [y/n]
OK, Shared with Default Collection

Scenario 2

Sharing your credentials to an Organization and Collection:
You belong to a 2 organizations:
1. Kiwix Backup (reg) - 9f386a8-febd-46f4-9cb6-ac4100a8339e 
2. Blabla2 - 9f386a8-febd-46f4-9cb6-ac4100a8341f
Do you want to share credentials with an organization? Enter it's number. Leave blank to not share credentials.
OK, Shared with Kiwix Backup (reg)
# Following only displayed if answer to above question is yes
Your organization (Kiwix Backup (reg)) has 2 collections:
1. Default Collection - f889465c-f322-4768-9665-ac4100a833a3
2. Kiwix Backcollect - f889465c-f322-4768-9665-ac4100a855b8
Do you want to share credentials with a collection? Enter it's number. Leave blank to not share credentials.
OK, Shared with Kiwix Backcollect

Avoid to check so often

Message from Borgbase:
You are – probably not intentionally – running very frequent repo checks on your repo download (zdt5q29g), which would read the whole repository over and over again. This is causing high server load and can make backups slower for other users, which is a problem if they need to actually restore data quickly. It will also slow your own backup time from minutes to hours.
Please review this and limit repo checks to once a month. For more details, we also have a detailed FAQ question on this topic.

Add interactive mode in Setting up command in README

We must add -ti args for this command :

docker run -ti kiwix/borg-backup setup-new-repo \
	--name <repo-name> \
	--bitwarden <bitwarden-master-email>
        --alert-days Periodicity of Borgbase e-mail alert in day(s) (default : 1d)
        --quota Quota in Mo (default : 2048, 0 : no quota)
        --region Server region (eu or us) (default : eu)

Setup-new-repo is too fragile

I keep on getting errors when trying to setup a new repo. Sometimes the 5 retries is just not enough.

I think we should understand the root cause of this: is this because borgbase needs a bit of time to set stuff up?

The consequence is when this happens, we've already sent SSH keypairs to bitwarden and created the repo on borgbase. So relaunching the same command may succeed but enventually, the backup step would fail because there are now multiple items for this repo in bitwarden. This requires manually connecting to bitwarden UI to remove them.
Alternative is to use a different repo name but then one have to manually delete the previous one from borgbase UI as the number of repo is limited.

Simplify repository setup

The setup ask for the BorgBase token, but considering that in 99% we only need one, this could be advantageously saved in Bitwarden (master) account. The setup would then, just need the Bitwarden credentials which is simplier.

I propose that we agree on the name of the BorgBase item, like for example "BACKUP_BORGBASE_TOKEN". If the item is there then use it, otherwise ask the setuper to give it (interactivly).

Initialize on each iteration?

While we mostly use it as single-backup, the image supports being run for a long time as it records cron jobs.
Long-running containers would initialize the borg repo (using the bitwarden credentials) upon start and just run borgmatic on every job started by cron.

Should borgbase configuration have changed since the start of the container, the borgmatic tasks would keep failing.

This happened with wp1 project where the container ran for 7 weeks but borgbase's target server changed in between. It resulted in container that keeps on launching the same task which always fails because the remote end changed.

Remote: ssh: Could not resolve hostname [box-eu16.borgbase.com](http://box-eu16.borgbase.com/): Name or service not known

As this is a first and it is now recorded in the ticket, let's wait and see if that is a frequent enough issue for us to fix it.

BorgBase credentials should be in BitWarden (not as Docker environnement variables)

The master Borgbase credentials (the ones allowing to do everything) should be kept only for BitWarden master user.

The master Borgbase credentials should be used to create a BorgBase repository and backuper credential with only append_only access to the corresponding BorgBase repository.

Backuper BorgBase crendentials should be stored by master (but readonly for user backuper) in Bitwarden.

We have to define a Bitwarden Entry reserver name to store the Master password and document it clearly (and have a clear error message if not available in Bitwarden at the setup time).

Borgbase key not saved in BW in interactive mode

When setting up a new repo using the syntax in README (ie. using the interactive mode for entering the borgbase key), the key is not properly saved to BW.

{
    "fields": [
            {
                "name": "BORGBASE_KEY",
                "value": null,
                "type": 0
            }
        ]
}

There is no error in setup-new-repo nor there is in backup. The backup initialization just fails with Cannot connect to BorgBase : 'NoneType' object is not iterable.

Tracing what happens shows an error in repo_exists with unexpected content

{
    "data": {
        "repoList": "None"
    },
    "errors": [
        {
            "locations": [
                {
                    "column": 7,
                    "line": 3
                }
            ],
            "message": "Not enough segments",
            "path": [
                "repoList"
            ]
        }
    ]
}

Couple things needs to be fixed:

  • Make sure interactive mode works
  • Test the credentials first before attempting to access data so we can fail with an understandable message
  • While you're at it, use fixed versions for dependencies. Installing latest borgmatic is much likely to break the tool some day.

make sure borgmatic commands don't overlap

Currently, only the scheduled borgmatic calls are protected by a file lock. The initial call is not which may lead to problem, especially during the very first call that can last more than an hour.

configure borgbase alertdays based on periodicity

Borgbase sends alert to repo owner if there's no activity on the repo for a given period. By default that period is one day.
Given we can specify the backup periodicity, we should maybe adjust the delay of those alerts as those can be annoying (borgbase sends them for 5 days)

Slower bitwarden login retries

It's relatively frequent that bitwarden authentication fails. It might be due to many different containers logging-in within a short period of time or not but when this happens, logs shows that bitwarden complains about the frequency of retries

Start initialization ...
Could not find dir, "/root/.config/Bitwarden CLI"; creating it instead.
Could not find data file, "/root/.config/Bitwarden CLI/data.json"; creating it instead.
Please try again ...
Please try again ...
Please try again ...
Please try again ...
Please try again ...
Unable to log in your Bitwarden account. Please check your credentials.
You are not logged in.Slow down! Too many requests. Try again in 1m.You are not logged in.Slow down! Too many requests. Try again in 1m.You are not logged in.Slow down! Too many requests. Try again in 1m.You are not logged in.Slow down! Too many requests. Try again in 1m.You are not logged in.Slow down! Too many requests. Try again in 1m.

We definitely shouldn't trigger this kind of response

Restriction on backup periodicity

We would like define backup periodicity in minutes, hours, week, days, or months. If we use Cron, I think that add some restriction :

  • The number of mimnute must be between 1 and 30,
  • the number of hour between 1 and 12.
  • the number of day between 1 and 14,
  • the number of month between 1 and 6.

And we can't easly use the week interval.

Better arguments management

Not a priority obviously but the way arguments are processed currently leave room for typos as there is no such thing as unexpected param so -alert-days 3 for instance (missing -) doesn't raise anything and just uses the default value.

configure borgmatic periodicity

Currently, borgmatic is ran every hour and we can only configure how many past archives we want to keep. We should be able to specify the periodicity (using --every) and that would adjust the cron configuration.

Question: what should be the default? 1h ? 1d ?

Matomo backup fail on mysqldump

matomo_backup | mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `piwik_archive_blob_2015_01` at row: 685145
matomo_backup | Command 'mysqldump --add-drop-database --host db --port 3306 --protocol tcp --user root --databases matomo > /root/.borgmatic/mysql_databases/db/all' returned non-zero exit status 3.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.