# Storage corruption when creating new AiiDA instance

**URL:** <https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596>\
**Category:** General Usage\
**Tags:** aiida\
**Created:** [April 2, 2025, 8:57am UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596 "2025-04-02T08:57:55Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![gjoalland13](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/gjoalland13/32/330_2.png) [@gjoalland13](https://aiida.discourse.group/u/gjoalland13)\
**Post date:** [April 2, 2025, 8:57am UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/1 "2025-04-02T08:57:55Z")

</div>

Hi,  
While fixing the issue using AiiDaQE in multiple Conda environments, I moved the configuration folder of my environment to a new location and updated the `AIIDA_PATH` variable as suggested [here](https://aiida.discourse.group/t/usage-of-aiida-qe-in-multiple-conda-environments/595/4). I moved the config directory to `"$CONDA_PREFIX"`, but I missunderstood the [documentation instructions](https://aiida.readthedocs.io/projects/aiida-core/en/stable/howto/installation.html#isolating-multiple-instances) and initially set:

```auto
AIIDA_PATH="$CONDA_PREFIX/.aiida"`

```

This mistake caused AiiDA to fail to locate the configuration folder, leading to the creation of a new one:

```auto
(base) gjoalland@ctimac001:~/.conda/envs/aiida$ conda activate aiida
/home/gjoalland/work/setup/aiida-core/src/aiida/manage/configuration/settings.py:109: UserWarning: Creating AiiDA configuration folder `/home/gjoalland/.conda/envs/.aiida/.aiida`.
  warnings.warn(f'Creating AiiDA configuration folder `{path}`.')

```

I quickly realized my mistake when my AiiDA profile was missing. I deleted the newly created `.aiida` folder, corrected the `AIIDA_PATH` variable , and restarted the environment in a new terminal tab.  
Just to be clear, this behavior is exactly as described in the warning in the [documentation](https://aiida.readthedocs.io/projects/aiida-core/en/stable/howto/installation.html#isolating-multiple-instances) :

 ![image](https://global.discourse-cdn.com/free1/uploads/aiida/original/1X/a113198f0197b071669d410a605eeeb258c2c795.png)

However, after correcting the issue, I discovered that the storage folder was somehow modified, and now the storage is corrupted:

```auto
(aiida) gjoalland@ctimac001:~/.conda/envs/aiida/.aiida$ verdi status
 ✔ version: AiiDA v2.6.2.post0
 ✔ config: /home/gjoalland/.conda/envs/aiida/.aiida
 ✔ profile: gjoalland
 ✘ storage: Storage is corrupted.
Error: CorruptStorage: The database has a repository UUID configured to c228ae00760a4523aa0788862923716d but the disk-objectstore's is b6297ef9a24b4237aa289f4d39bb7490.
 ✔ broker: RabbitMQ v3.12.1 @ amqp://guest:guest@127.0.0.1:5672?heartbeat=600
 ✔ daemon: Daemon is running with PID 511294

```

Any suggestion on how to solve the problem?

On my own, I attempted several solutions and confirmed that the database and nodes are still present, but many operations remain unavailable.  
Does anyone have suggestions on how to resolve this issue?  
Thanks in advance!

---

<div class="post-metadata">

**Author:** ![gjoalland13](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/gjoalland13/32/330_2.png) [@gjoalland13](https://aiida.discourse.group/u/gjoalland13)\
**Post date:** [April 2, 2025, 9:24am UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/2 "2025-04-02T09:24:38Z")

</div>

One approach I tried was manually updating the storage configuration:

1. **Locate the storage folder**  
I found the storage location using the following command:

```auto
gjoalland@ctimac001:~/.conda/envs/aiida$ verdi profile show gjoalland | grep repository
    repository_uri: file:///home/gjoalland/repository/gjoalland

```

1. **Modify the** `container_id` **key**  
I edited the file `/home/gjoalland/repository/gjoalland/container/config.json` , replacing the value of `"container_id"`:

```auto
"b6297ef9a24b4237aa289f4d39bb7490"

```

with

```auto
"c228ae00760a4523aa0788862923716d"

```

This partially resolved the issue. I regained access to storage nodes, and initially, everything seemed to be working fine:

```auto
(aiida) gjoalland@ctimac001:~/repository$ verdi status
 ✔ version: AiiDA v2.6.2.post0
 ✔ config: /home/gjoalland/.conda/envs/aiida/.aiida
 ✔ profile: gjoalland
 ✔ storage: Storage for 'gjoalland' [open] @ postgresql+psycopg://gjoalland:***@localhost:5432/aiida_database / DiskObjectStoreRepository: c228ae00760a4523aa0788862923716d | /home/gjoalland/repository/gjoalland/container
 ✔ broker: RabbitMQ v3.12.1 @ amqp://guest:guest@127.0.0.1:5672?heartbeat=600
 ⏺ daemon: The daemon is not running.

```

However, after testing further, I found that some features remain broken. For example, I cannot submit calculations, and attempting to retrieve calculation outputs with `verdi calcjob outputcat <PK>` results in errors like this:

```auto
(aiida) gjoalland@ctimac001:~$ verdi calcjob outputcat 20744
Critical: Could not open output path "aiida.out". Exception: object with key `07fd16323f5022864707cba97a86a06911c99c9e61e6d3e491c683d3ffd024f2` does not exist.

```

Does anyone have suggestions on how to fully resolve this issue?

---

<div class="post-metadata">

**Author:** ![giovannipizzi](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/giovannipizzi/32/17_2.png) [@giovannipizzi](https://aiida.discourse.group/u/giovannipizzi)\
**Post date:** [April 2, 2025, 10:44am UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/3 "2025-04-02T10:44:32Z")

</div>

Hi, I’m not sure I follow 100% what exactly happened, but I give the explanation of what should happen, hopefully you can fix things in this way.

1. AiiDA stores node information in 2 places:  
a. the database (where the node PK, UUID, modification time, links, … are stored, but also all attributes and extras of the nodes).  
b. the repository (a folder on disk, managed by the disk-objectstore library for efficiency)

2. The two have to be always “paired together”: the DB it’s just written something like "This node with PK= 20744 has a file that is stored in the corresponding repository, the filename is aiida.out and the file hash (to find it in the repository) is 07fd16323f5022864707cba97a86a06911c99c9e61e6d3e491c683d3ffd024f2

3. In order to ensure that you don’t mix by mistake repository and DBs of different repos (what’s happening in your case…), they are assigned an unique UUID (the same for each pair), this is checked and this is the error you get. Indeed, somehow your configuration is trying now to mix a DB and a different repository.

4. Of course if, as you did, change the UUID of one of the two, AiiDA will not notice immediately, but the files you are looking for will not be there anymore.

So the solution, in your case, (if the DB is correct, which I assume since you know the PK and you get correctly that it’s a CalcJob etc. - but you assigned the wrong repo) is to find where the “correct” repository is, before you moved things around. It should have the correct container\_id. You can check in the places where AiiDA would put it by default, that is, as a subfolder of the corresponding .aiida folder.

Hope this helps!

---

<div class="post-metadata">

**Author:** ![gjoalland13](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/gjoalland13/32/330_2.png) [@gjoalland13](https://aiida.discourse.group/u/gjoalland13)\
**Post date:** [April 2, 2025, 1:32pm UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/4 "2025-04-02T13:32:38Z")

</div>

Hi,

Thanks for the quick reply and the clear explanations! After further investigation, I can confirm that I do not have another `.aiida` configuration folder:

```auto
(aiida) gjoalland@ctimac001:~/.conda/envs/aiida/.aiida$ sudo find / -type d -name ".aiida"
/home/gjoalland/.conda/envs/aiida/.aiida

```

This folder doesn’t contain anything particularly relevant except for several `config.json` files, all of which point to the same storage location that I already know:

```auto
(aiida) gjoalland@ctimac001:~/.conda/envs/aiida/.aiida$ ls
access config.json.20250401-140258.625873
config.json config.json.20250401-140429.876085
config.json.20250318-130045.874063 config.json.20250401-140438.101310
config.json.20250318-130046.172942 config.json.20250401-155744.456689
config.json.20250318-130046.220621 config.json.20250401-160050.097561
config.json.20250320-123015.982679 daemon
config.json.20250327-193423.929439
(aiida) gjoalland@ctimac001:~/.conda/envs/aiida/.aiida$ cat config* | grep repo
"repository_uri": "file:///home/gjoalland/repository/gjoalland"
"repository_uri": "file:///home/gjoalland/repository/gjoalland"
...
"repository_uri": "file:///home/gjoalland/repository/gjoalland"

```

This confirms that even two weeks ago, the storage repository was the same, meaning it was likely erased rather than moved.

Just in case, I also searched for any other directories named `gjoalland` that might contain a storage repository:

```auto
(aiida) gjoalland@ctimac001:~/.conda/envs/aiida/.aiida$ sudo find / -type d -name "gjoalland"
/home/gjoalland # the home folder
/home/gjoalland/.conda/envs/aiida/.aiida/access/gjoalland # a subfolder of the config folder. It does not contain any relevent information
/home/gjoalland/.conda/envs/aiida/SAVE_.aiida/access/gjoalland # a copy of the config folder I created
/home/gjoalland/repository/gjoalland # the storage folder of the gjoalland profile

```

I’m starting to wonder if the “links” you described in _2._ still exist. Unfortunately, it doesn’t seem like they do.

Is there any way to restore them? Unfortunately, I don’t have a backup…

If not, would it be possible to delete my current AiiDA profile while keeping the database, then create a new profile with a fresh storage repository but linked to the same database? Would that restore the links?

---

<div class="post-metadata">

**Author:** ![giovannipizzi](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/giovannipizzi/32/17_2.png) [@giovannipizzi](https://aiida.discourse.group/u/giovannipizzi)\
**Post date:** [April 3, 2025, 1:15pm UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/5 "2025-04-03T13:15:16Z")

</div>

Mmm that’s strange. I don’t see where AiiDA would delete the container. The only way I see is if you run `verdi profile delete` (but then you would do it consciously, and also the DB would be deleted, in principle).

There is no other “link” except that the DB has the checksum SHA256 of each file of a node (e.g. 07fd16323f5022864707cba97a86a06911c99c9e61e6d3e491c683d3ffd024f2) - and that the repository container has the same UUID as the DB.

One more thing, just to do a final check, would be: the repository contains folders named `loose`, `duplicates`, `packs`, `sandbox` (and a file called `packs.idx`). You could try to do a search for those folders/files…

> If not, would it be possible to delete my current AiiDA profile while keeping the database, then create a new profile with a fresh storage repository but linked to the same database? Would that restore the links?

No - I mean, what you did by changing the UUID is essentially this, but the point is: if you have a file (e.g. the raw input or output of a calculation) belonging to a node, that node is always going to complain when you try to access that file, because you don’t have it anymore (the fresh storage repository would also be empty). You should really try to find the repository…

---

<div class="post-metadata">

**Author:** ![giovannipizzi](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/giovannipizzi/32/17_2.png) [@giovannipizzi](https://aiida.discourse.group/u/giovannipizzi)\
**Post date:** [April 3, 2025, 1:17pm UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/6 "2025-04-03T13:17:16Z")

</div>

> [@gjoalland13](#):
>
> I quickly realized my mistake when my AiiDA profile was missing. I deleted the newly created `.aiida` folder

Reading back your earlier message above: is it possible that you didn’t just delete `/home/gjoalland/.conda/envs/.aiida/.aiida` but `/home/gjoalland/.conda/envs/.aiida/` that possibly contained the repository, thus deleting it?

---

<div class="post-metadata">

**Author:** ![gjoalland13](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/gjoalland13/32/330_2.png) [@gjoalland13](https://aiida.discourse.group/u/gjoalland13)\
**Post date:** [April 4, 2025, 3:14pm UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/7 "2025-04-04T15:14:53Z")

</div>

After some further investigations, the folder appears to be the correct one, as it contains the folders named `loose`, `duplicates`, `packs`, and `sandbox`, as well as the `packs.idx` file:

```auto
(base) gjoalland@ctimac001:~/repository/gjoalland/container$ ls
config.json loose packs.idx packs.idx-wal
duplicates packs packs.idx-shm sandbox
(base) gjoalland@ctimac001:~/repository/gjoalland/container$ ls packs
(base) gjoalland@ctimac001:~/repository/gjoalland/container$ ls sandbox/
(base) gjoalland@ctimac001:~/repository/gjoalland/container$ ls duplicates/
(base) gjoalland@ctimac001:~/repository/gjoalland/container$ ls loose
35 3f 51 9a

```

However, the `loose` folder contains only a few files, all created after the incident. This strongly suggests that most of my data has been lost. I used to have over 30,000 nodes, so I would expect roughly 30,000 files spread across the four folders in `loose`.

> [@giovannipizzi](#):
>
> Reading back your earlier message above: is it possible that you didn’t just delete `/home/gjoalland/.conda/envs/.aiida/.aiida` but `/home/gjoalland/.conda/envs/.aiida/` that possibly contained the repository, thus deleting it?

Following this message, I was carefull not to do that. I copied the folder elsewhere and then deleted `/home/gjoalland/.conda/envs/.aiida/` before moved it back afterward.

> [@giovannipizzi](#):
>
> Mmm that’s strange. I don’t see where AiiDA would delete the container. The only way I see is if you run verdi profile delete (but then you would do it consciously, and also the DB would be deleted, in principle).

After some investigation, I remembered that after moving back the folder, I did run `verdi profile delete gjoalland --keep-data`, and then reconfigured it using `verdi profile setup`. I had forgotten this step as in did not change the output of the `verdi status` command. However, this probably explains the deletion of the files in the `loose` directory and is consistent with the fact that the database itself was not deleted.

So… I guess I’m kind of screwed, right?

I suppose there’s no other solution than to create a fresh environment and try to recover whatever I can from the corrupted environment. I’ll attempt this by editing the file `/home/gjoalland/repository/gjoalland/container/config.json`, replacing the value of `"container_id"` with `"c228ae00760a4523aa0788862923716d"` in the hope of recovering anything that might still be accessible. 😕

---

<div class="post-metadata">

**Author:** ![giovannipizzi](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/giovannipizzi/32/17_2.png) [@giovannipizzi](https://aiida.discourse.group/u/giovannipizzi)\
**Post date:** [April 4, 2025, 3:45pm UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/8 "2025-04-04T15:45:10Z")

</div>

I have to say that yes, from your report, I don’t think there is much more that can be done… Note that AiiDA since 2.6 comes with a backup command. We strongly suggest running backups (in general, but in particular before any kind of migration). I’m sorry…

---

<div class="post-metadata">

**Author:** ![gjoalland13](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/gjoalland13/32/330_2.png) [@gjoalland13](https://aiida.discourse.group/u/gjoalland13)\
**Post date:** [April 7, 2025, 7:20am UTC](https://aiida.discourse.group/t/storage-corruption-when-creating-new-aiida-instance/596/9 "2025-04-07T07:20:48Z")

</div>

I see… Thank you for the help and the advices!  
For now on, I will make regular backups to prevent this from happening again…