# Database restore script fails though errors from pg\_restore are not severe

**URL:** https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753
**Category:** Feedback
**Tags:** self-hosting, database
**Created:** [July 18, 2025, 11:56am UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753 "2025-07-18T11:56:05Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![mkonrad](https://community.baserow.io/letter_avatar_proxy/v4/letter/m/7feea3/32.png) [@mkonrad](https://community.baserow.io/u/mkonrad)
#### Post date: [July 18, 2025, 11:56am UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/1 "2025-07-18T11:56:05Z")

</div>

I’m using Baserow 1.33.4, self-hosted, Docker single-image. I can confirm that the problem persists also in Baserow 1.34.2.

I have to report that the DB restore script doesn’t work under some circumstances. To be specific, in my case some of the batches to be restored contained `CREATE SEQUENCE` commands that led to `relation "..." already exists` errors which in turn made the restore script abort execution. However, these “errors” were not really a problem. When manually running the respecive pg\_restore commands, the backup could indeed be restored. Here are the details:

I created a DB backup with the following command:

```
docker compose run -it --remove-orphans baserow backend-cmd-with-db backup [...]

```

I then started the restore script. I made sure that it started with an empty data directory, which means that the database was initialized as “fresh” (I could confirm that this worked and the created database “baserow” was empty).

```
docker compose run -it --remove-orphans baserow backend-cmd-with-db restore -f <PATH_TO_BACKUP>

```

The first batches were OK, then the script stopped with the following output:

```
pg_restore --host=localhost --dbname=baserow --port=5432 --username=baserow -Fd --jobs=1 -w /dev/shm/[REDACTED]/user_tables_batch_28
pg_restore: error: could not execute query: ERROR: relation "field_47452_seq" already exists
Command was: CREATE SEQUENCE public.field_47452_seq
	START WITH 1
	INCREMENT BY 1
	NO MINVALUE
	NO MAXVALUE
	CACHE 1;

 [POSTGRES][2025-07-18 06:40:54] 2025-07-18 06:40:25.590 UTC [300] LOG: checkpoint starting: wal  
 [POSTGRES][2025-07-18 06:40:54] 2025-07-18 06:40:54.913 UTC [411] baserow@baserow ERROR: relation "field_47452_seq" already exists  
 [POSTGRES][2025-07-18 06:40:54] 2025-07-18 06:40:54.913 UTC [411] baserow@baserow STATEMENT: CREATE SEQUENCE public.field_47452_seq  
 [POSTGRES][2025-07-18 06:40:54] START WITH 1  
 [POSTGRES][2025-07-18 06:40:54] INCREMENT BY 1  
 [POSTGRES][2025-07-18 06:40:54] NO MINVALUE  
 [POSTGRES][2025-07-18 06:40:54] NO MAXVALUE  
 [POSTGRES][2025-07-18 06:40:54] CACHE 1;  
 [POSTGRES][2025-07-18 06:40:54] 	  
 [POSTGRES][2025-07-18 06:40:54] 	  
pg_restore: warning: errors ignored on restore: 1
CommandError: The back-up failed because of the failure of the following sub-command, please read the output of the failed command above to see what went wrong. 
The sub-command which failed was:
pg_restore --host=localhost --dbname=baserow --port=5432 --username=baserow -Fd --jobs=1 -w /dev/shm/tmp5d1js537/[REDACTED]/user_tables_batch_28
It failed with a return code of: 1

```

After I trying out different things, I settled with the following:

- extracted the backup archive gz file manually
- again started a container with a completely “fresh” database (no tables in it) and mounted the directory with the extracted backup files
- manually executed the pg\_restore commands one by one, i.e.

```auto
pg_restore --host=localhost --dbname=baserow --port=5432 --username=baserow -Fd --jobs=1 -w <PATH_TO_EXTRACTED_BACKUP>/user_tables_batch_0
pg_restore --host=localhost --dbname=baserow --port=5432 --username=baserow -Fd --jobs=1 -w <PATH_TO_EXTRACTED_BACKUP>/user_tables_batch_1
...

```

- for some batches, pg\_restore again complained about `CREATE SEQUENCE public.field_`, but it always ended with an `pg_restore: warning: errors ignored on restore: ...` with 1 to 3 ignored errors – which to me signalled that the errors could indeed be ignored

After that, it looked like the backup was successfully restored. Logs looked fine and the UI worked.

---

<div class="post-metadata">

### Author: ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)
#### Post date: [July 22, 2025, 1:20pm UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/2 "2025-07-22T13:20:39Z")

</div>

Hey @mkonrad, I’m sorry to hear that you’re having some problems with the export and import. It sounds a bit as if either the created backup is corrupt, or it’s not being restored properly.

Did you stop the Baserow instance when making the backup? If not, then I would highly recommend making the backup against a PostgreSQL that is not receiving any other queries.

Before restoring the backup into an empty PostgreSQL database, did you already start a Baserow instance connected to that database? That could cause the initial database migrations to have already been executed.

---

<div class="post-metadata">

### Author: ![mkonrad](https://community.baserow.io/letter_avatar_proxy/v4/letter/m/7feea3/32.png) [@mkonrad](https://community.baserow.io/u/mkonrad)
#### Post date: [July 22, 2025, 1:48pm UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/3 "2025-07-22T13:48:31Z")

</div>

The baserow instance (i.e. the baserow docker container) was always automatically stopped before running the DB backup. We’re using the “all-in-one” image, which also contains the PostgresDB. This means, the container was stopped (along with it the DB), the `baserow backend-cmd-with-db backup` command was executed via `docker run` as recommended in your docs and the backup was successfully created without any errors whatsoever. I expect that such a backup can then be restored, but this was not the case. As I already said, _the database was initialized as “fresh” (I could confirm that this worked and the created database “baserow” was empty)_. Running the restore command still failed and it did so because the restore command internally handled pg\_restore “errors” _that were actually nothing more than warnings_ as fatal and stopped. I’m repeating myself again, but manually restoring the backup batch by batch and _ignoring the warnings from pg\_restore_ resulted in a successful backup restoration. So it looks like the culprit is the baserow restore command.

---

<div class="post-metadata">

### Author: ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)
#### Post date: [July 23, 2025, 2:38pm UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/4 "2025-07-23T14:38:23Z")

</div>

Hey @mkonrad, my apologies, I didn’t realize that you’ve done a successful import using `pg_restore` manually and ignoring those warning. I’ve created an issue here [Backup/restore command can fail with `relation "field_{id}_seq" already exists` (#3761) · Issues · Baserow / baserow · GitLab](https://gitlab.com/baserow/baserow/-/issues/3761), so that we can try to reproduce and solve it.

---

<div class="post-metadata">

### Author: ![fcolak13](https://community.baserow.io/letter_avatar_proxy/v4/letter/f/5f8ce5/32.png) [@fcolak13](https://community.baserow.io/u/fcolak13)
#### Post date: [November 27, 2025, 11:36am UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/5 "2025-11-27T11:36:50Z")

</div>

I am having the exact same issue. I followed the steps as exactly described in backup/restore documents, and our script also stops everything before taking a backup.

```auto
pg_restore: warning: errors ignored on restore: 1
CommandError: The back-up failed because of the failure of the following sub-command, please read the output of the failed command above to see what went wrong. 
The sub-command which failed was:
pg_restore --host=localhost --dbname=baserow --port=5432 --username=baserow -Fd --jobs=1 -w /dev/shm/tmpeb3f5e4d/baserow_backup_20251122_0201.tar.gz/user_tables_batch_23
It failed with a return code of: 1

```

My problem is that, even if I import everything, I am still redirected to signup page instead of login. Any idea what could be the reason?

---

<div class="post-metadata">

### Author: ![fcolak13](https://community.baserow.io/letter_avatar_proxy/v4/letter/f/5f8ce5/32.png) [@fcolak13](https://community.baserow.io/u/fcolak13)
#### Post date: [November 27, 2025, 12:45pm UTC](https://community.baserow.io/t/database-restore-script-fails-though-errors-from-pg-restore-are-not-severe/10753/6 "2025-11-27T12:45:57Z")

</div>

Just to reply myself, login page issue is actually something different. I managed to import my backup successfully with @mkonrad’s way.