ownCloud 10 Classic에서 ownCloud Infinite Scale로 마이그레이션하는 방법

예시 시나리오: 가상의 디자인 회사인 Cedar Studio(직원 32명)가 ownCloud Classic 10을 사용하고 있다고 가정해 보겠습니다. 이 회사는 LDAP 디렉터리, 개인 파일 영역, 그룹 공유, 공용 링크 및 외부 프로젝트 저장소 마운트를 사용하고 있습니다. Cedar Studio는 새 서버를 설치하더라도 기존 데이터나 권한이 그대로 이전되지 않을 것이라는 전제 하에 ownCloud Infinite Scale(oCIS)로 마이그레이션하려고 합니다. 이 예시는 가상의 시나리오이며, 실제 마이그레이션 완료 사례를 다루는 것은 아닙니다.

migrate-to-ocisownCloud에서 지원하는 마이그레이션 경로는 클래식 서버의 앱과 명령어를 사용하는 가이드 마이그레이션입니다 occ. 이는 클래식 데이터베이스 또는 데이터 디렉터리를 제자리에서 업그레이드하는 것이 아니라, 별도의 깨끗한 oCIS 대상 서버로 단계적으로 전송하는 방식입니다. 마이그레이션 설명서에는 대부분의 과정에서 소스 서버가 계속 작동한다고 명시되어 있지만, 지속적인 동기화나 다운타임 없는 최종 델타 패스에 대한 설명은 없습니다. 운영 환경에 사용하기 전에 ownCloud 지원팀과 협의하여 제어된 전환 계획을 수립하고 소스 서버 버전 호환성 및 최종 쓰기 동결 절차를 확인하십시오.

아래 단계는 2026년 10월 6일에 제공된 ownCloud Server 11.0 마이그레이션 가이드 및 Infinite Scale 8.2 인증 및 백업 관련 공식 문서를 따릅니다. 명령 구문, 환경 변수 및 지원 방식은 변경될 수 있으므로 설치된 버전의 문서를 참조하여 확인하십시오.

1단계: 클래식 인스턴스를 인벤토리화하고 "마이그레이션됨"의 의미를 정의합니다.

Cedar Studio의 경우, 첫 번째 작업은 사용자, 그룹, 활성화 및 비활성화된 계정, 공유 폴더, 링크 공유, 외부 마운트, 그리고 LDAP에 존재하지 않는 모든 로컬 사용자를 목록화하는 것입니다. 각 항목에 의존하는 팀을 기록해야 합니다. 이렇게 하면 개인 파일 전송이 성공했다고 해서 모든 기존 워크플로가 이전되었다고 잘못 판단하는 것을 방지할 수 있습니다.

마이그레이션 가이드에 따르면, 이 마이그레이션을 통해 활성화된 사용자와 멤버십이 있는 그룹, 각 활성화된 사용자의 홈 디렉터리 파일, 그리고 사용자, 그룹 및 링크 공유를 전송할 수 있습니다. 파일은 oCIS의 각 사용자 개인 공간에 저장됩니다. 비활성화된 사용자와 해당 파일은 마이그레이션 대상에서 제외됩니다. 이 과정에서 암호나 외부 마운트는 마이그레이션되지 않습니다. 외부 마운트 및 수신된 공유 폴더에 있는 데이터는 개인 파일 전송에서 제외되므로 별도로 처리해야 합니다. 해당 위치를 목록화하고 수동으로 마이그레이션 담당자를 지정하십시오.

암호가 없는 공개 링크 사용 여부도 기록하십시오. oCIS는 기본적으로 공개 링크에 암호를 요구합니다. 이러한 기존 링크는 대상 정책을 변경하지 않으면 마이그레이션이 실패할 수 있습니다. 기존 URL을 유지하기 위해 해당 정책을 완화하지 마십시오. 링크 소유자가 암호로 보호되는 새 링크를 생성해야 하는지 여부를 결정하십시오. 마이그레이션된 암호 보호 링크의 암호는 이전 암호와 일치하지 않으므로 사용자는 전환 후 암호를 재설정해야 합니다.

