Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-4057

Handle database/filesystem conflicts (due to incorrect backup/restore) more gracefully

XMLWordPrintable

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      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!

              Unassigned Unassigned
              herzog@t-systems.com_match herzog@t-systems.com_match
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: