NocoDB v1.32.0 restore from backup fails - PostgreSQL role already exists error

[ivan-petro]

Hi,

I'm having issues restoring NocoDB v1.32.0 from a backup. The restore task consistently fails.

Environment:

• Cloudron version: v8.3.1
• OS: Ubuntu 24.04.2 LTS
• PostgreSQL allocated memory: 63 GiB (usually 5-10 GB used)
• PostgreSQL works correctly for other apps

Problem:
After running the restore from backup, the task fails. I restarted PostgreSQL and tried "Retry task", but it still fails.

PostgreSQL logs:

add: adding database db4fd86909c95a4f079147e3854b98203f
2026-01-28 08:55:34.684 UTC [974] root@postgres ERROR: role "db4fd86909c95a4f079147e3854b98203f" already exists
2026-01-28 08:55:34.684 UTC [974] root@postgres STATEMENT: CREATE ROLE db4fd86909c95a4f079147e3854b98203f NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOLOGIN
add: failed to create database. error: role "db4fd86909c95a4f079147e3854b98203f" already exists

Task error:

Addons Error: Error setting up postgresql. Status code: 500 message: role "db4fd86909c95a4f079147e3854b98203f" already exists

It seems the restore process tries to create a PostgreSQL role that already exists from a previous failed attempt. Is there a way to clean up this orphaned role, or should Cloudron's restore process handle this case with CREATE ROLE IF NOT EXISTS or DROP ROLE IF EXISTS before creating?

Any help would be appreciated. Thank you!

[james]

Hello @ivan-petro

Can you share with me what backup provider you are using and how you did restore the app backup?
Did you uninstall the app first and imported the backup or did you select one of the latest backups in the app view?

[joseph]

@ivan-petro a workaround might be to download the backup config. Then install a new nocodb and import the backup config.

[ivan-petro]

Thank you @james and @joseph for your quick responses!

1) Backup provider: AWS S3

2) Tried Joseph's suggestion - install new NocoDB and import backup config:

I created a fresh NocoDB app and tried to import the backup configuration from AWS. Got a different error - seems like the backup archive might be corrupted:

BoxError: tarExtract pipeline error: incorrect header check
at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async /home/yellowtent/box/src/backupformat/tgz.js:248:9
at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)
at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)

3) Tried importing into the existing app:

Same PostgreSQL role error as before:

Addons Error: Error setting up postgresql. Status code: 500 message: role "db4fd86909c95a4f079147e3854b98203f" already exists

Summary of the situation:

• Fresh app + import → tarExtract pipeline error: incorrect header check (possibly corrupted backup?)
• Existing app + import → role already exists error

Is there a way to:

1. Verify if the backup file on S3 is intact/not corrupted?
2. Manually clean up the orphaned PostgreSQL role db4fd86909c95a4f079147e3854b98203f so the existing app restore can proceed?

Let me know if you need any additional logs or information.

[ivan-petro]

While waiting for your response, I'm considering manually cleaning up the orphaned PostgreSQL role.

Could you please confirm - is it safe to run the following commands?

DROP ROLE IF EXISTS db4fd86909c95a4f079147e3854b98203f;
DROP DATABASE IF EXISTS db4fd86909c95a4f079147e3854b98203f;

Or should I only drop the role and keep the database (if it exists)?

Also, I'm concerned - if I drop these and the restore still fails (especially with the tarExtract error on the new app), will I lose any chance to recover the data? Is there any way to verify the backup integrity on S3 first, or should I make a local copy of the backup before attempting any cleanup?

[joseph]

@ivan-petro You can download the backup file directly from S3 and try to extract it (on your laptop). Inside it you will find the postgresqldump and other data files. Backup -> Info will give the details of the path (remote path) in S3 . That will help us determine if the backup is corrupt or not.