DataBackup 開源 root 備份，把每個 App 的資料打包成標準 tar 檔

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

手機備份這件事，Google 帳號幫你做了一半：App 清單、部分設定、相片雲端硬碟都會回來，但每個 App 自己的登入狀態、遊戲存檔、聊天記錄這些藏在應用資料目錄裡的東西，官方雲端備份從來不碰。要把這一半也掌握在自己手裡，Android 上的老答案一直是 root 加上一支備份工具，從早期的鈦備份到後來的各種腳本都是這條路。DataBackup 是這條路上仍活躍維護的開源作品：GPL-3.0 授權、7,452 顆星、需要 root、支援 Magisk、KernelSU 與 APatch。這篇我把它的原始碼關鍵檔、官方文件與將近百則問題討論串翻過一輪，先講我的整體判斷：它的備份端工程比多數同類做得扎實，但 2026 年使用這類工具的真正難關，已經從「備份」搬到了「還原」這一端。

先停 App 再打包：備份端的工程比想像裡扎實

打開它的原始碼，備份流程每一步都看得到實作。開始備份某個 App 前，程式會先讀設定裡的停止 App 選項，把目標 App 強制停掉才開始複製，避免備到寫到一半的檔案；接著每個 App 的內容被拆成六類分別處理：APK 安裝檔本身、每個使用者帳號的資料、裝置保護區資料、主資料目錄、OBB 遊戲擴充檔與媒體檔。這也是它標榜資料完整性的底氣來源：完整性來自「先停再複製」的資料一致性設計，而不是什麼神奇技術。

打包本體則是一條標準的 tar 指令管線。原始碼裡的壓縮工具類實際拼出的命令是 tar 加上串接壓縮器，格式有三種可選：純 tar、zstd 與 lz4，其中 lz4 也是透過 zstd 工具以 lz4 格式參數輸出。比較少人注意到的是，它不依賴手機系統自帶的 tar：專案把一份自己維護的 GNU tar 原始碼以子模組形式收進來編譯，zstd 同樣是自帶繫結，目的就是擺脫各家 ROM 精簡版工具鏈的行為差異。壓縮完成後還會對檔案做一次完整性測試，確認封存檔真的可以讀，備份才算數。

三種壓縮格式對使用者是有實際意義的選擇：純 tar 不壓縮，備份最快、檔案最大，適合空間充裕的外接儲存；zstd 是折衷，壓縮率與速度都有水準；lz4 把重點放在解壓速度，適合頻繁還原的場景。壓縮等級也可以自己調，空間與時間的取捨留給使用者決定。除了逐 App 備份，它也能打包任意檔案與目錄，多使用者環境下可以指定任何使用者帳號的應用來備份或還原，多人共用的平板或工作裝置才會用到這條。

對使用者來說，這套設計的直接意義是：打包出來的東西是標準 tar 封存檔。十年後就算這個 App 消失了，任何一臺 Linux 電腦都還能解開你的備份，資料不會被鎖在某個只有原作者看得懂的專有格式裡。root 權限的執行走的是 Magisk 作者的 libsu 函式庫，管理 root 授權的方式照主流做法：Magisk 使用者直接在彈出視窗按下同意，KernelSU 與 APatch 則要先在自己管理器裡手動同意再重啟 App，文件站也保留了自己指定 su 檔案路徑的選項，給某些 su 不叫 su 的裝置用。

Pin

兩種安裝包只差一個 Firebase：重視隱私選 foss 就對了

下載時你會面對 foss 與 premium 兩種檔名，這是同一套程式的兩個建置口味，差異在原始碼裡寫得一清二楚：premium 版接上了 Google 的 Firebase，帶 Crashlytics 當機回報與 Analytics 分析兩項服務；foss 版則完全不帶。接線方式在建置設定檔的分流裡，Firebase 設定檔只存在於 premium 那個目錄下，foss 版從編譯源頭就沒有這條線。

散布管道也反映了這個差異：F-Droid 與 IzzyOnDroid 兩個自由軟體商店上架的都是 foss 版，GitHub 版本頁則兩種都有，每個版本依照四種處理器架構各出 foss 與 premium 兩包，最新穩定版 2.0.12 一輪八個安裝包。下載分布值得看一眼：2.0.12 從 2025 年 9 月發布到現在，八個包累計下載超過十萬次，其中 arm64 的兩個包就各佔四萬五上下，其餘架構都是幾千次的小尾巴，等於大多數使用者集中在主流 64 位元 arm 裝置。授權是 GPL-3.0。

