ONLYOFFICE Workspace에서 기본 저장 위치를 ​​변경하는 방법

간단히 말하자면 , ONLYOFFICE Workspace의 제어판에서 포털의 정적 데이터를 기본 로컬 디스크에서 지원되는 타사 스토리지 서비스로 이동할 수 있습니다. 현재 공식 관리 가이드에는 이 용도로 Amazon S3, Google Cloud Storage, Rackspace Cloud Storage 및 Selectel Cloud Storage가 나열되어 있습니다. 하지만 제어판에서 임의의 로컬 경로(예: .)를 입력할 수 있는 필드에 대한 설명은 없습니다 /mnt/storage.

이 가이드는 전체적으로 가상의 예시를 사용합니다. 노스스타 스튜디오(Northstar Studio)라는 소규모 디자인 에이전시를 가정해 보겠습니다. 자체 호스팅 ONLYOFFICE Workspace 서버의 로컬 디스크 공간이 업로드된 파일과 포털의 정적 데이터가 꾸준히 증가하면서 부족해지고 있습니다. 관리자는 Workspace 포털 자체는 같은 서버에 유지하면서 포털 스토리지를 Amazon S3 버킷으로 옮기려고 합니다. 노스스타 스튜디오는 단지 예시일 뿐이며, 실제 테스트나 고객 사례는 아닙니다.

설정을 변경하기 전에, 흔히 "기본 저장 위치 변경"이라고 불리는 두 가지 작업을 구분하는 것이 좋습니다. 첫 번째는 제어판에서 포털의 정적 데이터 저장 위치를 ​​로컬 디스크에서 지원되는 객체 스토리지 공급자로 변경하는 것입니다. 두 번째는 자체 호스팅 Docker 설치에서 사용하는 호스트 파일 시스템 디렉터리를 이동하는 것입니다. ONLYOFFICE에서는 이 두 가지를 서로 다른 계층으로 구분하여 설명하고 있으므로, 아래 단계에서는 먼저 제어판을 사용하는 방법을 설명한 후 로컬 디스크를 사용하는 경우를 별도로 설명합니다.

새로운 스토리지 제공업체를 선택하면 어떤 점이 달라지나요?

기본적으로 ONLYOFFICE Workspace는 Workspace가 설치된 컴퓨터의 로컬 디스크에 포털 데이터를 저장합니다. 공식 저장소 페이지에 따르면 연결된 타사 서비스를 정적 ​​포털 데이터에 사용할 수 있습니다. 새 공급자를 선택하고 연결하면 페이지가 새로 고쳐지고 데이터 마이그레이션 프로세스가 시작됩니다. 데이터 양에 따라 마이그레이션에 시간이 걸릴 수 있습니다.

따라서 Northstar Studio의 목표는 "모든 사용자가 향후 문서를 특정 폴더에 저장하도록 하는 것"이 ​​아니라 "포털의 ​​스토리지 백엔드를 기본 디스크에서 S3 버킷으로 이전하는 것"입니다. 이러한 차이가 중요한 이유는 사용자 폴더 구성, 문서 모듈 내의 연결된 타사 폴더, 백업 대상 및 관리자 수준의 스토리지 백엔드가 각각 별개의 기능이기 때문입니다.

공식 참조: ONLYOFFICE 도움말 센터: 타사 스토리지 연결 .

1단계: 저장소를 변경하기 전에 포털을 백업하십시오.

저장 위치를 ​​변경하면 마이그레이션이 시작되므로 먼저 복구 가능한 백업을 생성하십시오. ONLYOFFICE는 제어판에서 백업 및 복원 기능을 제공합니다. 백업은 배포 및 구성에 따라 임시 저장소, 문서 모듈, 컴퓨터 경로 또는 지원되는 타사 저장소에 저장할 수 있습니다.

가상의 Northstar Studio 서버를 예로 들면, 관리자는 스토리지 페이지를 건드리기 전에 새 백업을 생성하고 결과 아카이브가 저장된 위치를 확인해야 합니다. 이는 마이그레이션이 실패한다는 것을 보장하는 것이 아니라, 자격 증명, 버킷 정책, 네트워크 액세스 또는 기타 종속성에 문제가 있을 경우 관리자에게 복구 경로를 제공하는 것입니다.

