Backup same-named databases on the same host but with different ports #418

Open
opened 2021-05-09 15:42:19 +00:00 by Matows Β· 10 comments

What I'm trying to do and why

I have two instances on mysql running on my server, one for me on port 3307 and one for my friends running in a chroot on port 3308.
I want to backup both (127.0.0.1:3307 and 127.0.0.1:3308).

Steps to reproduce (if a bug)

Run two instances of mysql listening with different port. The easy way would be with docker, if you don't want to set up a chroot :

  • docker run --name db1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=mypassword -e MYSQL_DATABASE=borgmatic mysql
  • docker run --name db2 -p 3308:3306 -e MYSQL_ROOT_PASSWORD=mypassword -e MYSQL_DATABASE=borgmatic mysql

config.yaml in hooks section :

    mysql_databases:
        - name: all
          hostname: 127.0.0.1
          port: 3307
          username: root
          password: "mypassword"
        - name: all
          hostname: 127.0.0.1
          port: 3308
          username: root
          password: "mypassword"

Actual behavior (if a bug)

Ensuring legacy configuration is upgraded
/etc/borgmatic/config.yaml: No commands to run for pre-everything hook
/etc/borgmatic/config.yaml: No commands to run for pre-prune hook
/etc/borgmatic/config.yaml: Running command for pre-backup hook
/usr/local/bin/pushover -a backup -t "[example.com] Starting backup" -m "`LC_TIME=fr_FR.UTF-8; date`"
Succeeded
/etc/borgmatic/config.yaml: No commands to run for pre-check hook
XXXX@XXXX.repo.borgbase.com:repo: Pruning archives
borg prune --keep-daily 1 --keep-weekly 4 --keep-monthly 2 --prefix {hostname}- --debug --show-rc XXXX@XXXX.repo.borgbase.com:repo
using builtin fallback logging configuration
35 self tests completed in 0.10 seconds
SSH command line: ['ssh', 'XXXX@XXXX.repo.borgbase.com', 'borg', 'serve', '--umask=077', '--debug']
Remote: using builtin fallback logging configuration
Remote: 35 self tests completed in 0.05 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'repo'
Remote: Resolved repository path to '/srv/repos/XXXX/repo'
Remote: Verified integrity of /srv/repos/XXXX/repo/index.120
TAM-verified manifest
security: read previous location 'ssh://XXXX@XXXX.repo.borgbase.com/./repo'
security: read manifest timestamp '2021-05-09T15:06:10.348425'
security: determined newest manifest timestamp as 2021-05-09T15:06:10.348425
security: repository checks ok, allowing access
Verified integrity of /root/.cache/borg/6fd001a3b58d99ca2031b6f0fc74836916e20929821cd5159a11be4f2e29f6cc/chunks
security: read previous location 'ssh://XXXX@XXXX.repo.borgbase.com/./repo'
security: read manifest timestamp '2021-05-09T15:06:10.348425'
security: determined newest manifest timestamp as 2021-05-09T15:06:10.348425
security: repository checks ok, allowing access
RemoteRepository: 213 B bytes sent, 3.15 kB bytes received, 5 messages sent
terminating with success status, rc 0
XXXX@XXXX.repo.borgbase.com:repo: Creating archive
XXXX@XXXX.repo.borgbase.com:repo: Calling mysql_databases hook function remove_database_dumps
XXXX@XXXX.repo.borgbase.com:repo: Removing MySQL database dumps
XXXX@XXXX.repo.borgbase.com:repo: Calling mysql_databases hook function dump_databases
XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL databases
XXXX@XXXX.repo.borgbase.com:repo: Querying for "all" MySQL databases to dump
mysql --host 127.0.0.1 --port 3307 --protocol tcp --user root --skip-column-names --batch --execute show schemas
XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all
mysqldump --add-drop-database --host 127.0.0.1 --port 3307 --protocol tcp --user root --databases bookstack gitea nextcloud > /root/.borgmatic/mysql_databases/127.0.0.1/all
XXXX@XXXX.repo.borgbase.com:repo: Querying for "all" MySQL databases to dump
mysql --host 127.0.0.1 --port 3308 --protocol tcp --user root --skip-column-names --batch --execute show schemas
XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all
XXXX@XXXX.repo.borgbase.com:repo: Error running actions for repository
[Errno 17] File exists
ssh://borg@home.example.com:2662/~/repo/: Pruning archives
borg prune --keep-daily 1 --keep-weekly 4 --keep-monthly 2 --prefix {hostname}- --debug --show-rc ssh://borg@home.example.com:2662/~/repo/
using builtin fallback logging configuration
35 self tests completed in 0.09 seconds
SSH command line: ['ssh', '-p', '2662', 'borg@home.example.com', 'borg', 'serve', '--umask=077', '--debug']
Remote: using builtin fallback logging configuration
Remote: 35 self tests completed in 0.80 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'/~/repo'
Remote: Resolved repository path to '/home/borg/repo'
Remote: Verified integrity of /home/borg/repo/index.68
TAM-verified manifest
security: read previous location 'ssh://borg@home.example.com:2662/~/repo'
security: read manifest timestamp '2021-05-09T15:06:14.931915'
security: determined newest manifest timestamp as 2021-05-09T15:06:14.931915
security: repository checks ok, allowing access
Verified integrity of /root/.cache/borg/010af3507627a0ca0003142f4964820694c36ebf78e57603d7772191de086e6d/chunks
security: read previous location 'ssh://borg@home.example.com:262/~/repo'
security: read manifest timestamp '2021-05-09T15:06:14.931915'
security: determined newest manifest timestamp as 2021-05-09T15:06:14.931915
security: repository checks ok, allowing access
RemoteRepository: 220 B bytes sent, 3.08 kB bytes received, 5 messages sent
terminating with success status, rc 0
ssh://borg@home.example.com:2662/~/repo/: Creating archive
ssh://borg@home.example.com:2662/~/repo/: Calling mysql_databases hook function remove_database_dumps
ssh://borg@home.example.com:2662/~/repo/: Removing MySQL database dumps
ssh://borg@home.example.com:2662/~/repo/: Calling mysql_databases hook function dump_databases
ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL databases
ssh://borg@home.example.com:2662/~/repo/: Querying for "all" MySQL databases to dump
mysql --host 127.0.0.1 --port 3307 --protocol tcp --user root --skip-column-names --batch --execute show schemas
ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all
mysqldump --add-drop-database --host 127.0.0.1 --port 3307 --protocol tcp --user root --databases bookstack gitea nextcloud > /root/.borgmatic/mysql_databases/127.0.0.1/all
ssh://borg@home.example.com:2662/~/repo/: Querying for "all" MySQL databases to dump
mysql --host 127.0.0.1 --port 3308 --protocol tcp --user root --skip-column-names --batch --execute show schemas
ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all
ssh://borg@home.example.com:2662/~/repo/: Error running actions for repository
[Errno 17] File exists
/etc/borgmatic/config.yaml: Running command for on-error hook
/usr/local/bin/pushover -a backup -t '[example.com] BACKUP ERROR' -m "`LC_TIME=fr_FR.UTF-8; date`
repository: ssh://borg@home.example.com:2662/~/repo/
error: [Errno 17] File exists
output:
"
Succeeded
/etc/borgmatic/config.yaml: Error running configuration file
/etc/borgmatic/config.yaml: No commands to run for post-everything hook

summary:
/etc/borgmatic/config.yaml: Error running configuration file
XXXX@XXXX.repo.borgbase.com:repo: Error running actions for repository
[Errno 17] File exists
ssh://borg@home.example.com:2662/~/repo/: Error running actions for repository
[Errno 17] File exists

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

Expected behavior (if a bug)

Borgmatic successfully dump both 127.0.0.1:3307 and 127.0.0.1:3307 databases

Other notes / implementation ideas

Environment

borgmatic version: 1.5.13

borgmatic installation method: pip

Borg version: 1.1.9

Python version: 3.7.3

Database version (if applicable): mysql Ver 15.1 Distrib 10.3.27-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Use psql --version or mysql --version on client and server.

operating system and version: Debian GNU/Linux 10 (buster)

#### What I'm trying to do and why I have two instances on mysql running on my server, one for me on port 3307 and one for my friends running in a chroot on port 3308. I want to backup both (127.0.0.1:3307 and 127.0.0.1:3308). #### Steps to reproduce (if a bug) Run two instances of mysql listening with different port. The easy way would be with docker, if you don't want to set up a chroot : * `docker run --name db1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=mypassword -e MYSQL_DATABASE=borgmatic mysql` * `docker run --name db2 -p 3308:3306 -e MYSQL_ROOT_PASSWORD=mypassword -e MYSQL_DATABASE=borgmatic mysql` config.yaml in hooks section : ``` mysql_databases: - name: all hostname: 127.0.0.1 port: 3307 username: root password: "mypassword" - name: all hostname: 127.0.0.1 port: 3308 username: root password: "mypassword" ``` #### Actual behavior (if a bug) ``` Ensuring legacy configuration is upgraded /etc/borgmatic/config.yaml: No commands to run for pre-everything hook /etc/borgmatic/config.yaml: No commands to run for pre-prune hook /etc/borgmatic/config.yaml: Running command for pre-backup hook /usr/local/bin/pushover -a backup -t "[example.com] Starting backup" -m "`LC_TIME=fr_FR.UTF-8; date`" Succeeded /etc/borgmatic/config.yaml: No commands to run for pre-check hook XXXX@XXXX.repo.borgbase.com:repo: Pruning archives borg prune --keep-daily 1 --keep-weekly 4 --keep-monthly 2 --prefix {hostname}- --debug --show-rc XXXX@XXXX.repo.borgbase.com:repo using builtin fallback logging configuration 35 self tests completed in 0.10 seconds SSH command line: ['ssh', 'XXXX@XXXX.repo.borgbase.com', 'borg', 'serve', '--umask=077', '--debug'] Remote: using builtin fallback logging configuration Remote: 35 self tests completed in 0.05 seconds Remote: using builtin fallback logging configuration Remote: Initialized logging system for JSON-based protocol Remote: Resolving repository path b'repo' Remote: Resolved repository path to '/srv/repos/XXXX/repo' Remote: Verified integrity of /srv/repos/XXXX/repo/index.120 TAM-verified manifest security: read previous location 'ssh://XXXX@XXXX.repo.borgbase.com/./repo' security: read manifest timestamp '2021-05-09T15:06:10.348425' security: determined newest manifest timestamp as 2021-05-09T15:06:10.348425 security: repository checks ok, allowing access Verified integrity of /root/.cache/borg/6fd001a3b58d99ca2031b6f0fc74836916e20929821cd5159a11be4f2e29f6cc/chunks security: read previous location 'ssh://XXXX@XXXX.repo.borgbase.com/./repo' security: read manifest timestamp '2021-05-09T15:06:10.348425' security: determined newest manifest timestamp as 2021-05-09T15:06:10.348425 security: repository checks ok, allowing access RemoteRepository: 213 B bytes sent, 3.15 kB bytes received, 5 messages sent terminating with success status, rc 0 XXXX@XXXX.repo.borgbase.com:repo: Creating archive XXXX@XXXX.repo.borgbase.com:repo: Calling mysql_databases hook function remove_database_dumps XXXX@XXXX.repo.borgbase.com:repo: Removing MySQL database dumps XXXX@XXXX.repo.borgbase.com:repo: Calling mysql_databases hook function dump_databases XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL databases XXXX@XXXX.repo.borgbase.com:repo: Querying for "all" MySQL databases to dump mysql --host 127.0.0.1 --port 3307 --protocol tcp --user root --skip-column-names --batch --execute show schemas XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all mysqldump --add-drop-database --host 127.0.0.1 --port 3307 --protocol tcp --user root --databases bookstack gitea nextcloud > /root/.borgmatic/mysql_databases/127.0.0.1/all XXXX@XXXX.repo.borgbase.com:repo: Querying for "all" MySQL databases to dump mysql --host 127.0.0.1 --port 3308 --protocol tcp --user root --skip-column-names --batch --execute show schemas XXXX@XXXX.repo.borgbase.com:repo: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all XXXX@XXXX.repo.borgbase.com:repo: Error running actions for repository [Errno 17] File exists ssh://borg@home.example.com:2662/~/repo/: Pruning archives borg prune --keep-daily 1 --keep-weekly 4 --keep-monthly 2 --prefix {hostname}- --debug --show-rc ssh://borg@home.example.com:2662/~/repo/ using builtin fallback logging configuration 35 self tests completed in 0.09 seconds SSH command line: ['ssh', '-p', '2662', 'borg@home.example.com', 'borg', 'serve', '--umask=077', '--debug'] Remote: using builtin fallback logging configuration Remote: 35 self tests completed in 0.80 seconds Remote: using builtin fallback logging configuration Remote: Initialized logging system for JSON-based protocol Remote: Resolving repository path b'/~/repo' Remote: Resolved repository path to '/home/borg/repo' Remote: Verified integrity of /home/borg/repo/index.68 TAM-verified manifest security: read previous location 'ssh://borg@home.example.com:2662/~/repo' security: read manifest timestamp '2021-05-09T15:06:14.931915' security: determined newest manifest timestamp as 2021-05-09T15:06:14.931915 security: repository checks ok, allowing access Verified integrity of /root/.cache/borg/010af3507627a0ca0003142f4964820694c36ebf78e57603d7772191de086e6d/chunks security: read previous location 'ssh://borg@home.example.com:262/~/repo' security: read manifest timestamp '2021-05-09T15:06:14.931915' security: determined newest manifest timestamp as 2021-05-09T15:06:14.931915 security: repository checks ok, allowing access RemoteRepository: 220 B bytes sent, 3.08 kB bytes received, 5 messages sent terminating with success status, rc 0 ssh://borg@home.example.com:2662/~/repo/: Creating archive ssh://borg@home.example.com:2662/~/repo/: Calling mysql_databases hook function remove_database_dumps ssh://borg@home.example.com:2662/~/repo/: Removing MySQL database dumps ssh://borg@home.example.com:2662/~/repo/: Calling mysql_databases hook function dump_databases ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL databases ssh://borg@home.example.com:2662/~/repo/: Querying for "all" MySQL databases to dump mysql --host 127.0.0.1 --port 3307 --protocol tcp --user root --skip-column-names --batch --execute show schemas ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all mysqldump --add-drop-database --host 127.0.0.1 --port 3307 --protocol tcp --user root --databases bookstack gitea nextcloud > /root/.borgmatic/mysql_databases/127.0.0.1/all ssh://borg@home.example.com:2662/~/repo/: Querying for "all" MySQL databases to dump mysql --host 127.0.0.1 --port 3308 --protocol tcp --user root --skip-column-names --batch --execute show schemas ssh://borg@home.example.com:2662/~/repo/: Dumping MySQL database all to /root/.borgmatic/mysql_databases/127.0.0.1/all ssh://borg@home.example.com:2662/~/repo/: Error running actions for repository [Errno 17] File exists /etc/borgmatic/config.yaml: Running command for on-error hook /usr/local/bin/pushover -a backup -t '[example.com] BACKUP ERROR' -m "`LC_TIME=fr_FR.UTF-8; date` repository: ssh://borg@home.example.com:2662/~/repo/ error: [Errno 17] File exists output: " Succeeded /etc/borgmatic/config.yaml: Error running configuration file /etc/borgmatic/config.yaml: No commands to run for post-everything hook summary: /etc/borgmatic/config.yaml: Error running configuration file XXXX@XXXX.repo.borgbase.com:repo: Error running actions for repository [Errno 17] File exists ssh://borg@home.example.com:2662/~/repo/: Error running actions for repository [Errno 17] File exists Need some help? https://torsion.org/borgmatic/#issues ``` #### Expected behavior (if a bug) Borgmatic successfully dump both 127.0.0.1:3307 and 127.0.0.1:3307 databases #### Other notes / implementation ideas #### Environment **borgmatic version:** 1.5.13 **borgmatic installation method:** pip **Borg version:** 1.1.9 **Python version:** 3.7.3 **Database version (if applicable):** mysql Ver 15.1 Distrib 10.3.27-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 Use `psql --version` or `mysql --version` on client and server. **operating system and version:** Debian GNU/Linux 10 (buster)
Owner

Ugh! This is a side effect of the way borgmatic namespaces database dump paths by hostname only rather than by hostname + port. The simple fix would be to add the port to the path. However that would break all existing database backup restores that don't contain the port in the path. I think solving this may require updating the restore logic to probe the path: First by hostname + port and then just by hostname.

Thank you for reporting this!

Ugh! This is a side effect of the way borgmatic namespaces database dump paths by hostname only rather than by hostname + port. The simple fix would be to add the port to the path. However that would break all existing database backup restores that don't contain the port in the path. I think solving this may require updating the restore logic to probe the path: First by hostname + port and then just by hostname. Thank you for reporting this!
Owner

Additionally, there's this noted limitation from the docs:

borgmatic does not currently support backing up or restoring multiple databases that share the exact same name on different hosts.

Or in this case, different host + port combinations. So this limitation would have to be addressed to support this use case.

Additionally, there's this noted limitation from [the docs](https://torsion.org/borgmatic/docs/how-to/backup-your-databases/#limitations): > borgmatic does not currently support backing up or restoring multiple databases that share the exact same name on different hosts. Or in this case, different host + port combinations. So this limitation would have to be addressed to support this use case.
witten added the
good first issue
label 2023-02-04 21:22:06 +00:00
Collaborator

So to clarify, this issue will come up for all databases and not just MySQL DBs, maybe the issue title can be updated πŸ˜…?

