將 Kopano 信箱移轉到 Grommunio 或 Zammad:選擇正確的路徑
比較 Kopano、grommunio 和 Zammad 的遷移功能。了解每種方法可以保留哪些郵箱數據,如何試用和驗證結果,以及何時適合使用 IMAP 或自訂匯入。
正確的遷移路徑取決於您對「郵箱」的定義。如果您需要一個能夠將郵件保存在群組郵件中的 Kopano 替代方案,請使用 grommunio 的 Kopano 遷移路徑。如果您想要一個共享支援佇列,將收到的電子郵件轉換為客戶對話和工單,Zammad 可能更合適——但它是一個幫助台,而不是群組郵件信箱的替代方案。 Zammad 目前的遷移文件中並未將 Kopano 列為直接匯入來源。
這種區別決定了成功結果的標準。在 Grommunio 中,使用者應該能夠找到他們的郵件,並且在完成單獨的遷移工作後,還能找到他們依賴的其他支援的群組資料。在 Zammad 中,客服人員應該能夠看到選定的通訊記錄,這些記錄已正確分組為工單和文章,並且客戶和所有權已根據您的支援工作流程進行對應。任何目標系統都不應在未進行試點和驗收檢查的情況下,直接複製 Kopano 的版本。
| 需要 | 更合身 | 預期情況 |
|---|---|---|
| 用 Kopano 替換電子郵件和群組 | 格羅穆尼奧 | 在支援的情況下使用 Kopano 原生資料路徑;明確規劃身分、路由、權限和非郵件資料。 |
| 將共享支援收件匣轉換為客服人員工作流程 | 札馬德 | 電子郵件將轉換為工單對話。定義要匯入哪些郵件,以及如何對應執行緒、客戶、群組和客服人員。 |
| 保留可搜尋的歷史檔案,但將新的支援郵件轉交給代理商。 | Zammad 加上存檔或來源信箱 | 連接支援地址以接收新郵件,並將舊的個人或商業郵件保留在適當的存檔中。 |
Grommunio 的遷移概述建議使用 Kopano/Zarafa,並指出此路徑會遷移完整的郵箱,包括 MAPI 屬性。其單獨的 IMAP 路徑會移轉郵件和資料夾,但不會移轉行事曆或聯絡人。在選擇工具之前,gromox-kdb2mt請先閱讀最新的Grommunio 遷移概述。
首先進行清點,而不是批量複製。記錄每個 Kopano 使用者、主地址和別名地址、儲存識別碼、郵箱大小、郵件數量、配額、共用資料夾、委託人、公用資料夾以及用於驗證使用者的服務。注意 Kopano 是否使用 LDAP,以及附件是儲存在資料庫中還是檔案系統中。郵箱遷移可以移動內容,同時保留目錄配置、郵件路由和權限。
選擇一個能代表實際環境的小型試點資料集:一個普通郵箱、一個大型郵箱,以及任何具有共用存取權限、非英文資料夾名稱或特殊附件的郵箱。備份來源郵箱和目標郵箱,並將首次匯入作業匯入到一個臨時的或乾淨的目標郵箱。在運行工具之前,定義可衡量的檢查項:
gromox-kdb2mt對於受支援的 Kopano 資料庫,grommunio 文件中提供了使用 `grommunio` 和 `grommunio` 的直接路徑gromox-mt2exm。第一個實用程式從 Kopano SQL 資料庫及其關聯的附件儲存中讀取一個儲存;第二個實用程式將傳輸流匯入到 grommunio 郵箱中。請遵循您已安裝版本的呼叫語法和選項,而不是從其他部署複製通用命令列。
來源 SQL 服務和所需的附件檔案必須可供遷移過程存取。目前的gromox-kdb2mt 手冊列出了支援的資料庫架構版本,並指出使用該架構的安裝attachment_storage=files_v1-x-y需要相應的--l1選項--l2。如果您的來源佈局不同,請暫停並解決儲存對應問題,然後再嘗試完整匯入。
匯入前請準備好目標網域和郵箱。如果 Kopano 使用 LDAP,請確定 grommunio 是否使用相同的目錄,並在遷移儲存之前測試使用者匹配。 Kopano 官方遷移指南描述了一個多步驟流程:配置目標目錄整合(如適用)、建立儲存、遷移用戶數據,然後切換郵件路由。該指南還提醒用戶,它可能無法涵蓋所有來源安裝。
務必仔細映射使用者。 Kopano 的資料庫可能使用數位或 GUID 元資料而非簡單的電子郵件地址來識別商店。 grommunio 文件可kdb-uidextract作為輔助工具,用於從即時 Kopano 系統中產生使用者對應;請參閱kdb-uidextract 手冊。映射對於收件人地址和存取控制條目至關重要。即使共用資料夾權限仍然指向目標系統中不存在的身份,傳輸在技術上也可能成功。
如果無法直接進行資料庫遷移,或者您只需要電子郵件,那麼當 Kopano 上啟用並可存取 IMAP 時,IMAP 同步可能是實用的替代方案。 grommunio 的文件化imapsync工作流程支援可重複的完整同步和增量同步,並保留郵件資料夾、標準標記和內部日期。但它的限制也很明顯:IMAP 不會傳輸日曆、聯絡人、任務、筆記、伺服器端規則、委派、公用資料夾或密碼。
首先準備好目標郵箱和配額,將憑證安全地保存在受保護的文件中,並在首次複製之前測試連接性。對一個試點郵箱執行初始同步,在 grommunio Web 中查看結果,然後在郵件流重定向後重複增量同步。詳細的grommunio IMAP 遷移指南包括準備工作、試運行檢查、資料夾映射、增量同步、切換和故障排除。除非您已確認鏡像或刪除選項會刪除哪些內容,否則請避免使用它們。
Zammad 將工作組織成工單,其中包含文章、客戶、群組和代理商。它不會像 Exchange 那樣建立包含行事曆、聯絡人、任務、資料夾權限和常規郵件用戶端行為的郵箱。其遷移文件目前列出了受支援的來源系統,例如 Freshdesk、Kayako、OTRS 和 Zendesk,但不包括 Kopano。文件指出,對於不支援的來源系統,遷移需要採用基於 API 的方法或進行自訂遷移。
在建置導入器之前,請先定義轉換規則。決定哪些 Kopano 信箱或資料夾代表支援請求,如何將郵件分組到對話中,如何將寄件者與 Zammad 客戶匹配,以及如何將舊的所有權或類別對應到 Zammad 群組和客服人員。郵箱並非自動成為工單佇列:個人信件、新聞簡報、草稿和自動通知可能不屬於面向客戶的工單。
對於歷史數據,請使用受支援的 Zammad API 或自訂遷移器規劃受控的匯出和匯入流程。在目標資料模型允許的情況下,保留原始郵件日期和郵件頭,保留附件,並記錄來源郵箱和郵件識別碼以進行追溯。首先將少量樣本匯入到新的 Zammad 實例中。 Zammad 的通用遷移規則規定,來源遷移要么全部遷移,要么全部不遷移,並且需要一個新的實例;這些規則僅適用於其文件中記錄的遷移模組,因此請單獨確認任何自訂導入器的行為。
使用 Zammad 的電子郵件通道連線切換後用於建立或接收新支援郵件的位址。 Zammad 目前的電子郵件通道文件介紹如何連接電子郵件提供者以及如何路由收到的郵件。請將通道設定和歷史郵箱匯入作為單獨的任務。切勿將真實使用者的收件匣指向未經測試的匯入程式:重複的工單、意外的回覆或錯誤的路由都可能影響真實使用者。
在驗收期內,確保 Kopano 可用並備份。試點通過後,運行主遷移並記錄來源基線。安排一個短暫的變更窗口,暫停或重定向郵件投遞,執行最終的增量或追趕導入,切換 MX 或內部路由,然後從組織內部和外部發送測試郵件。 grommunio 遷移概述特別建議在 DNS/MX 切換後進行最終的增量運行,以確保過渡期間到達的郵件不會遺失。
更新使用者登入資訊、用戶端設定、自動發現、行動裝置、別名、中繼規則以及任何透過 Kopano 傳送郵件的應用程式。這些操作與複製郵箱資料無關。制定回滾計畫:了解如何將郵件路由回原伺服器、使用者如何存取原始伺服器,以及如果目標伺服器無法接受郵件,由誰授權回溯。
當目標資料夾及其代表性內容與來源資料夾在約定的誤差範圍內匹配,使用者可以找到最近和歷史郵件、已開啟的附件,且郵件雙向流動正常時,遷移即可投入正常使用。對於 Grommunio,需分別驗證行事曆和聯絡人遷移、共用存取權限、目錄登入以及用戶端行為。對於 Zammad,需驗證工單邊界、文章順序、客戶匹配、可見性、分配情況,以及舊郵件是否觸發了意外的外部回應。
如果試點計畫顯示缺少 MAPI 資料、附件損壞、ACL 未解析,或需要保留 IMAP 副本無法承載的群組功能,則應變更遷移方法。對於 Zammad,如果主要需求是個人郵箱的連續性或日曆/聯絡人支持,則應重新考慮目標位置。自訂遷移可以橋接資料模型,但會增加映射、測試和維護工作;它不等同於 Kopano 的原生郵箱導入。在使用者和管理員能夠驗證所需記錄之前,請將 Kopano 設定為唯讀或保留單獨的存檔。
比較 Kopano、grommunio 和 Zammad 的遷移功能。了解每種方法可以保留哪些郵箱數據,如何試用和驗證結果,以及何時適合使用 IMAP 或自訂匯入。
將 Nextcloud 資料目錄遷移到外部硬碟,同時保持檔案引用的完整性。安全地使用備份、持久掛載、rsync、權限和符號連結。
透過檢查服務使用者、PHP 和 Nextcloud 路徑、定時器啟動和作業運行歷史記錄,對 Ubuntu 上的 Nextcloud systemd cron 定時器進行故障排除。
在 BigBlueButton 4.0 beta.4 或更早版本中啟用 Etherpad 共享筆記。安裝可選軟體包,選擇會議等級或全域預設值,並排查代理問題。
透過檢查 PHP、Nginx 或 Apache、反向代理、逾時設定和存儲,修復 Nextcloud 2GB 上傳限制。使用大於原始限制的檔案安全地測試變更。
在 Apache 上為 ownCloud 伺服器設定 Let's Encrypt HTTPS。檢查 DNS 和端口,使用 Certbot 頒發證書,啟用重定向,並測試續約。
升級後診斷 ownCloud 完整性警告,並為核心檔案不符、檔案缺失、額外檔案或應用程式簽署錯誤選擇安全的修復方案。
為 ownCloud Server 公共連結設定最長過期日期,了解它會影響哪些共享,並在不忽略較舊連結的情況下驗證策略。
設定 Zimbra GAL 自動同步,設定輪詢間隔,強制執行測試同步,驗證時間戳,並追蹤過時的內部或外部 LDAP 聯絡人。
為 ownCloud Infinite Scale 配置 LDAP 支援的登錄,映射使用者和群組,選擇內建或外部 OIDC,保護憑證,並安全地驗證身份驗證。