This is a post is a very condensed version of my last 24hrs, although it hasn’t actually worked yet so i’m also hoping someone will post where it went wrong below this. My Discourse update failed due to a duplicate key, one of my tags is doubled up. To fix the update issue i needed to do a fresh Di…

Thanks for replying. [画像] Jay Pfaffman: ./launcher start app to start the old container, was there a reaason that you couldn’t do that? It refused to start as we were a few upgrades behind, so i updated to the latest Discourse by creating a new one and uploading our old backup, but it reject…

[画像] Jay Pfaffman: Is this problem resolved? It reads as if it’s a how-to I was hoping someone might see an error in it and correct me, so it would become a ‘how to’ guide.

What I would look at next: Redo the whole unzip. Zip it up unchanged. Check the zip size is same as before. If not maybe you are not zipping with the same options? Unzip again, check file size of file you are editing. Edit it, save it, confirm size unchanged significantly.

A bit of an update. Someone else in my team was working on this last week but a solution didn’t come so i had another try, this time by editing the DB on my local system. What i did: downloaded old backup that i want to restore unzipped files with 7zip opened dump.sql with visual studio code foun…

This is a follow up of my earlier post here . I’m posting again so it easier to find for anyone else doing this in the future if it works. What i did to edit the DB on my laptop: downloaded old backup that i want to restore from the admin section unzipped files with 7zip opened dump.sql with visua…

I think perhaps the exact name of a backup file is important: forum name, date and timestamp, version identifier. So, if unpacking, modifying and repacking, I would suggest rebuilding to the same name as the original. But keep the original safe, of course.

I’ve combined the posts from the new topic into this one as it seems like keeping this issue grouped together in one place will make it much easier to follow for future travellers. :+1:

Thanks @Ed_S , i kept the original name as i’d read elsewhere that its important. My question above is about why the backup restore tool was looking for and not finding: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz which is the date i was doing the restore.

Ah, sorry. That does seem odd. It may be that the temporary directory is fully expected to be named according to today’s date, but it doesn’t look good that the sql dump file isn’t found. If you list the tar file contents do you see that filename in there? In my case root@ubuntu-2gb-nbg1-1:/var/d…

Thanks Ed, That file didn’t exist. Sorry for the delay, i’ve been off-grid for a bit. There isn’t a file with the correct name there so I just tried creating an empty file there manually: sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/ but every time i hit restore it look…

復元時に失敗しないように、重複キータグを削除するためにバックアップ内のデータベースを変更する

サポートインストール

pfaffman (Jay Pfaffman) 2023 年 8 月 30 日午前 10:21 29

直ったんですね！本当によかったです！

What's the cause of the 'unmet peer dependency' messages?

トピック		返信	表示
SQL Error during import Self-hosting	19	2345	2015 年 5 月 3 日
Can't restore due to corrupt indexes (with some clues on how to deal with corrupt indexes) Self-hosting	13	4751	2020 年 2 月 5 日
Problems while updating from 3.0.0 to 3.0.1 Self-hosting	16	1250	2023 年 6 月 14 日
Problem with restore Discourse from backup (3.4, quite large DB) Support	18	298	2025 年 1 月 14 日
Error restoring backup "key is duplicated" Self-hosting	8	1844	2017 年 8 月 31 日

復元時に失敗しないように、重複キータグを削除するためにバックアップ内のデータベースを変更する

関連トピック