所以怎麼選其實不難：不想要任何遙測的人拿 foss 版，而且直接從 F-Droid 裝最省事；願意讓作者收到當機報告當作回饋的人再考慮 premium。兩者功能面沒有差別，差別只有資料回報這件事。

Pin

備份放哪自己決定：本機目錄，或自己的 WebDAV、FTP、SFTP、SMB

備份目的地是這類工具的另一個關鍵設計。DataBackup 的雲端備份支援四種協定：WebDAV、FTP、SFTP 與 SMB，設定頁在程式裡各有一個。這裡有個文件與程式碼對不上的小細節：官方文件首頁列雲端支援時只寫了 WebDAV、FTP、SMB 三個，SFTP 是看原始碼的設定頁檔案才數得出來的，實際以程式碼為準。

四個協定共同的立場是：沒有任何一個是廠商雲端。WebDAV 與 SMB 對應你自己的 NAS，FTP 與 SFTP 對應你自己租的伺服器，備份檔從頭到尾不出自己控制的範圍，這跟把資料交給某個 App 服務商的雲端是兩種完全不同的信任模型。它也處理了一些 root 備份特有的周邊：無線網路設定的備份與還原走隱藏 API 模組處理跨版本差異，甚至偵測 XPosed 模組存在時有對應的處理邏輯。如果你要的不是全機應用備份，而是單一服務的資料匯出，站上先前介紹過的 B 站收藏備份工具 與 微信聊天記錄備份 是更輕的選擇，兩者不需要 root，讀者任務其實分得很開。

這類周邊功能藏在單獨的隱藏 API 模組裡，版本演進看得到維護痕跡：無線網路設定的還原在 2.0.11 修過跨 Android 版本的行為差異，2.0.10 也更新過 XPosed 模組的偵測方式。這些細節平常沒人注意，但重刷機器後無線網路全部要重打的體驗差異，用過的人都知道。

穩定版停在一年多前，新版正在換一顆快照引擎

接下來是最需要誠實面對的部分：時間軸。穩定版的發布節奏是 2025 年 8 月連出 2.0.10、2.0.11，9 月 20 日出 2.0.12，然後就停了，到今天超過一年沒有新版。其實 2.0.12 的版本說明裡就先講明白了：正在準備下一代的 DataBackup，這需要很多時間，2.x 的更新作業會延後。將近一年後有人在 2026 年 8 月開問題問哪裡能下載到最新編譯版，作者的回覆說得更直白：最新版本還沒有達到生產可用的狀態，所以一直沒有正式發布，目前發布的最新版仍是 2.0.12。這兩句都是作者的宣稱，但倉庫的開發分支佐證了它們不是藉口。

開發分支接下來的動作野心更大：整個核心正在重寫，最新的功能性提交一路排到 2026 年 10 月中，主軸是把一套叫 rustic_core 的 Rust 快照引擎裝進 Android，以子模組直接收錄上游官方程式碼。快照引擎帶來的是類似 restic 那種內容去重、可回溯多個時間點的增量備份模型，而「用 restic 式增量備份」正好也是問題區裡有人點名的功能請求。新版還沒排進正式發布頁，版本說明只附上 CI 產物連結，留給願意自己動手的人。

Pin

對正在考慮採用的人，可以把這條時間軸讀成：2.0.12 就是現況，它成熟、下載量大、該修的常見問題修過幾輪；但別把「很快就會有增量備份新版」當成採用理由，作者自己都說還沒到生產可用。翻譯與文件倒是持續活著，透過 Weblate 的翻譯提交到 2026 年 10 月中都還在進倉庫，這對一個單人核心專案來說是維持基本體溫的訊號。

檔案還原成功，不等於 App 打得開

這是我認為 2026 年使用 root 備份工具最該理解的一件事，也是問題討論串裡最有價值的一則。2026 年 9 月底有使用者回報：把受 Google Play 自動保護機制 PairIP 保護的 App 還原之後，App 會在執行約二十秒後自己跳出「請從 Play 商店安裝」的提示然後退出。細節很有意思：從商店裝的 App 與從備份還原的 App，在系統安裝記錄裡有差，還原的那份會多一條經由 Shell 安裝的標記，討論串也把問題指向這個安裝記錄的差異。

