如何從 ownCloud 10 Classic 遷移到 ownCloud Infinite Scale

範例場景：假設有一個虛構的 32 人設計公司 Cedar Studio，它運行 ownCloud Classic 10，其中包含 LDAP 目錄、個人文件區、群組共享、公共連結以及外部專案儲存掛載。該公司希望遷移到 ownCloud Infinite Scale (oCIS)，但不認為安裝新伺服器就能遷移其資料或權限。此範例僅為假設，並非已完成遷移的報告。

ownCloud 官方支援的遷移路徑是使用migrate-to-ocisClassic 伺服器上的應用程式和occ命令進行引導式遷移。這是一個分階段遷移到獨立、乾淨的 oCIS 目標的過程，而不是對 Classic 資料庫或資料目錄進行就地升級。遷移手冊指出，來源系統在大部分過程中保持運行，但並未描述持續同步或零停機的最終增量遷移。請在生產環境使用前，請與 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 二進位。請勿使用任意 Marketplace 軟體包或無關的文件複製作業來取代此應用程式文件中記錄的遷移過程。

在 oCIS 端，啟用auth-app服務和應用程式驗證設定。遷移指南還要求啟用模擬功能，並為 oCIS 管理員建立應用程式令牌。 Infinite Scale 8.2 auth-app 文件明確指出，模擬功能僅用於遷移，不應在生產部署中保持啟用狀態。請將其視為臨時遷移設定：保護令牌，限制其存取權限，並在遷移完成後關閉僅用於遷移的模擬功能。在分散式部署中，請依照文件說明將設定套用到正確的服務。

對於假設的 Cedar Studio，應使用與 Classic 伺服器相同的 LDAP 服務測試 oCIS 目標。將憑證保存在部署的金鑰機制中，而不是將綁定密碼貼到 shell 歷史記錄或共用運作手冊中。官方的ownCloud 遷移指南列出了目標要求，並指出了 ownCloud 對遷移應用程式的支援。 oCIS 8.2 驗證應用程式指南解釋了應用程式代幣和模擬。

步驟 3：使身分映射一致，然後執行就緒性檢查

在遷移檔案和共用之前，oCIS 必須能夠解析使用者和群組。 Cedar Studio 已使用 LDAP，因此其管理員會將 oCIS 連接到同一目錄，以驗證使用者是否可以登錄，並檢查識別碼是否已對應到預期帳戶。 ownCloud 指南列出了每個已啟用 Classic 使用者的唯一有效電子郵件地址。對於使用 LDAP 的 Classic 用戶，指南還列出了用戶名屬性（通常為 `<username>`uid或 `<group> samAccountName`）以及對應的 oCIS LDAP 架構設定。請將屬性與實際目錄進行比對；不要盲目複製範例值。

如果 Classic 使用本機帳戶，而 oCIS 將使用外部 LDAP 目錄，請在檔案傳輸之前建立或移轉符合的使用者和群組到該目錄中。使用者名稱和群組名稱必須相符。 oCIS 內部的 IDM 是一個功能有限的嵌入式目錄，主要針對小型部署或測試環境；ownCloud 建議生產環境使用真正的 LDAP 或外部身分識別管理系統。官方遷移流程不支援在同一遷移分支中同時存在本地和 LDAP 支援的 Classic 使用者。請尋求技術支援來解決此架構問題，而不是在遷移過程中暫時調整。

在 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

驗證指令會檢查已啟用使用者是否擁有有效且不重複的電子郵件地址。請先修復已報告的問題，然後再繼續操作，不要跳過驗證步驟。如果已停用使用者需要遷移，請先審核該帳戶，在驗證之前在 Classic 中啟用該帳戶，並將其納入遷移計劃。 Cedar Studio 也應在資料傳輸開始之前，使用幾個代表性使用者驗證 oCIS 的 LDAP 登入。

步驟 4：完成使用者和群組分支，然後遷移檔案和共用

請按照官方指南中與您的身分設定相符的分支進行操作。如果 Classic 使用者是本機用戶，並且將使用 oCIS 的嵌入式身分識別管理 (IDM)，則指南的步驟包括遷移使用者、指派 oCIS 角色和遷移群組。遷移後的使用者將被指派一個角色；Classic 角色不會一一保留，Classic 子管理員權限在 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 中刪除已移轉的檔案。請勿將重置標誌作為常規重試策略。如果某個階段失敗，請保留日誌，確定創建了哪些內容，並在決定是修復目標還是從乾淨的目標重新開始之前，查閱遷移指南或諮詢技術支援。

步驟五：切換時預留充分的驗證與恢復時間。

為了確保安全切換，Cedar Studio 會安排一段時間，在此期間員工停止在 Classic 中修改文件，運行已批准的遷移程序，並在所有檢查通過後才將客戶端和使用者引導至 oCIS。此寫入凍結措施是一種操作保障，並非聲稱遷移應用程式會執行即時同步。已發布的遷移指南並未記錄持續同步或最終的增量複製命令。如果企業無法接受寫入凍結，請在承諾零停機遷移之前，向 ownCloud 支援團隊索取特定版本的過渡方案。

使用檢查清單進行驗證，而不是僅使用管理員登入資訊：

• 確認預期的已啟用使用者、群組和群組成員身分是否出現在 oCIS 中；確認角色分配，特別是對於先前的管理員。
• 讓使用者開啟從多個個人空間遷移過來的代表性文件，包括大文件和最近編輯過的文件。
• 使用所有者帳戶和接收者帳戶測試內部使用者共用和群組共用。
• 在私密瀏覽器會話中開啟公共連結；重設已遷移的受保護連結的密碼，並重新建立未通過政策檢查的連結。
• 重新建立外部掛載點，並分別遷移或重新連接它們指向的數據，然後確認使用者擁有預期的存取權限。
• 在公佈新地址之前，請檢查桌面和行動用戶端、登入、同步以及密碼重設支援途徑。

在業務負責人簽署確認並檢查所需記錄之前，請將 Classic 版本保持在受控的唯讀或其他凍結狀態。移除臨時模擬功能，並在不再需要時撤銷遷移應用程式令牌。然後，請按照其儲存佈局的步驟進行 oCIS 備份並進行測試。官方的oCIS 8.2 備份注意事項指出，必須完全關閉實例才能執行文件中記錄的備份步驟，並解釋說元資料和檔案 blob 可能位於不同的儲存路徑。

一次成功的遷移是什麼樣的呢？

在 Cedar Studio 的範例中，成功不僅僅意味著 oCIS Web 介面載入成功。它還意味著員工可以使用預期的身份來源進行身份驗證，找到其主目錄內容，打開團隊文件，並使用具有預期權限的重新建立或遷移的共用資料夾。密碼重設、外部掛載和公共連結變更都會被考慮在內，同時 Classic 版本在驗收完成前仍然可用。如果任何一項檢查失敗，則暫停切換，記錄受影響的使用者和對象，並在將 oCIS 作為正式記錄系統之前解決此問題。