2단계: 깨끗한 oCIS 대상과 마이그레이션 연결을 준비합니다.

운영 데이터를 전송하기 전에 별도의 oCIS 인스턴스를 구축하고 테스트하십시오. 마이그레이션 가이드에서는 두 시스템 모두 실행 중이고 서로 접근 가능해야 한다고 명시하고 있습니다. 또한 대상 시스템은 새롭고 깨끗한 상태여야 합니다. 기존 사용자나 데이터가 가져온 콘텐츠와 충돌할 수 있기 때문입니다. 현재 Classic 인스턴스를 백업하고 사용자가 새 서비스를 수락할 때까지 해당 인스턴스를 계속 사용할 수 있도록 롤백 계획을 준비하십시오.

마이그레이션을 위해서는 기존 서버에 ownCloud에서 제공하는 앱이 설치되어 있어야 합니다. 이 앱은 안내에 따라 마이그레이션을 진행하는 과정에서 제공되며, 문서에는 관리자가 ownCloud 지원팀에 문의하여 앱을 받도록 안내되어 있습니다. 앱에는 자체 rclone 바이너리가 포함되어 있습니다. 이 앱의 문서화된 마이그레이션 프로세스 대신 임의의 마켓플레이스 패키지나 관련 없는 파일 복사 작업을 사용하지 마십시오.

oCIS 측에서는 auth-app서비스 및 애플리케이션 인증 설정을 활성화하십시오. 마이그레이션 가이드에서는 oCIS 관리자를 위한 가장(impersonation) 활성화 및 앱 토큰 생성도 요구합니다. Infinite Scale 8.2 auth-app 문서에서는 가장 기능은 마이그레이션을 위한 것이며 프로덕션 환경에서는 활성화된 상태로 유지해서는 안 된다고 명시적으로 밝히고 있습니다. 가장 기능은 임시 마이그레이션 설정으로 간주하여 토큰을 보호하고, 접근 권한을 제한하며, 마이그레이션 작업이 완료되면 마이그레이션 전용 가장 기능을 비활성화하십시오. 분산 배포 환경에서는 문서에 명시된 대로 해당 서비스에 설정을 적용하십시오.

가상의 Cedar Studio 환경에서 oCIS 대상은 기존 서버에서 사용하는 것과 동일한 LDAP 서비스를 사용하여 테스트해야 합니다. 자격 증명은 셸 기록이나 공유 런북에 붙여넣는 대신 배포의 비밀 메커니즘에 보관하십시오. ownCloud 공식 마이그레이션 가이드 에는 대상 요구 사항과 마이그레이션 앱에 대한 ownCloud 지원 정보가 나와 있습니다. oCIS 8.2 인증 앱 가이드에서는 앱 토큰과 가장에 대해 설명합니다.

3단계: ID 매핑을 일관성 있게 만든 다음 준비 상태 검사를 실행합니다.

oCIS는 파일과 공유 폴더를 마이그레이션하기 전에 사용자와 그룹을 확인할 수 있어야 합니다. Cedar Studio는 이미 LDAP를 사용하고 있으므로 관리자는 oCIS를 동일한 디렉터리에 연결하고 사용자가 로그인할 수 있는지 확인하고 식별자가 의도한 계정에 매핑되는지 확인해야 합니다. ownCloud 가이드에서는 활성화된 모든 클래식 사용자에 대해 고유하고 유효한 이메일 주소를 제시합니다. LDAP 기반 클래식 사용자의 경우, 일반적으로 uid또는 samAccountName와 같은 사용자 이름 속성과 해당 oCIS LDAP 스키마 설정도 제시합니다. 속성을 실제 디렉터리와 일치시켜야 하며, 샘플 값을 그대로 복사해서는 안 됩니다.