這不是 DataBackup 的 bug，是整個生態的方向。檔案層的備份與還原它做到了，但 Play 完整性這類機制驗的是安裝來源與完整性，經 root shell 裝回去的 App 天生就帶著不同指紋。作者到 2026 年 10 月中還在這則問題裡給測試安裝包請使用者幫忙驗證，使用者試完回報仍然失敗，等於這條路目前沒有解。其他問題也反映了類似的現實：有 ColorOS 16 使用者因為系統精簡版 tar 導致全部備份失敗，有 MIUI 14 拿不到 root 權限的，有雲端備份超過 10GB 直接失敗的，也有大檔上傳到 FTP 逾時的。ROM 相容性與雲端大檔是工程問題會慢慢修，但安裝來源驗證這條是生態結構問題，短期內看不出會放寬。

所以實際的期待管理是這樣：遊戲存檔、自己開發的工具、沒有安裝來源檢查的 App，備份還原的把握度高；付費 App、銀行與金融類 App、有反竄改保護的商業 App，就算檔案一個位元組都沒少地還原回去，也要有被打回票的心理準備。這段我沒有 root 實機可以實測，判斷全部來自上述討論串的逐則內容與作者回覆，這個邊界先說清楚。

授權、單人維護與文件現況

專案形態的部分。核心開發者 XayahSuSuSu 一人貢獻了 1,816 次提交，其後的貢獻者集中在每次數十次的翻譯與週邊修正，典型的單人核心專案，巴士係數很低，這是採用任何開源工具都該知道的風險面。緩解是授權與散布：GPL-3.0 加上 F-Droid 收錄，就算原開發者哪天停手，程式碼與建置管道都在公共管道裡，社群可以接手，這正是開源備份工具相對閉源前輩們的結構性優勢。

出身上它是個繼承者：源頭是酷安市場一位作者維護的 speed-backup 備份腳本，App 版本是在腳本原作者同意下重寫的，這段譜系在說明文件與商店頁都如實交代。從 shell 腳本到應用程式的重寫，也解釋了為什麼打包核心堅持走標準 tar 指令而不是自創格式：腳本世代的可攜性傳統被完整繼承下來。

文件站提供十種語言，包含簡體中文，但沒有繁體中文版，要看文件只能挑簡中或英文版。另外有個入門前會踩到的小混淆：支援的 Android 版本在三個官方位置說法不一致，倉庫描述寫 Android 7.0 以上，文件站寫 Android 8 以上，F-Droid 商店頁寫 Android 9 以上。實際安裝前建議以商店頁的 9 以上最保守認定，太舊的裝置先確認再下手。官方管道除了 GitHub，還有 Telegram 的公告頻道與討論群可以追進度。

限制與風險：安裝前該知道的事

把會影響決策的限制集中列一遍。第一，root 是硬門檻，沒有 root 完全不能用，而無 root 模式目前只存在於功能請求裡；root 本身的保固與安全風險不歸這個工具管。第二，還原端的生態風險如前所述，受 Play 完整性保護的 App 就算還原成功也可能拒絕執行。第三，跨機型還原要保守：備份是逐檔複製，還原到不同 SoC、不同 Android 版本甚至不同 ROM 的裝置上，行為沒有人掛保證，最穩的用法是同一臺裝置的災難復原，而不是換機搬家的萬用票。第四，雲端大檔與部分協定的邊角問題存在未解案例，備份量大的人先小規模試。第五，工具自身的資料也要備份，它有備份自身的選項，設定檔與備份索引一併留份才不會備份了半天卻找不到索引。

想降低還原風險，實際做法是先做小規模演練：備份完成後挑一個不重要又沒有安裝來源檢查的 App 實際還原一次，確認流程通順、資料回得來，再把重要資料押上去；雲端備份也一樣，先用小備份組驗證傳輸與身分設定，再上大檔。這是備份領域的老原則：沒有實際還原過的備份，都只能算是假設。

誰該裝，誰先等等

把整體判斷收斂成一句話：DataBackup 是 root 陣營目前工程品質最整齊的開源備份方案，值得採用的前提是你接受它的兩個現實。該裝的人：手機已 root、在意 App 資料主權、想要標準格式備份檔放在自己 NAS 或伺服器的人，尤其是同一臺裝置用很久、最怕突發災難的長期使用者，拿 foss 版從 F-Droid 安裝，把備份排程指向自己的 WebDAV，這是最穩的一條路。先等等的人：不想 root 的人沒得談，想靠它輕鬆換機搬整套 App 的人會在 Play 完整性那堵牆上失望，等增量備份新版的人也可以再等等，新版還沒到生產可用。介於中間的人，可以先用它備份不在乎安裝來源的那批 App，把金融與付費 App 的期待值降到檔案留檔即可。Android 進階玩家如果只是想在電腦上操作手機，之前介紹的 scrcpy 圖形介面版 是另一個方向的工具，兩者搭配起來剛好是一套完整的桌面管理流程。