backupdb should store which grid it is scoped to #977

Open
opened 2010-03-02 23:57:05 +00:00 by davidsarah · 2 comments
davidsarah commented 2010-03-02 23:57:05 +00:00
Owner

On tahoe-dev, Brian Warner wrote:

Jody Harris wrote:

Any issues with switching a node (non-storage) from one grid to another?
You may want to erase your backupdb (~/.tahoe/private/backupdb.sqlite), because it will remember copying files to the old grid, and therefore skip uploading them to the new grid. The backupdb is really scoped to a specific grid.. if we had grid-identifiers of some sort, we'd either use a separate backupdb for each one, or add gridids into the SQL tables so "tahoe backup" would never confuse multiple grids.

On tahoe-dev, Brian Warner wrote: > Jody Harris wrote: > > Any issues with switching a node (non-storage) from one grid to another? > You may want to erase your backupdb (~/.tahoe/private/backupdb.sqlite), because it will remember copying files to the old grid, and therefore skip uploading them to the new grid. The backupdb is really scoped to a specific grid.. if we had grid-identifiers of some sort, we'd either use a separate backupdb for each one, or add gridids into the SQL tables so "tahoe backup" would never confuse multiple grids.
tahoe-lafs added the
code-frontend-cli
major
defect
1.6.0
labels 2010-03-02 23:57:05 +00:00
tahoe-lafs added this to the 1.7.0 milestone 2010-03-02 23:57:05 +00:00
davidsarah commented 2010-03-03 00:01:53 +00:00
Author
Owner

Also see #403 about grid identifiers. For this purpose, the domain name of the gateway might be sufficient, since that would only result in one inefficient backup run when using a different gateway to the same grid.

Also see #403 about grid identifiers. For this purpose, the domain name of the gateway might be sufficient, since that would only result in one inefficient backup run when using a different gateway to the same grid.
tahoe-lafs modified the milestone from 1.7.0 to soon 2010-06-19 01:06:43 +00:00
davidsarah commented 2011-01-15 10:16:41 +00:00
Author
Owner

#1310 was a duplicate:
Replying to [zooko]ticket:1310:

I use multiple grids (pub grid, volunteergrid, and a private family grid), and I just now had a confusing error where I ran tahoe backup and it completed quickly but produced a backup directory full of links to files with 0 shares each.

What happened, of course, was that I had previously run tahoe backup --node-url=<http://127.0.0.1:3458/> to backup these files to my family grid, and now I was running tahoe backup --node-url=<http://127.0.0.1:3457/> to backup these files to the volunteergrid, but I was unwittingly using the same backupdb.sqlite.

I wonder if, when the --node-url option is present, then the CLI shouldn't look into ~/.tahoe at all. Most of the configuration and state in ~/.tahoe is specific to the gateway that the --node-url points to, and the CLI will ignore it anyway and instead whatever configuration is in the tahoe-base-dir that is used by the gateway will take effect.

The only exception that I can think of right away is the private/backupdb.sqlite. Is that the only thing that affects the CLI when --node-url is present? Maybe it should be kept in a different directory.

I think I'm a bit confused about this. I'm not sure what all it means that there exists a ~/.tahoe when I'm actually using a gateway which runs as a separate user process, is specified by the --node-url option, and it has its own ~/.tahoe in its own user account. As a work-around and a way to gain clarity, I'll probably start specifying --node-directory in addition to --node-url, but this really feels wrong as it isn't a node directory at all! It is a CLI directory. :-)

#1310 was a duplicate: Replying to [zooko]ticket:1310: > I use multiple grids (pub grid, volunteergrid, and a private family grid), and I just now had a confusing error where I ran `tahoe backup` and it completed quickly but produced a backup directory full of links to files with 0 shares each. > > What happened, of course, was that I had previously run `tahoe backup --node-url=<http://127.0.0.1:3458/>` to backup these files to my family grid, and now I was running `tahoe backup --node-url=<http://127.0.0.1:3457/>` to backup these files to the volunteergrid, but I was unwittingly using the same `backupdb.sqlite`. > > I wonder if, when the `--node-url` option is present, then the CLI shouldn't look into `~/.tahoe` at all. Most of the configuration and state in `~/.tahoe` is specific to the gateway that the `--node-url` points to, and the CLI will ignore it anyway and instead whatever configuration is in the tahoe-base-dir that is used by the gateway will take effect. > > The only exception that I can think of right away is the `private/backupdb.sqlite`. Is that the only thing that affects the CLI when `--node-url` is present? Maybe it should be kept in a different directory. > > I think I'm a bit confused about this. I'm not sure what all it means that there exists a `~/.tahoe` when I'm actually using a gateway which runs as a separate user process, is specified by the `--node-url` option, and it has its own `~/.tahoe` in its own user account. As a work-around and a way to gain clarity, I'll probably start specifying `--node-directory` in addition to `--node-url`, but this really feels wrong as it isn't a node directory at all! It is a CLI directory. :-)
tahoe-lafs modified the milestone from soon to 1.9.0 2011-01-15 10:16:41 +00:00
tahoe-lafs modified the milestone from 1.9.0 to 1.10.0 2011-08-13 23:27:28 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
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: tahoe-lafs/trac-2024-07-25#977
No description provided.