-
Suggestion
-
Resolution: Duplicate
-
None
-
None
-
RHEL Linux.
Original summary: "Add check on creating/deleting a Repository"
Hi.
On my Backup/restore tests I wanted to find out what happens if I do this backup "online" (hot-backup).
I found out that always the database has the main knowledge of the system configuration and it seems only the filesystem (stash_home) knows some extra informations about plugins and repositories.
In a scenario where you create a database backup followed by the backup of stash_home within a huge (unnatuaral) period of time you can describe following case:
if you create a repository within this time, it comes that if you restore that backup - this repository is gone. This is okay as at the time of the database backup the repository was unknown. But sadly this repository exists in the stash_home filesystem. First nobody knows BUT:
If you now try to create a new Repository on this restored system you get an error: stash says the reppsitory "repoID" (it's the repo-id-number) would exist... Looking into the filesystem you will see this repo existing...
I came to the conclusion that Stash iterates by 1 when creating a new repository...
I'd like to ask you to improve that by checking first if a repo with the next iteration already exists and suggest to create a new repository with one more iteration. Also put a big warning that it seems there is a "ghost-repository"
this would not paralyze our users from creatign repositories when having a huge stash-instance later 
You can imageine that there is obviously the same counter when deleting a repository within that timespan.
Maybe as a spanning view I'd suggest to store some metainformation (which stash-project, wich repo-name) inside the bulk-repository on the filesystem. (I'll look for an open issue for that or open another one later)
Thanks!
- duplicates
-
- Closed
[BSERV-4057] Handle database/filesystem conflicts (due to incorrect backup/restore) more gracefully
| Workflow | Original: JAC Suggestion Workflow [ 3396353 ] | New: JAC Suggestion Workflow 3 [ 3624451 ] |
| Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: BSERV Suggestions Workflow [ 2687605 ] | New: JAC Suggestion Workflow [ 3396353 ] |
| Workflow | Original: Stash Workflow [ 579781 ] | New: BSERV Suggestions Workflow [ 2687605 ] |
| Status | Original: Closed [ 6 ] | New: Resolved [ 5 ] |
| Resolution | New: Duplicate [ 3 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
| Link |
New:
This issue duplicates |
| Affects Version/s | Original: 2.8.3 [ 37296 ] | |
| Issue Type | Original: Improvement [ 4 ] | New: Suggestion [ 10000 ] |
| Labels | Original: backup repo-mgmt restore | |
| Priority | Original: Minor [ 4 ] |
Hi thank you for fiddling with that.
Well, your question is a good one. I can't really answer it but think of it.
As I know from other applications we run in our company they have some "consistency checks". Some are running on demand, others can be set on application start up. They compare the Data held in Database with the one that are stored in the filesystem. How they solve the conflicts differs from application to application and I don't really know what they internally really do if there are conflicts...
But as there is an unwritten general concept of how to do application backups: database first, filesystem later - it make sense to follow this by checking the consistency of DB vs FS by helding the DB as "base line information".
| Status | Original: Needs Triage [ 10030 ] | New: Open [ 1 ] |
| Description |
Original:
Hi.
On my Backup/restore tests I wanted to find out what happens if I do this backup "online" (hot-backup). I found out that always the database has the main knowledge of the system configuration and it seems only the filesystem (stash_home) knows some extra informations about plugins and repositories. In a scenario where you create a database backup followed by the backup of stash_home within a huge (unnatuaral) period of time you can describe following case: if you create a repository within this time, it comes that if you restore that backup - this repository is gone. This is okay as at the time of the database backup the repository was unknown. But sadly this repository exists in the stash_home filesystem. First nobody knows BUT: If you now try to create a new Repository on this restored system you get an error: stash says the reppsitory "repoID" (it's the repo-id-number) would exist... Looking into the filesystem you will see this repo existing... I came to the conclusion that Stash iterates by 1 when creating a new repository... I'd like to ask you to improve that by checking first if a repo with the next iteration already exists and suggest to create a new repository with one more iteration. Also put a big warning that it seems there is a "ghost-repository" this would not paralyze our users from creatign repositories when having a huge stash-instance later :) You can imageine that there is obviously the same counter when deleting a repository within that timespan. Maybe as a spanning view I'd suggest to store some metainformation (which stash-project, wich repo-name) inside the bulk-repository on the filesystem. (I'll look for an open issue for that or open another one later) Thanks! |
New:
Original summary: "Add check on creating/deleting a Repository"
Hi. On my Backup/restore tests I wanted to find out what happens if I do this backup "online" (hot-backup). I found out that always the database has the main knowledge of the system configuration and it seems only the filesystem (stash_home) knows some extra informations about plugins and repositories. In a scenario where you create a database backup followed by the backup of stash_home within a huge (unnatuaral) period of time you can describe following case: if you create a repository within this time, it comes that if you restore that backup - this repository is gone. This is okay as at the time of the database backup the repository was unknown. But sadly this repository exists in the stash_home filesystem. First nobody knows BUT: If you now try to create a new Repository on this restored system you get an error: stash says the reppsitory "repoID" (it's the repo-id-number) would exist... Looking into the filesystem you will see this repo existing... I came to the conclusion that Stash iterates by 1 when creating a new repository... I'd like to ask you to improve that by checking first if a repo with the next iteration already exists and suggest to create a new repository with one more iteration. Also put a big warning that it seems there is a "ghost-repository" this would not paralyze our users from creatign repositories when having a huge stash-instance later :) You can imageine that there is obviously the same counter when deleting a repository within that timespan. Maybe as a spanning view I'd suggest to store some metainformation (which stash-project, wich repo-name) inside the bulk-repository on the filesystem. (I'll look for an open issue for that or open another one later) Thanks! |
We'll track this suggestion in
BSERV-4255which we believe incorporates this.