공식 참조: ONLYOFFICE 고객 지원 센터: 제어판 백업 및 복원 .

2단계: 제어판을 열고 통합 상태를 확인합니다.

포털 관리 권한이 있는 계정으로 로그인하세요. 워크스페이스 시작 페이지에서 제어판을 열거나, 포털 설정에서 왼쪽 영역의 제어판 링크를 클릭하세요. 타사 서비스는 포털의 통합 섹션에서 먼저 연결해야 합니다. 그렇지 않으면 저장소 페이지에서 해당 서비스의 저장소 옵션이 비활성화됩니다.

Northstar Studio는 Amazon S3를 사용할 예정이므로 관리자는 먼저 Amazon S3가 타사 서비스로 구성되어 있는지 확인해야 합니다. Google Cloud Storage, Rackspace Cloud Storage 또는 Selectel Cloud Storage를 선택할 때도 동일한 전제 조건이 적용됩니다.

3단계: 일반 설정 → 저장소 열기

제어판에서 일반 설정 의 저장소 페이지 로 이동합니다 . 기본적으로 디스크 기본값이 선택되어 있습니다. 여기에서 포털의 정적 데이터를 저장할 지원되는 백엔드를 선택합니다.

서버의 로컬 디스크에만 데이터를 저장하려는 경우 클라우드 공급자를 선택하지 마십시오. 디스크 기본값이 로컬 저장소 옵션으로 유지됩니다. 로컬 데이터를 동일 서버의 다른 마운트 지점으로 이동해야 하는 경우 아래의 Docker 및 호스트 경로 관련 섹션으로 건너뛰십시오. 저장소 페이지는 일반적인 파일 시스템 경로 선택기가 아닙니다.

4단계: 공급자별 설정을 입력합니다.

사용할 공급자를 선택하고 필요한 연결 정보를 입력하세요. Amazon S3의 경우, 현재 ONLYOFFICE 문서에는 버킷 및 지역 필드 외에도 서비스 URL, 경로 스타일 강제 지정, HTTP 사용 여부 및 암호화 관련 설정과 같은 선택적 필드에 대한 설명이 있습니다. Google Cloud Storage는 버킷 이름을 사용하고, Rackspace와 Selectel은 자체 컨테이너 및 지역 필드를 사용합니다.

Northstar Studio 예시에서 관리자는 전용 S3 버킷과 올바른 AWS 리전을 입력합니다. 의도적으로 다른 엔드포인트가 필요한 경우가 아니면 서비스 URL은 변경하지 않고 그대로 둡니다. 자격 증명과 권한은 Workspace에 필요한 수준으로 제한해야 하며, 마이그레이션을 시작하기 전에 서버에서 스토리지 서비스로의 네트워크 액세스가 가능한지 확인해야 합니다.

연결 버튼을 클릭하기 전에 확인해야 할 실질적인 사항

• 버킷 또는 컨테이너가 예상 지역에 있는지 확인하십시오.
• 통합 자격 증명이 유효하고 필요한 객체 작업에 대해 권한이 부여되었는지 확인하십시오.
• 워크스페이스 서버가 공급자 엔드포인트에 연결할 수 있는지 확인하십시오.
• 마이그레이션 중인 데이터와는 별도로 최근 백업 파일을 보관하십시오.
• 포털 및 스토리지 서비스에서 오류나 예상치 못한 용량 사용량을 모니터링할 수 있는 기간에 변경 작업을 예약하십시오.

5단계: 스토리지를 연결하고 마이그레이션이 완료될 때까지 기다립니다.

[연결]을 클릭하세요 . ONLYOFFICE의 공식 안내에 따르면 페이지가 새로고침되고 데이터 마이그레이션 프로세스가 시작됩니다. 공급자가 승인되었다고 해서 변경이 완료된 것으로 간주하지 마세요. 새 스토리지가 선택된 상태로 스토리지 페이지가 다시 나타날 때까지 기다린 후 포털을 정상적으로 사용할 수 있는지 확인하세요.

