# 복구 시 실패하지 않도록 백업 내부 데이터베이스에서 중복된 키 태그를 제거하는 방법

**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:** [7월 27, 2023, 12:25오후 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:** 22

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [8월 22, 2023, 8:09오후 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/22 "2023-08-22T20:09:30Z")

</div>

파일 경로와 관련이 있을 것 같습니다. 아래를 확인해 보세요.

> <https://github.com/discourse/discourse/blob/main/lib/backup_restore/backuper.rb#L218-L238>

음. 그게 문제가 아닐 수도 있겠네요. 저는 `7zip`이 호환되는 `tar` 파일을 생성하는 것을 별로 신뢰하지 않지만, 그게 비합리적인 생각일 수도 있습니다.

```plaintext
  -h, --dereference
              심볼릭 링크를 따릅니다. 링크가 가리키는 파일을 아카이브하고 덤프합니다.

```

> [@Drew-ART](#):
>
> 위에서 제가 질문한 내용은 백업 복구 도구가 다음 파일을 찾다가 찾지 못한 이유가 무엇인지를 묻는 것입니다: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

답은 위의 파일 안에 있을 수 있습니다. 사실, 같은 디렉토리의 다른 파일 안에 있을 가능성이 더 높습니다.

---

_[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)._