Database restore script fails though errors from pg_restore are not severe

Feedback
,
1

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.
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.

2

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.

3

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.

4

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, so that we can try to reproduce and solve it.

1 Like
5

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.

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?

6

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

1 Like