Northstar Studio의 경우, 적절한 유효성 검사에는 기존 문서 몇 개를 열어보고, 새 파일을 업로드하고, 이미지나 기타 정적 콘텐츠를 미리 보고, S3 버킷에 새 객체가 있는지 확인하는 과정이 포함됩니다. 객체 레이아웃은 구현 세부 사항이며, 중요한 결과는 포털 콘텐츠가 정상적으로 작동하고 새 백엔드가 사용되고 있는지 확인하는 것입니다. 포털에서 오류가 발생하는 경우, 추가 변경을 진행하기 전에 자격 증명, 버킷 정책, 지역, 엔드포인트 연결 가능성 및 서버 로그를 조사해야 합니다.

다른 로컬 디스크나 마운트 지점을 사용하고 싶다면 어떻게 해야 할까요?

많은 "기본 저장 위치" 관련 튜토리얼이 오해를 불러일으키는 부분이 바로 이 지점입니다. 제어판의 디스크 기본 설정 옵션은 임의의 호스트 디렉터리를 선택할 수 있는 기능을 제공하지 않습니다. Docker 기반 Workspace 배포의 경우, ONLYOFFICE 자체 마이그레이션 문서에 따르면 포털 데이터는 /app/onlyoffice호스트의 특정 디렉터리에 저장됩니다. 또한, Docker 설치 설명서에서는 CommunityServer, DocumentServer, MailServer, ControlPanel 및 데이터베이스 관련 디렉터리와 같은 구성 요소 디렉터리를 해당 디렉터리 아래에 생성합니다.

호스트 측 디렉터리를 더 큰 디스크로 이동해야 하는 경우, 제어판 설정이 아닌 배포 마이그레이션으로 처리해야 합니다. 설치를 백업하고, 관련 컨테이너를 중지하고, 소유권과 권한을 유지하면서 데이터를 복사하고, 특정 배포에서 사용하는 호스트 측 바인드 마운트 또는 Docker Compose 볼륨 정의를 업데이트한 다음 스택을 다시 시작하십시오. 정확한 Compose 파일과 볼륨 매핑은 Workspace 설치 방식에 따라 다르므로 다른 배포에서 일반적인 명령을 복사하면 포털이 제대로 작동하지 않을 수 있습니다.

Docker Compose 설치의 경우, 현재 사용 중인 배포 파일을 공식 설치 가이드 (Docker Compose를 사용한 ONLYOFFICE Workspace Community 설치) 와 비교해 보세요 . 공식 Docker 기반 Workspace 레이아웃에서 사용하는 호스트 데이터 위치는 ONLYOFFICE Workspace Docker 마이그레이션 가이드를 참조하세요 .

포털 저장소 변경은 백업 저장소 변경과 어떻게 다른가요?

이 두 가지는 별개의 선택 사항입니다. 저장소 페이지에서는 지원되는 포털 정적 데이터가 저장되는 위치를 결정하고, 백업 페이지에서는 백업 아카이브가 기록되는 위치를 결정합니다. 예를 들어, 포털 데이터는 기본 디스크에 유지하면서 백업은 다른 위치에 기록하거나, 포털 정적 데이터는 S3로 이동하고 백업은 다른 위치에 저장할 수 있습니다. 복원력을 높이기 위해 백업을 기본 저장소 백엔드와 논리적으로 분리하여 관리하는 것이 복구 과정에서 더 용이합니다.

어떤 옵션이 당신의 상황에 가장 적합합니까?

최종 확인 체크리스트

• 원하는 공급자는 스토리지 페이지에서 선택됩니다.
• 이주 현상은 이제 막 시작된 ​​것이 아니라 이미 끝났습니다.
• 기존 파일은 정상적으로 열리고 다운로드됩니다.
• 새 업로드가 정상적으로 작동합니다.
• 사용자는 저장 공간 관련 오류 없이 포털에 계속 접속할 수 있습니다.
• 새로운 버킷 또는 컨테이너는 포털 사용과 일관된 활동을 보여줍니다.
• 최근 백업 파일이 여전히 사용 가능하며, 실수로 방금 이동한 데이터 세트 내에만 저장되지 않았습니다.

Northstar Studio 예시에서 스토리지 변경은 마이그레이션 후 포털이 정상적으로 작동하고 관리자가 선택한 S3 백엔드가 활성화되었음을 확인했을 때만 성공적으로 완료됩니다. 이러한 실질적인 정의는 '연결' 버튼 자체를 작업 완료의 증거로 간주하는 것보다 훨씬 유용합니다.