Classic에서 로컬 계정을 사용하지만 oCIS에서 외부 LDAP 디렉터리를 사용하는 경우, 파일 전송 전에 해당 디렉터리에 일치하는 사용자 및 그룹을 생성하거나 마이그레이션해야 합니다. 사용자 및 그룹 이름은 반드시 일치해야 합니다. oCIS의 내장 IDM은 소규모 환경 또는 테스트를 위한 제한적인 임베디드 디렉터리이므로, ownCloud는 프로덕션 환경에서 실제 LDAP 또는 외부 ID 관리 시스템 사용을 권장합니다. 공식 마이그레이션 절차는 하나의 마이그레이션 분기에서 로컬 사용자와 LDAP 기반 Classic 사용자가 혼합된 구성을 지원하지 않습니다. 마이그레이션 도중에 임의로 처리하기보다는 지원을 통해 해당 아키텍처 문제를 해결하십시오.

마이그레이션 앱이 클래식 시스템에 설치 및 활성화되면, 문서에 설명된 경로와 서비스 계정을 사용자의 설치 환경에 맞게 조정하십시오. 이 가이드에서는 /var/www/owncloud와 를 www-data예시로 사용합니다.

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

검증 명령은 활성화된 사용자의 이메일 주소가 유효하고 중복되지 않는지 확인합니다. 검증을 건너뛰기 전에 보고된 문제를 해결하십시오. 비활성화된 사용자를 이동해야 하는 경우, 계정을 검토하고 검증 전에 클래식 환경에서 해당 사용자를 활성화한 다음 마이그레이션 계획에 포함하십시오. Cedar Studio는 데이터 전송을 시작하기 전에 여러 대표 사용자를 사용하여 oCIS에 대한 LDAP 로그인도 확인해야 합니다.

4단계: 사용자 및 그룹 분기를 완료한 다음 파일과 공유를 마이그레이션합니다.

공식 가이드에서 사용자의 ID 설정에 맞는 분기를 따르십시오. 클래식 사용자가 로컬 사용자이고 oCIS에 내장된 IDM을 사용하는 경우, 가이드의 순서에는 사용자 마이그레이션, oCIS 역할 할당, 그룹 마이그레이션이 포함됩니다. 마이그레이션된 사용자에게는 하나의 역할이 할당됩니다. 클래식 역할은 일대일로 유지되지 않으며, 클래식 하위 관리자 권한에는 oCIS에서 상응하는 역할이 없습니다. 관리자 액세스 권한을 수동으로 검토하십시오. 두 시스템이 동일한 LDAP 디렉터리를 사용하는 경우, 사용자와 그룹이 이미 oCIS에서 사용 가능한지 확인하고 중복 생성을 피하고 LDAP 분기를 따르십시오.

사용자, 그룹 및 역할 설정이 완료되면, 문서화된 파일 및 공유 명령은 oCIS 관리자 사용자 이름을 마지막 인수로 사용합니다. 기존 관리자 암호는 대화형으로 입력하라는 메시지가 표시됩니다.

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

마이그레이션 절차에 설명된 대로 공유 폴더 전송 전에 파일 전송을 실행하십시오. 로그인한 적이 없거나 파일이 없는 사용자, 또는 oCIS에 등록되지 않은 사용자는 파일 전송 단계를 건너뜁니다. 누락된 사용자 또는 그룹이 포함된 공유 폴더는 마이그레이션이 진행되는 동안 오류로 보고될 수 있습니다. Cedar Studio의 경우, 팀에서 명령 출력과 공유 폴더 목록을 검토해야 합니다. 치명적인 오류 없이 마이그레이션이 완료되었다고 해서 모든 공유 폴더가 정상적으로 작동하는 것은 아닙니다.

마이그레이션 가이드에 따르면 성공적으로 완료된 단계는 생성된 대상 데이터를 먼저 제거하지 않고는 단순히 반복할 수 없습니다. --force초기화 재설정은 oCIS에서 이미 마이그레이션된 파일을 제거하지 않습니다. 재설정 플래그를 일상적인 재시도 전략으로 사용하지 마십시오. 단계가 실패하면 로그를 보존하고 생성된 항목을 확인한 후 대상을 복구할지 또는 깨끗한 대상에서 다시 시작할지 결정하기 전에 마이그레이션 가이드 또는 지원팀에 문의하십시오.

