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?
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?
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?
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:
Tried it both ways, but most recently on CLI. I will try increasing disk space and then watch the usage as the import progresses.
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?
It stores your forum contents. We have 1GB Discourse instances and 500GB Discourse instances, depends on how much activity happens 
There is a query to know each table size in the PostgreSQL 13 update topic, maybe try running it and posting the results here?
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.
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.
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.