Also, I checked dump.py::make_database_dump_filename(), it returns os.path.join(os.path.expanduser(dump_path), hostname or 'localhost', name).
As this includes hostname, shouldn't this function ensure that database backups with same database names but different hosts have different filenames, hence preventing the namespace collisions you mentioned earlier?

Other than that, yes, it's clear to me that this does not use the port, so that may cause errors.

I think solving this may require updating the restore logic to probe the path: First by hostname + port and then just by hostname.

I agree.

So to clarify, this issue will come up for all databases and not just MySQL DBs, maybe the issue title can be updated πŸ˜…? Also, I checked `dump.py::make_database_dump_filename()`, it returns `os.path.join(os.path.expanduser(dump_path), hostname or 'localhost', name)`. As this includes `hostname`, shouldn't this function ensure that database backups with same database names but different hosts have different filenames, hence preventing the namespace collisions you mentioned earlier? Other than that, yes, it's clear to me that this does not use the port, so that may cause errors. >I think solving this may require updating the restore logic to probe the path: First by hostname + port and then just by hostname. I agree.
witten changed title from [bug][mysql_databases] can't backup different mysql instances on same host to Backup same-named databases on the same host but with different ports 2023-03-18 04:00:35 +00:00
Owner

So to clarify, this issue will come up for all databases and not just MySQL DBs, maybe the issue title can be updated πŸ˜…?

