Restore Failing - Check Free Disk Space

I’m trying to do a restore on a freshly installed Discourse instance and I’m getting this error on CLI:

ERROR:  could not extend file "base/16384/17011337": wrote only 4096 of 8192 bytes at block 15860
HINT:  Check free disk space.
EXCEPTION: psql failed: HINT:  Check free disk space.

The backup file I’m trying to restore is 22 GB (compressed gz) and I have 198 GB free on the server, so I feel like there’s no way this is actually a disk space issue. Any idea why it would be complaining here?

2 Likes

Do you have any idea of the uncompressed size? Also that doesn’t account for indexes, so may try in a server with more disk?

2 Likes

You can also check your disk partitions. It is possible you have 198 GB free on the server; but the server has more than one disk partition, as I’m sure you know. Maybe reply with the output of the df command?

2 Likes

I think the database was around 40 GB uncompressed. I took a backup of the board after importing from another forum software, so I assumed a restore would be no problem. I was definitely not lacking for disk before. I can add a bit more disk but I just thought there was no way it would need over 3x the size of the database.

Everything is partitioned on / so I don’t think there are any issues there:

2 Likes

Hey @Ghan

Did you start your restore from the command line or from the “docker manager” UI?

1 Like

Tried it both ways, but most recently on CLI. I will try increasing disk space and then watch the usage as the import progresses.

1 Like

I added 50 GB and it completed successfully. That’s a lot of disk space for a database.

Does the restore process add additional indexes compared to an import?

4 Likes

It stores your forum contents. We have 1GB Discourse instances and 500GB Discourse instances, depends on how much activity happens :stuck_out_tongue:

There is a query to know each table size in the PostgreSQL 13 update topic, maybe try running it and posting the results here?

3 Likes

I know we have a lot of content. But it seems that the space requirement ballooned simply by doing a backup and restore. We had over 100 GB of space free before the backup so I assumed it would not be a problem doing a restore, but the restore operation needed quite a bit more space than I expected. It looks like it was just a tiny bit short.

I am trying to run the query to show the top 20 largest objects in the database, but it has been running about an hour now and I have no idea how long it will need until it completes.

1 Like

Check if the schemas backup and restore are still there. When a restore/backup fails catastrophiclly (like running out space) they may longer around. We have a background job that cleans it up weekly, but you may want to run it sooner.

Visit /sidekiq/scheduler and search for Jobs::DropBackupSchema and click on trigger.

2 Likes

If you have a full backup, then you’ll have 3 copies. The full backup, the database dump inside it, and the restored database, plus whatever database is there to start.

2 Likes