Kann ich einfach /var/discourse komplett packen und auf einem neuen Server ausführen?

[Monikas (JustMonika)]

Denn wenn ich versuche, mit dem integrierten Backup zu migrieren, füllt der Komprimierungsprozess schnell meine Festplatte. Ich hatte noch etwa 60 GB freien Speicherplatz, aber während des Backups wird die Festplatte voll und schlägt fehl.

Wenn ich jedoch den gesamten Ordner /var/discourse manuell komprimiere, ist das Archiv nur etwa 30 GB groß (der Ordner selbst ist etwa 34 GB groß).

Da die Kapazität direkt freigegeben wird, wenn sie voll ist, habe ich einen Screenshot bei 80 % gemacht.

Meine Fragen sind also:

• Kann ich einfach den gesamten Ordner /var/discourse packen, auf einen neuen Server verschieben, entpacken und dann Discourse ausführen?

• Oder muss ich den empfohlenen Weg befolgen (Datenbank-Backup + separate Übertragung der Uploads)?

• Gibt es eine Methode, um zu vermeiden, dass die Festplatte während des Backup-Komprimierungsprozesses vollläuft?

[Canapin (Coin-coin le Canapin)]

Hey,

@Monikas

Kann ich den gesamten Ordner /var/discourse einfach mit tar/packen, ihn auf einen neuen Server verschieben, entpacken und dann Discourse ausführen?

• Oder muss ich den empfohlenen Weg befolgen (Datenbanksicherung + separate Kopie der Uploads)?

Schau dir das an:

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

• Gibt es eine Möglichkeit, zu vermeiden, dass die Festplatte während des Backup-Komprimierungsprozesses vollläuft?

Ja, mehr freien Speicherplatz haben

Abgesehen von dieser offensichtlichen Antwort gibt es Funktionsanfragen, um zu verhindern, dass Backups bei der Erstellung mehr Speicherplatz beanspruchen, aber diese wurden noch nicht erfüllt: Reduce local disk space needs by not (redundantly) gzipping backups & Add option to disable backup compression

[pfaffman (Jay Pfaffman)]

Außerdem, wenn Sie noch keinen Befehl ausgeführt haben

./launcher cleanup

dann haben Sie möglicherweise eine Menge Docker-Images, die Speicherplatz belegen.

[Ethsim2 (Ethan)]

Ich glaube, docker system prune könnte helfen.

[Monikas (JustMonika)]

Ich habe es versucht, es auf 44 GB freigegeben, mein Server insgesamt 98, und dann habe ich S3 wieder gestartet, es funktioniert immer noch nicht, es ist nicht genug Platz, ich weiß nicht, was Discourse über so große Backups gesagt hat

[2025-08-20 10:11:31] Finalisiere Backup…

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

[2025-08-20 10:11:31] Stelle sicher, dass das Archiv noch nicht existiert…

[2025-08-20 10:11:31] Erstelle leeres Archiv…

[2025-08-20 10:11:31] Archiviere Daten-Dump…

[2025-08-20 10:11:31] Archiviere Uploads…

[2025-08-20 10:16:35] Entferne temporäres Verzeichnis ‘/var/www/discourse/tmp/backups/default/2025-08-20-101058’…

[2025-08-20 10:16:36] Gzippe Archiv, das kann eine Weile dauern…

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

Archiv konnte nicht gegziped werden.

gzip: /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar.gz: Kein Speicherplatz mehr auf dem Gerät

[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] Lösche alte Backups…

[2025-08-20 10:28:06] Bereinige Dinge…

[2025-08-20 10:28:06] Entferne ‘.tar’ Reste…

[2025-08-20 10:28:07] Markiere Backup als abgeschlossen…

[2025-08-20 10:28:07] Benachrichtige ‘VegaMonika’ über das Ende des Backups…

[pfaffman (Jay Pfaffman)]

Ich glaube, Sie müssen die .tar-Datei in /var/discourse/shared/standalone/backups/default löschen.

Es scheint, als hätten Sie mehr Uploads als in ein Backup passen. Sie müssen (1) eine größere Festplatte besorgen, (2) Assets nach Spaces oder S3 verschieben, (3) Uploads auf ein Volume verschieben, (4) keine Uploads sichern.

Die einfachste sofortige Lösung, nachdem Sie die .tar-Datei gelöscht haben, ist, keine Uploads zu sichern.

[Lee_Ars]

@Monikas

• Kann ich einfach den gesamten Ordner /var/discourse packen/archivieren, ihn auf einen neuen Server verschieben, entpacken und dann Discourse ausführen?

Ich habe eine Version davon als Teil eines Umzugs von einer EC2-Instanz zu einer größeren durchgeführt, jedoch mit der Einschränkung, dass der neue Server, den ich verwendete, exakt dasselbe Basis-Betriebssystem-Image, denselben Hostnamen, dieselbe installierte Software und dieselbe IP-Adresse wie der alte haben würde. Nachdem ich /var/discourse auf die neue Box verschoben hatte, führte ich einen launcher rebuild app aus und die Seite war sofort wieder online.

Unter diesen sehr spezifischen Umständen hat es also beim einzigen Mal, als ich es ausprobiert habe, hervorragend funktioniert.

[sam (Sam Saffron)]

Es ist eine unordentliche Art der Migration, aber solange es sich um eine Standardinstallation handelt und Sie sicherstellen, dass Sie zuerst alle Ihre Docker-Container stoppen, wird es wahrscheinlich funktionieren.

[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“