Done!

Also, I checked dump.py::make_database_dump_filename(), it returns os.path.join(os.path.expanduser(dump_path), hostname or 'localhost', name).
As this includes hostname, shouldn't this function ensure that database backups with same database names but different hosts have different filenames, hence preventing the namespace collisions you mentioned earlier?

For creating a database dump, yes. For restoring, no! That's because restoration is currently done by database name:

usage: borgmatic restore [--repository REPOSITORY] --archive ARCHIVE [--database NAME [NAME ...]] [-h]

I'm pretty sure borgmatic/actions/restore.py:get_configured_database() is part of the problem here.

> So to clarify, this issue will come up for all databases and not just MySQL DBs, maybe the issue title can be updated πŸ˜…? Done! > Also, I checked dump.py::make_database_dump_filename(), it returns os.path.join(os.path.expanduser(dump_path), hostname or 'localhost', name). As this includes hostname, shouldn't this function ensure that database backups with same database names but different hosts have different filenames, hence preventing the namespace collisions you mentioned earlier? For creating a database dump, yes. For restoring, no! That's because restoration is currently done by database name: ``` usage: borgmatic restore [--repository REPOSITORY] --archive ARCHIVE [--database NAME [NAME ...]] [-h] ``` I'm pretty sure `borgmatic/actions/restore.py:get_configured_database()` is part of the problem here.
Collaborator

Ah okay, makes sense.
I referred the documentation and have another small doubt though, given that it only takes the database name to restore a database, what does borgmatic do when:

  1. There are 2 database dumps, PSQL and MySQL, both with the same name, users.
  2. There are 2 PSQL databases from different hosts, both with the same name users.

