/var/discourse全体をtarにして、新しいサーバーで実行できますか？

[Monikas (JustMonika)]

Because when I try to migrate using the built-in backup, the compression process quickly fills up my disk. I still had around 60GB free space, but during backup the disk goes full and fails.

However, if I just manually compress the entire /var/discourse folder, the archive is only about 30GB (the folder itself is about 34GB).

Because the capacity is released directly when it is full, I took a screenshot at 80%.

So my questions are:

•	Can I simply tar/pack the entire /var/discourse folder, move it to a new server, extract it, and then run Discourse?

•	Or do I have to follow the recommended way (database backup + copy uploads separately)?

•	Is there any method to avoid the disk filling up during the backup compression process?

[Canapin (Coin-coin le Canapin)]

Hey,

@Monikas

Can I simply tar/pack the entire /var/discourse folder, move it to a new server, extract it, and then run Discourse?

•	Or do I have to follow the recommended way (database backup + copy uploads separately)?

Have a look at this:

Move a Discourse site to another VPS with rsync

This method is different than restoring file in UI. Maybe there is a more downtime but it’s simpler for linux folks without Discourse knowledge and it’s easy to automate. Prepare new VPS First, prepare our new Current Ubuntu LTS VPS with empty Discourse dir, OS upgrade and Docker install sudo mkdir -p /var/discourse sudo apt-get update sudo apt-get dist-upgrade wget -qO- https://get.docker.com/ | sh Then, make sure that we are on latest installed kernel and other libraries by just restarting …

@Monikas

•	Is there any method to avoid the disk filling up during the backup compression process?

Yes, having more free space

That obvious answer aside, there are feature requests to prevent backups from taking more space on creation, but they have not been fulfilled yet: Reduce local disk space needs by not (redundantly) gzipping backups & Add option to disable backup compression

[pfaffman (Jay Pfaffman)]

Also, if you haven’t done a

./launcher cleanup

then you may have a bunch of docker images taking up space.

[Ethsim2 (Ethan)]

i think docker system prune might help

[Monikas (JustMonika)]

I tried it liberated it to 44gb my server total 98 and then I started s3 again it still doesn’t work don’t have enough space don’t know what discourse said about backups being so big

[2025-08-20 10:11:31] Finalizing backup…

[2025-08-20 10:11:31] Creating archive: discourse-2025-08-20-101058-v20250812033430.tar.gz

[2025-08-20 10:11:31] Making sure archive does not already exist…

[2025-08-20 10:11:31] Creating empty archive…

[2025-08-20 10:11:31] Archiving data dump…

[2025-08-20 10:11:31] Archiving uploads…

[2025-08-20 10:16:35] Removing tmp ‘/var/www/discourse/tmp/backups/default/2025-08-20-101058’ directory…

[2025-08-20 10:16:36] Gzipping archive, this may take a while…

[2025-08-20 10:28:05] EXCEPTION: gzip -1 /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar

Failed to gzip archive.

gzip: /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar.gz: No space left on device

[2025-08-20 10:28:05] /var/www/discourse/lib/discourse.rb:171:in `execute_command’

/var/www/discourse/lib/discourse.rb:137:in `exec’

/var/www/discourse/lib/discourse.rb:32:in `execute_command’

/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive’

/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run’

/var/www/discourse/script/spawn_backup_restore.rb:9:in `backup’

/var/www/discourse/script/spawn_backup_restore.rb:31:in `block in ’

/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork’

/var/www/discourse/script/spawn_backup_restore.rb:4:in `’

[2025-08-20 10:28:05] Deleting old backups…

[2025-08-20 10:28:06] Cleaning stuff up…

[2025-08-20 10:28:06] Removing ‘.tar’ leftovers…

[2025-08-20 10:28:07] Marking backup as finished…

[2025-08-20 10:28:07] Notifying ‘VegaMonika’ of the end of the backup…

[pfaffman (Jay Pfaffman)]

I think you’ll need to delete the .tar file left in /var/discourse/shared/standalone/backups/default

It sounds like you have more uploads than will fit in a backup. You’ll need to (1) get a bigger disk, (2) move assets to Spaces or S3, (3) move uploads to a volume, (4) don’t backup uploads

The simplest immediate solution, after you delete the .tar file, is to not backup uploads.

[Lee_Ars]

@Monikas

• Can I simply tar/pack the entire /var/discourse folder, move it to a new server, extract it, and then run Discourse?

I have done a version of this as part of a move from one EC2 instance to a larger one, but with the caveat that the new server I was using was going to have the exact same base OS image, hostname, installed software, and IP address as the old one. After moving /var/discourse to the new box, I ran a launcher rebuild app and the site came right up.

So under those very specific circumstances, it worked great the one time I tried it.

[sam (Sam Saffron)]

It is a messy way of moving, but as long as it’s a default install and you make sure you stop all your docker containers first, it will probably work

[Ethsim2 (Ethan)]

snap remove aws-cli

.\launcher stop app

docker system prune

apt autoremove

.\launcher enter app

discourse backup

docker cp “app:/var/www/discourse/public/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz “ “root@[server_ip_address]:/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“

exit

snap install aws-cli --classic

aws configure

aws s3 cp “/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“ “myBucket://your-site-2006-01-02-150405-v20200101150405.tar.gz“

---

aws s3 cp “/var/discourse/containers/app.yml“ “myBucket://app.yml“