# 복원 후 아바타가 사라졌습니다. 어떻게 다시 가져올 수 있나요?
**URL:** https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223
**Category:** Support
**Created:** [4월 16, 2020, 10:43오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223 "2020-04-16T10:43:23Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 17, 2020, 2:59오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/21 "2020-04-17T14:59:37Z")
원래 서버를 몇 시간 동안 종료할 수 없기 때문에, 모든 것이 정상적으로 작동하는지 테스트한 후 서버를 교체할 때까지 이름을 변경했습니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [4월 17, 2020, 3:00오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/22 "2020-04-17T15:00:57Z")
그렇게 할 필요가 없습니다. 와일드카드 인증서를 보유하고 있다면, 로컬 DNS를 호스트 파일(HOSTS)을 통해 변경하여 모든 설정을 구성하고 백업 자체를 복원할 수 있습니다.
그 후 공개 DNS를 전환하기만 하면 됩니다.
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 17, 2020, 3:07오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/23 "2020-04-17T15:07:07Z")
말씀하신 내용을 잘 이해하지 못하겠습니다.
테스트를 진행하는 동안 a.domain.com이 계속 가동되도록 유지해야 합니다.
그리고 복원 중인 사본의 Discourse 인터페이스에 접근하여 모든 것이 정상인지 확인해야 합니다.
따라서 다른 서버에서 사본에 접근하기 위해 별도의 URL이 필요합니다.
그래서 복원 후 Discourse와 nginx에서 호스트 이름만 간단히 변경합니다.
모든 것이 정상임을 확인하면 새 서버의 이름을 a.domain.com으로 변경하고, 구 서버를 종료한 뒤 DNS에서 a.domain.com을 새 서버로 지정합니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [4월 17, 2020, 3:37오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/24 "2020-04-17T15:37:27Z")
> [@ariznaf](#):
>
> 그래서 다른 서버에서 복사본에 액세스하려면 다른 URL이 필요합니다.
위 내용은 정확하지 않습니다. 로컬 컴퓨터의 HOSTS 파일을 수정하거나 로컬 DNS에 항목을 하드코딩하여 로컬 머신이 동일한 DNS 이름으로 새 서버에 연결하도록 강제할 수 있습니다.
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 17, 2020, 4:16오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/25 "2020-04-17T16:16:59Z")
로컬 머신이 없습니다.
두 대의 서버 모두 인터넷 또는 클라우드 서버에 있습니다.
저는 Windows 머신에서 ssh를 사용합니다.
로컬 호스트 이름을 변경하여 해당 머신의 IP를 설정할 수는 있겠지만, 서버에서 이름을 변경하는 것보다 훨씬 복잡합니다.
호스트 이름 변경이 문제일 수 있다고 생각하시나요?
문제가 되어서는 안 될 것 같은데요…
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 2:37오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/26 "2020-04-18T02:37:46Z")
> [@ariznaf](#):
>
> Riking은 시스템이 미니멀 이미지를 다시 구축해야 한다고 말합니다. 하지만 작업은 완료된 것처럼 보였습니다.
@ariznaf,
네, `sidekiq` 프로세스가 부수적인 아바타와 프로필 이미지를 다시 구축할 충분한 시간이 있었음에도 불구하고, 이 사용자 지정 아바타 문제가 다시 발생하기 시작했습니다. 다만 `nginx reverse proxy to a unix domain socket` 구성에서만 해당됩니다.
작은 아이콘 아바타는 정상적으로 표시됩니다. 하지만 프로필 카드나 프로필 페이지에서는 작동하지 않습니다(이전에 캐시되어 있었고 캐시가 만료되지 않은 경우를 제외하고).
다음과 같이 실행하는 즉시:
```plaintext
nginx -s stop; ./launcher start web-only
```
사용자 지정 아바타 이미지 문제가 사라집니다(브라우저에서 이전에 표시되지 않았거나 캐시되지 않은 이미지에 대해).
그리고 이 작업을 실행한 직후:
```plaintext
./launcher stop web-only; nginx
```
아직 표시되지 않았거나 캐시되지 않은 이미지에 대해 사용자 지정 아바타 이미지 문제가 다시 발생합니다.
HTTPS와 관련된 오류는 없으며, 이는 force\_https 때문이 아닙니다(완전히 무관):
```plaintext
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
```
모바일(ios, 최신 버전), 데스크톱, chrome(최신), safari(최신) 등에서 이 문제를 확인했습니다.
nginx를 unix 소켓으로 리버스 프록시로 사용할 때 사용자 지정 아바타 이미지에 영향을 미치는 이상한 일이 일어나고 있습니다.
지금까지 @ariznaf 님께 죄송합니다만, 문제를 분리할 수 없으며 해결책도 없습니다.
`nginx reverse proxy to a unix socket` 구성에서, `discourse app` (컨테이너)가 nginx를 unix 도메인 소켓으로 리버스 프록시로 사용하지 않는 구성에서처럼 이 사용자 지정 아바타 이미지를 다시 구축하지 않는 것 같습니다.
아마도 `sidekiq`가 `nginx reverse proxy to unix socket` 구성을 좋아하지 않아 이 재구축 프로세스를 예약하거나 실행하는 것을 거부하는 것일까요, 하하? @riking ?
이상하네요.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 3:51오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/27 "2020-04-18T03:51:14Z")
@riking
후속 질문입니다:
우리가 논의 중인 유닉스 소켓을 사용하는 리버스 프록시 설정에서:
그러나 `force_https`를 확인해 보면:
```plaintext
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
```
물론, 예상대로 브라우저 인증서에 오류가 없습니다(크롬은 문제없음):
따라서, 제 `무지한` 추측은 이 설정에서 `force_http` 설정/메서드에 이러한 이미지들이 빠져 있다는 것입니다. 왜냐하면 이 커스텀 아바타(그리고 프로필 페이지 이미지)를 제외하고는 모든 것이 완벽하기 때문입니다.
이것은 제 `디스커스에 대한 전문 지식을 넘어선` 추측입니다.
* * *
* * *
업데이트:
추가 조사를 해본 결과, 우리의 `nginx 리버스 프록시 to 유닉스 소켓` 설정들이 `/shared/uploads`(파일)의 대부분을 누락하고 있었던 것으로 드러났습니다. 이 단계는 이 주제에 대해 읽은 다양한 튜토리얼 및 howto 문서에서 빠져 있었으므로, 다음에 메타에서 이 주제에 대한 위키를 보면 이 단계를 포함하도록 튜토리얼/위키/howto를 업데이트할 것입니다.
남은 유일한 작은 함정은 favicon 문제입니다:
이 문제를 해결하는 권장 방법이 있는 분이 있다면 알려주시면 좋겠습니다. 감사합니다!
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [4월 18, 2020, 6:12오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/28 "2020-04-18T06:12:32Z")
다시 업로드하세요. 그게 가장 빠른 해결책입니다.
소켓을 사용할 때 HTTPS 템플릿을 비활성화했다는 사실을 잊곤 합니다. 그래서 `force_https`를 수동으로 활성화하지 않는 한 Discourse가 SSL 뒤에 있는지 알 수 없으며, 이것이 제가 어제 그 해결책을 제안한 이유입니다.
`force_https`를 활성화한 후에는 에셋을 다시 업로드하여 경로를 수정할 수 있습니다.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [4월 18, 2020, 6:40오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/29 "2020-04-18T06:40:18Z")
> [@neounix](#):
>
> 더 조사해 본 결과, 우리 `nginx reverse proxy to unix socket` 설정에서 `/shared/uploads`(파일)의 상당 부분이 누락되어 있었습니다. 이 부분은 이 주제에 대해 읽은 여러 튜토리얼과 howto 문서에 빠져 있었는데, 다음에 메타에서 이 주제에 관한 위키를 보게 되면 이 단계를 포함하도록 튜토리얼/위키/howto를 업데이트하겠습니다.
이런 것들에 답장을 하지 않은 이유는, 내장 백업 기능을 사용하지 않은 서버 데이터 전송 과정에서 문제가 생겨 /uploads/ 디렉터리 전체가 누락된 것으로 추측했기 때문입니다. 그리고 그걸 여러분이 이해할 수 있는 방식으로 설명하는 법을 전혀 몰랐습니다.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 7:03오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/30 "2020-04-18T07:03:02Z")
> [@riking](#):
>
> 이 모든 것에 답장을 하지 않은 이유는, 내장 백업 기능을 사용하지 않은 상태에서 서버 데이터 전송이 제대로 되지 않아서 `/uploads/` 디렉터리가 완전히 누락된 것이라고 가정했기 때문이고, 그것을 여러분이 이해할 수 있는 방식으로 설명하는 방법을 전혀 몰랐기 때문입니다.
네… 우리는 nginx 리버스 프록시를 설정하기 위해 이 가이드를 따랐지만, 이것은 스탠드얼론(독립형) 설정을 위한 것이었고, 스탠드얼론 모드에서는 전송이 필요하지 않았기 때문에 업로드에 대해 언급하지 않았습니다:
> [@Add an offline page to display when Discourse is rebuilding or starting up](https://meta.discourse.org/t/adding-an-offline-page-when-rebuilding/45238):
>
> warning This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will lose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution! When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser… …or a not-so-nice 502 error message from Nginx: If you’re a perfectionist …
그리고 컨테이너 두 개를 위한 가이드도 따랐는데, 이 가이드에서도 DB 복원이나 업로드 디렉터리 전송에 대해 언급하지 않았습니다:
> [@Move from standalone container to separate web and data containers](https://meta.discourse.org/t/how-to-move-from-standalone-container-to-separate-web-and-data-containers/29413):
>
> warning This is an advanced setup. Don’t follow this unless you are experienced with Linux server administration and Docker. You also need to pay close attention to commits to discourse\_docker to make sure you notice if there’s a version bump for postgres or redis. Converting your Current Setup I managed to migrate to two containers. If anyone else needs instructions, this is how it worked for me. The process includes backup, setting up separate web and data containers and restore data. …
우리는 쉽게 이해할 수 있다고 생각합니다. 참고로, 설명을 돕기 위해 여러분이 놓치고 있던 단서를 여기에 제시합니다:
**이 구성에 대한 주요 튜토리얼들은 DB 복원을 하거나, 또는 업로드를 새 컨테이너로 수동으로 전송해야 한다는 사실을 누락하고 있습니다. (우리가 그 내용을 포함하지 않았기 때문입니다.)**
_물론, 튜토리얼에 그런 내용이 없어서 우리가 100% 혼자서 이 문제를 해결해 낸 후에는 이제 모든 것이 이해가 됩니다. LOL_
**문제를 알면 모든 것이 쉽습니다.**
🙂 🙂 🙂
P.S. 마무리로. 다양한 튜토리얼을 작성해 주신 모든 분들께 감사드립니다. 큰 도움이 되었습니다. 진심으로 감사드립니다. 우리 쪽에서는 이 구성이 완료되었고, 향후 더 이상 어떤 Discourse 사이트에서도 스탠드얼론 구성을 사용하지 않을 것입니다. 우리의 기본 "기본값"은 리버스 프록시를 통해 유닉스 소켓으로 연결된 두 개의 컨테이너가 될 것입니다. 이것은 업데이트를 하거나 실시간으로 컨테이너를 전환할 때 거의 제로 다운타임으로 작동하는 가장 좋은 방법입니다. 훌륭합니다!!
**Discourse는 훌륭합니다!!**
**훌륭한 작업이었습니다, Jeff @codinghorror님과 Sam @sam님! 브라보!**
❤ ❤
@ariznaf 님…
이것을 작동시키는 것은 비교적 쉽지만, 앞서 언급했듯이 우리는 S3나 다른 클라우드 저장소 서비스를 사용하지 않고, 모든 것을 “단순하게” 유지하는 것을 선호합니다. 그래서 우리의 백업은 단순히 `rsync`를 통해 오프사이트 저장소로 동기화됩니다. 우리는 이 방식을 선호합니다… 디버깅해야 할 일이 하나 줄어드니까 🙂 그리고 S3 없이도 “살아갈” 수 있으니까요,
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [4월 18, 2020, 9:17오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/31 "2020-04-18T09:17:47Z")
이것이 도움이 될지 확신은 없습니다. 하지만 이미지 최적화 작업이 인터넷 도메인 이름을 통해 서버에 도달하지 못할 경우, 최적화 작업이 실패하는 경향이 있습니다.
더 복잡한 리버스 프록시 설정에서 예상대로 작동하지 않는 이유를 설명할 수 있는 부분입니다.
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 18, 2020, 9:42오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/32 "2020-04-18T09:42:13Z")
Kane님, 감사합니다.
(아마도 아시다시피) 저는 Discourse에서 UI를 통한 표준 백업 방법의 대안을 시도하고 있었습니다. 표준 백업 방법으로 복원할 때마다 문제가 발생했고, 이 사이트의 공식 튜토리얼에 제시된 지침을 항상 따랐음에도 불구하고 그랬기 때문에 다른 방법을 시도하게 된 것입니다.
어쨌든, 저는 처음부터 UI 인터페이스와 표준 백업 절차, 그리고 권장되는 복원 절차를 사용하여 백업에서 복원하고 있다고 명시했습니다.
스탠드얼론 Discourse의 표준 설치 환경과의 유일한 차이는 nginx를 리버스 프록시로 사용하고 있으며, 이는 소켓을 통해 Discourse에 연결되어 있다는 점입니다.
우리가 발견한 주요 문제는 아바타였습니다. 아바타가 apparently 사라졌고, 흰색 프로필 이미지로 대체되어 있었습니다.
Kane님은 sidekiq 작업을 통해 재빌드해야 한다고 말씀하셨습니다. 하지만 그 작업을 실행하면 성공(OK 상태)과 함께 즉시 종료되는 것처럼 보이지만, 아바타는 여전히 그대로였습니다.
백업은 우리에게 매우 중요합니다(누가 백업을 무시할 수 있겠습니까?). 따라서 저는 더 많은 테스트를 수행할 것이며, 지침을 매우 주의 깊게 따르고, 여기에 제시된 다른 아이디어들을 시도해 볼 것입니다.
우리는 Discourse에 만족하며, 그것을 매우 좋아합니다. 단지 우리는 어떤 종류의 공격(최근에 한 번 겪었습니다)이나 서버 장애가 발생할 경우를 대비하여 견고한 복원 절차를 갖추고 있는지 확인하려고 할 뿐입니다.
이 문제를 해결하기 위해 테스트를 수행하거나 정보를 제공하기를 원하신다면, 최선을 다해 그 정보를 제공하겠습니다.
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 18, 2020, 9:52오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/33 "2020-04-18T09:52:05Z")
시스템이 아바타 섬네일에 접근하지 못하는 것 같습니다. 이 부분은 확실합니다.
하지만 포럼의 나머지 부분은 정상적으로 제공되고 있습니다. 라우팅, SSL, 기타 설정들도 제가 볼 수 있는 범위에서는 모두 올바르게 구성되어 있습니다.
만약 어떤 종류의 설정 오류가 있었다면 디스커스 포럼에 접속하여 나머지 콘텐츠를 볼 수 없었을 것입니다. 502 오류나 비슷한 오류가 발생했을 것입니다.
@neounix
UI를 통해 가장 간단한 방법으로 오프사이트 백업을 유지할 수 있기 때문에 S3를 사용하고 있습니다.
S3가 최선의 옵션은 아닐 수도 있고, 저는 잘 모르지만, 어쨌든 백업이 저장되는 위치는 이 문제와 무관합니다. 백업에 접근하지 못하거나 복구를 수행하지 못하는 문제가 아니기 때문입니다.
복구는 정상적으로 수행되고 있습니다.
@stephan
app.yml 파일에서 ssl 템플릿과 letsencrypt 템플릿, 그리고 포트가 포함된 expose 섹션을 주석 처리해 두었습니다.
SSL 부분은 nginx에서 처리하고 있으므로, 소켓을 암호화할 필요가 없는 것이 맞나요?
이것이 잘못된 것인가요? 그럼에도 불구하고 ssl 템플릿을 사용해야 하나요?
이것이 문제였다면 복구 후 포럼의 어떤 부분도 볼 수 없었을 것입니다. 아바타뿐만 아니라요. 하지만谁知道呢…
추가 테스트를 수행하겠습니다. 도움을 주셔서 모두 감사합니다.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 9:59오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/34 "2020-04-18T09:59:06Z")
> [@ariznaf](#):
>
> S3이 최선의 선택이 아닐 수도 있습니다. 모르겠지만, 어쨌든 백업이 어디에 저장되어 있는지는 이 문제와 무관합니다. 백업에 접근하지 못하거나 복구를 하지 못해서 발생하는 문제가 아니기 때문입니다.
> 복구는 올바르게 수행되었습니다.
@ariznaf … 안녕!
저는 두 대의 서로 다른 서버에서 이 문제를 해결하기 위해 원래 설정에서 `/shared/uploads` 디렉토리를 `socket-only` 설정으로 수동으로 복사했습니다. 그 이후로 이 문제가 사라졌습니다.
저는 다음과 같은 방법으로 빠르게 확인할 수 있었습니다. 단순히 `uploads` 디렉토리의 크기를 비교한 것입니다. (공유 디렉토리에 있는 것을 전제로 합니다):
```plaintext
du -sh uploads
```
크기를 비교했을 때 비로소 문제의 원인을 알게 되었습니다 🙂
혹시 당신도 확인해 볼 수 있을까요? 이 방법이 문제를 격리하는 데 도움이 되기를 바랍니다.
PS: _S3에 대해 부정적인 태도를 취하는 것은 아닙니다. 말 그대로 각자 취향이 다르다는 뜻이죠…_
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 18, 2020, 10:11오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/35 "2020-04-18T10:11:38Z")
제가 당신을 올바르게 이해하고 있는지 확인해 보겠습니다.
백업을 생성할 때 업로드 파일도 함께 저장하도록 체크했습니다. (썸네일은 제외했지만, 썸네일도 저장하도록 테스트해 보았습니다. 이제 썸네일도 함께 저장하고 있으므로 다시 생성을 기다릴 필요가 없습니다.)
복원 후 업로드 파일도 함께 복원됩니다.
업로드 파일의 복원이 제대로 이루어지지 않아 수동으로 처리해야 한다는 말씀이신가요?
업로드 파일을 수동으로 복원하는 방법은 무엇인가요?
백업을 다운로드한 후 shared/standalone/uploads를 압축 해제하신 건가요?
만약 그렇다면 (저도 시도해 보겠습니다) 복원 작업에 어떤 종류의 버그가 있는 것 같다는 결론이 자연스럽게 나옵니다.
감사합니다.
백업을 생성하고 저장하는 대안을 찾고 있지만, discourse 커뮤니티 사람들은 표준 백업 기능만이 유일한 올바른 방법이라고 주장하고 있습니다.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 10:23오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/36 "2020-04-18T10:23:08Z")
> [@ariznaf](#):
>
> 백업 및 저장을 위한 대안을 찾고 있지만, 디스코urs(Disourse) 커뮤니티의 사람들은 유일한 올바른 방법은 표준 백업을 사용하는 것이라고 주장합니다.
@ariznaf님, 안녕하세요.
저희는 관리자 UI에서 복원하지 않습니다(웹 인터페이스에서는 백업만 수행하고 복원은 하지 않음). `sftp`를 사용하여 파일(업로드 포함)을 컨테이너로 전송한 후 다음과 같이 복원합니다:
```plaintext
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
```
그러나 며칠 전 새로운 `nginx 리버스 프록시 to unix 소켓` 구성을 만들었을 때, 데이터베이스가 이미 `data` 컨테이너에 있었기 때문에(해당 howto 토픽에서 언급된 바와 같이) DB에서 복원하지 않았습니다.
이 때문에 업로드 파일을 새 컨테이너로 수동으로 복사해야 했습니다.
귀하의 상황은 저희의 경우와 달라 보입니다.
도움이 되셨으면 좋겠습니다.
---
### Author:  [@ariznaf](https://meta.discourse.org/u/ariznaf)
#### Post date: [4월 18, 2020, 10:27오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/37 "2020-04-18T10:27:05Z")
감사합니다.
인터페이스를 통해 수행하는 동일한 작업을 명령줄을 통해 수행하고 있는 것으로 보입니다: 복원을 활성화하고, 데이터베이스와 업로드가 포함된 tgz 파일에서 복원하는 것이죠.
그런데 아바타가 작동하도록 하려면(소켓과 nginx 리버스 프록시를 사용하여) 업로드만 두 번째로 복원해야 한다는 말씀이시죠? 맞습니까?
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [4월 18, 2020, 10:33오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/38 "2020-04-18T10:33:26Z")
> [@ariznaf](#):
>
> 하지만 아바타를 작동시키려면(소켓과 nginx 리버스 프록시 사용) 업로드만 두 번째로 복원해야 한다고 하셨는데, 맞나요?
@ariznaf 님… 정확히 말하면 아닙니다…
처음에는 독립형 애플리케이션이 하나 있었습니다. 그 애플리케이션을 두 개의 서로 다른 컨테이너(데이터 전용과 웹 전용)로 분리한 뒤, 업로드가 포함된 큰 백업 파일에서 복원을 수행했습니다.
모든 과정이 잘 진행되었습니다…
그 후, 새로운 컨테이너인 `socket-only`를 생성하고 리버스 프록시를 사용하도록 설정했습니다.
새로운 `socket-only` 컨테이너에서는 복원을 수행하지 않았습니다(데이터 컨테이너에 이미 DB 데이터가 안전하게 존재했기 때문이었죠). 하지만 업로드를 수동으로 복사하는 것을 놓쳤습니다(이것이 제 실수였습니다). 일반적인 복원 프로세스를 수행했다면 그 작업은 필요 없었을 것입니다.
그러나 새로운 컨테이너에서 수동으로 DB 복원을 다시 할 이유는 없습니다. 데이터가 그 작은 컨테이너 안에 안전하게 보관되어 있는 것이 바로 그 컨테이너를 사용하는 이유이기 때문입니다. 따라서 이 상황에서는 업로드를 새로운 컨테이너로 복사해야 합니다. 실제로는 꽤 깔끔하게 처리됩니다.
도움이 되셨나요?
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [4월 18, 2020, 10:37오전 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/39 "2020-04-18T10:37:27Z")
> [@ariznaf](#):
>
> 어떤 설정 오류가 있었다면 discourse 포럼에 접속할 수 없고 나머지 콘텐츠도 볼 수 없었을 것입니다.
제가 말한 것이 아닙니다. 백엔드가 프론트 엔드 nginx를 통해 자기 자신을 도달할 수 없다는 것이었습니다. 말씀하시는 내용은 그 반대입니다.
업로드를 최적화하기 위해, Sidekiq 작업은 http(s)를 사용하여 이를 가져옵니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [4월 18, 2020, 1:59오후 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/40 "2020-04-18T13:59:37Z")
아니요, SSL 템플릿은 비활성화할 수 있지만 force\_https를 수동으로 활성화해야 합니다.
[이전 페이지](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223.md?page=1)
[다음 페이지](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223.md?page=3)