# Модификация базы данных внутри резервной копии для удаления дублирующегося тега ключа, чтобы избежать сбоя при восстановлении

**URL:** https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039
**Category:** Self-hosting
**Created:** [27.Июль.2023 12:25:26 UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039 "2023-07-27T12:25:26Z")
**Posts on this page:** 1
**Showing post:** 13

<div class="post-metadata">

### Author: ![Drew-ART](https://avatars.discourse-cdn.com/v4/letter/d/8edcca/32.png) [@Drew-ART](https://meta.discourse.org/u/Drew-ART)
#### Post date: [08.Август.2023 16:04:46 UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/13 "2023-08-08T16:04:46Z")

</div>

Небольшое обновление. На прошлой неделе над этим работал кто-то другой из моей команды, но решение так и не нашлось, поэтому я попробовал ещё раз, на этот раз отредактировав базу данных на своей локальной системе.

Что я сделал:

1. Загрузил старую резервную копию, которую хочу восстановить.
2. Распаковал файлы с помощью 7-Zip.
3. Открыл dump.sql в Visual Studio Code.
4. Нашёл дублирующиеся теги непосредственно в базе данных.
5. Нашёл, по-видимому, список тегов, выполнив поиск с использованием кавычек вокруг тега. В моём случае это ‘socialmedia’. Теги выглядят как второй и третий снизу среди найденных вхождений.

 ![image](https://global.discourse-cdn.com/meta/original/4X/3/c/7/3c70d41a760e364a0e412ff3d9a8167819a27f6e.png)

1. Изменил одно из вхождений на:

> 132 ‘socialmedia2’:1A socialmedia2 en\_GB 3

1. Снова упаковал файл dump.sql с помощью 7-Zip:

- Добавить в архив
- Формат архива: .gzip

1. Снова упаковал основной файл резервной копии:

- Добавить в архив
- Формат архива: .tar (gzip пока недоступен)

1. Теперь у вас должен появиться заархивированный исправленный файл резервной копии .tar

2. Упакуйте файл .tar с помощью 7-Zip, чтобы создать файл .tar.gz, соответствующий формату, используемому в Discourse:

- Добавить в архив
- Формат архива: .gzip

1. Загрузите файл в раздел резервных копий и восстановите его через административную панель.

На этом этапе я столкнулся с сообщением об ошибке:

> Извлечение файла дампа…  
> [2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb\_check\_realpath\_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Есть ли у кого-нибудь идеи, что я упустил в описанном выше процессе?

Единственное, что приходит мне в голову, — это то, что путь, который система ищет, использует сегодняшнюю дату, а не дату резервной копии (я пишу это 08-08-2023).

---

_[View the full topic](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039)._