5단계: 의도적인 검증 및 복구 기간을 두고 전환합니다.

안전한 전환을 위해 Cedar Studio는 직원들이 Classic에서 파일 변경을 중단하는 기간을 정하고, 승인된 마이그레이션을 실행한 다음, 모든 검사가 통과된 후에만 클라이언트와 사용자가 oCIS를 사용하도록 안내합니다. 이러한 파일 변경 중지는 운영상의 안전장치일 뿐, 마이그레이션 앱이 실시간 동기화를 수행한다는 의미는 아닙니다. 게시된 마이그레이션 가이드에는 지속적인 동기화 또는 최종 델타 복사 명령에 대한 설명이 없습니다. 만약 비즈니스에서 파일 변경 중지를 허용할 수 없다면, 다운타임 없는 마이그레이션을 약속하기 전에 ownCloud 지원팀에 버전별 전환 계획을 문의하십시오.

단일 관리자 로그인 대신 체크리스트를 사용하여 유효성을 검사하십시오.

• oCIS에서 예상되는 활성화된 사용자, 그룹 및 그룹 멤버십이 표시되는지 확인하고, 특히 이전 관리자의 경우 역할 할당을 확인하십시오.
• 사용자들이 대용량 파일과 최근 편집한 문서를 포함하여 여러 개인 스페이스에서 마이그레이션된 대표 파일을 열어보도록 하세요.
• 소유자 계정과 수신자 계정 모두를 사용하여 내부 사용자 공유 및 그룹 공유를 테스트하십시오.
• 공개 링크를 개인 브라우저 세션에서 열고, 이전된 보호 링크의 암호를 재설정하고, 정책 검사에 실패한 링크를 다시 생성할 수 있습니다.
• 외부 마운트를 다시 생성하고 해당 마운트가 가리키는 데이터를 별도로 마이그레이션하거나 다시 연결한 다음 사용자가 의도한 액세스 권한을 갖는지 확인합니다.
• 새 주소를 발표하기 전에 데스크톱 및 모바일 클라이언트, 로그인, 동기화, 그리고 비밀번호 재설정을 위한 지원 경로를 확인하십시오.

비즈니스 소유자의 승인 및 필요한 기록 확인이 완료될 때까지 Classic 인스턴스를 제어된 읽기 전용 또는 고정 상태로 유지하십시오. 더 이상 필요하지 않을 경우 임시 가장 기능을 제거하고 마이그레이션 앱 토큰을 취소하십시오. 그런 다음 스토리지 레이아웃에 맞는 절차를 사용하여 oCIS 백업을 수행하고 테스트하십시오. 공식 oCIS 8.2 백업 고려 사항에는 문서화된 백업 절차를 수행하려면 인스턴스를 완전히 종료해야 하며 메타데이터와 파일 블롭이 별도의 스토리지 경로를 가질 수 있다고 명시되어 있습니다.

성공적인 이민이란 어떤 모습일까요?

Cedar Studio 사례에서 성공은 단순히 oCIS 웹 인터페이스가 로드되는 것만을 의미하지 않습니다. 직원들이 의도된 ID 소스로 인증하고, 홈 디렉터리 콘텐츠를 찾고, 팀 파일을 열고, 예상되는 권한으로 재구성되거나 마이그레이션된 공유 폴더를 사용할 수 있어야 합니다. 암호 재설정, 외부 마운트 및 공용 링크 변경 사항도 고려되며, 승인이 완료될 때까지 기존 시스템(Classic)은 계속 사용할 수 있습니다. 이러한 검사 중 하나라도 실패하면 전환을 일시 중지하고 영향을 받는 사용자와 개체를 기록한 다음, oCIS를 공식 시스템으로 간주하기 전에 문제를 해결해야 합니다.