The third point, 2 databases with the same host and different port is covered by this issue of course.

Ah okay, makes sense. I referred the [documentation](https://torsion.org/borgmatic/docs/how-to/backup-your-databases/#restore-particular-databases) and have another small doubt though, given that it only takes the database name to restore a database, what does borgmatic do when: 1. There are 2 database dumps, PSQL and MySQL, both with the same name, `users`. 2. There are 2 PSQL databases from different hosts, both with the same name `users`. The third point, 2 databases with the same host and different port is covered by this issue of course.
Owner

There are 2 database dumps, PSQL and MySQL, both with the same name, users.

In this case, if the user tries to restore the "users" database on the command-line, the first database in configuration (across all database hooks) that matches "users" is restored. This logic is all in get_configured_database().

There are 2 PSQL databases from different hosts, both with the same name users.

Same thing as above: The first such matching database in configuration gets used.

I have a couple ideas for solving these restore issues with borgmatic:

  1. Add support for an optional database label/identifier that's distinct from the database name. That way, you could for instance label your database as "postgresql-users" or "media-server-users" and then refer to it by label when doing a restore.. even if it shares a database name with another database.
  2. Or: Add extra flags to the restore command-line so that you can specify additional characteristics of the database you're trying to restore so as to disambiguate it: hook name (postgresql, mysql, etc.), hostname, port, etc.

In either of these cases, borgmatic could error if it doesn't have enough information to disambiguate. (If there are more than one matching databases based on the info provided.)

I'm of course open to other ideas as well.

> There are 2 database dumps, PSQL and MySQL, both with the same name, users. In this case, if the user tries to restore the "users" database on the command-line, the first database in configuration (across all database hooks) that matches "users" is restored. This logic is all in `get_configured_database()`. > There are 2 PSQL databases from different hosts, both with the same name users. Same thing as above: The first such matching database in configuration gets used. I have a couple ideas for solving these restore issues with borgmatic: 1. Add support for an optional database label/identifier that's distinct from the database name. That way, you could for instance label your database as "postgresql-users" or "media-server-users" and then refer to it by label when doing a restore.. even if it shares a database name with another database. 2. Or: Add extra flags to the restore command-line so that you can specify additional characteristics of the database you're trying to restore so as to disambiguate it: hook name (`postgresql`, `mysql`, etc.), hostname, port, etc. In either of these cases, borgmatic could error if it doesn't have enough information to disambiguate. (If there are more than one matching databases based on the info provided.) I'm of course open to other ideas as well.
Collaborator

I like the second point more, add additional flags to the current restore command, seems to be more user friendly as I won't have to explicitly label every database and worry about uniqueness of these labels, and command usage will also almost remain the same.
By default, if I restore the users database, it will restore the first occurence, and if I pass the hostname/hookname/portname params it will try to match for those first in an order.
Will wait for some more community feedback/other approaches before I start this though.

I like the second point more, add additional flags to the current restore command, seems to be more user friendly as I won't have to explicitly label every database and worry about uniqueness of these labels, and command usage will also almost remain the same. By default, if I restore the users database, it will restore the first occurence, and if I pass the hostname/hookname/portname params it will try to match for those first in an order. Will wait for some more community feedback/other approaches before I start this though.
Owner

Sounds good!

Sounds good!

Are there any updates on this?

I just stumbled on the same problem,
I'm running local postgres cluster, 4 instances on one host and all of them with the same db name (but each of it, actually has different data) running on different ports. And while I can sugest changing db_name and make each db_name different, I'm looking in ways to fix it from borgmatic side first.

Are there any updates on this? I just stumbled on the same problem, I'm running local postgres cluster, 4 instances on one host and all of them with the same db name (but each of it, actually has different data) running on different ports. And while I can sugest changing db_name and make each db_name different, I'm looking in ways to fix it from borgmatic side first.
Collaborator

Hey, I started work on some other issues so I could not get a chance to look at this.
I have my exams soon, so I'll be back to contributing actively after the first week of May.

If someone else wants to work on this before that, feel free!

Hey, I started work on some other issues so I could not get a chance to look at this. I have my exams soon, so I'll be back to contributing actively after the first week of May. If someone else wants to work on this before that, feel free!
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#418
No description provided.