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

XMLWordPrintable

      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!

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

              Created:
              Updated:
              Resolved: