企业官网建设流程全解析

system分区和data分区，是Android设备上最值得单独拎出来做备份的两块地。前者装着系统本身的只读镜像，后者装着你所有的应用数据、账号配置、聊天记录和内部存储。很多人刷机前嘴上说"我备份了"，真出事了才发现备份的是通讯录和照片，系统起不来照样抓瞎。这篇就把"完全备份"这四个字拆开讲清楚：怎样把system分区做成一个可以原样写回的镜像，怎样把data分区在保留权限和SELinux上下文的前提下打包，以及为什么这两件事不能用同一套方法做。内容偏实操，适合已经会基本命令行操作、手里有可用root权限、准备折腾系统或者做设备迁移的朋友；完全没接触过命令行的新手也能看懂思路，按步骤照抄也能跑通，但涉及分区写入的步骤建议先在非主力机上练手。

1. 备份之前先把三件事想明白

动手敲命令之前，先把目标、介质和风险边界定下来。这一步省掉的时间，后面往往要成倍还回去。我见过太多人上来就dd，结果备份文件写到一半空间不足，得到一个残缺镜像，刷回去直接变砖——备份这件事最怕的不是没做，而是做了一半还以为做成了。

1.1 分区的"完全备份"到底指什么

先统一概念。"完全备份"在系统维护语境里有两种含义，混淆了就会做出错误决策。

第一种是块级备份，也叫裸镜像备份。它绕开文件系统，直接按扇区读取整个分区，产出一个和分区等大的二进制镜像文件。优点是绝对忠实：文件系统元数据、空闲块、甚至是已删除文件的残留都在里面；恢复时一个dd写回去，分区状态和备份那一刻逐字节一致。缺点也很明显：体积大、无法单独提取某个文件、不能跨分区大小恢复。

第二种是文件级备份。它通过文件系统接口遍历目录树，把文件、目录结构、权限位、所有者、时间戳、扩展属性打成归档包。优点是灵活、体积可控、可以只备份一部分、能跨设备恢复。缺点是会丢失"文件系统之外"的东西——空闲块布局、inode 编号、以及最容易出事的 SELinux 安全上下文（如果打包工具没处理好）。

对system分区，我强烈建议用块级。它本身就是只读的、内容相对静态、大小固定，一个镜像打完收工，恢复时也最省心。

对data分区，情况反过来。它体积大、内容天天变、里面还套着一层/data/media（也就是你在文件管理器里看到的"内部存储"），块级备份出来往往是几个GB的加密数据，换个设备根本用不了。data更适合文件级，或者块级+文件级双轨。

1.2 备份存到哪里，这个介质选择很关键

介质选择直接决定成败。设备内部空间是有限的，而你要备份的东西恰恰是占用空间最大的两块。

往内部存储（/sdcard）写大文件是个典型陷阱。一是空间不够，system镜像动辄几个GB；二是这个路径在很多机型上是FUSE挂载的模拟存储层，权限和路径映射都比较绕，dd写进去经常出现权限被拒或者写入极慢。真要临时落盘，用/data/local/tmp更稳妥，它是真正的文件系统路径，权限宽松，速度也快。

我的常规做法是流水线直出：根本不在设备上落地，dd读出来通过管道直接经 USB 通道送到电脑。这样设备端零空间占用，也不受内部存储速度限制。代价是中途断了要重来，所以线材和接口要靠谱，别用那种接触不良的转接头。

如果非要落盘到外部存储卡，注意格式。FAT32 单文件上限 4GB，一个 system 镜像很可能刚好超过去，写入会在临界点报错。exFAT 没这个限制，但部分旧内核的驱动支持不完整。这个细节很多人栽过。

1.3 权限前提和不可逾越的风险边界

这一节是硬门槛，绕不过去。

读取块设备节点（/dev/block/...）需要 root。普通应用即使拿到存储读写权限，也碰不到块设备层。所以前提是你的设备已经具备可用的 root 环境，或者你能进入一个允许 root shell 的恢复环境。

这里必须说清楚边界：只对你本人拥有、且已经获得合法管理权限的设备做这些操作。设备上的用户数据涉及隐私，备份文件里可能包含账号凭证、通讯录、聊天记录，务必加密存放、不要随手传到公共网盘、用完及时清理。给别人做备份或者帮人迁移数据，务必取得对方明确同意，并且只处理对方指定范围内的数据。

另外提前打个预防针：往分区里写数据是有风险的操作。写错了分区、断电、镜像残缺、恢复后签名校验失败，都可能导致设备无法启动。所以下面所有涉及写入的步骤，我都会强调先确认目标分区路径、先做校验、先准备好救急方案。

2. 搞懂system和data的本质差异

为什么这两块不能用同一招？因为它们在文件系统层面根本是两种东西。这个道理不难，但不搞明白就动手，踩的坑会很莫名其妙。

2.1 system分区：只读挂载的静态镜像

system 分区在正常运行时是以只读方式挂载的，里面是系统框架、系统应用、运行库、字体、权限配置文件这些内容。它平时不会被写入，只在系统更新时整体替换。

这个特性带来两个好处。第一，备份过程中数据不会变动，不存在一致性问题的烦恼——不像备份正在运行的数据库，得先冻结写入。第二，块级备份出来的镜像，恢复时只要目标分区容量不小于原分区，逐字节写回即可，几乎不会出问题。

但也有个坑：很多现代设备上 system 已经不是一个独立的物理分区了，而是被塞进了动态分区容器（通常叫 super 分区）里，作为一个逻辑分区存在。这时候它的设备节点路径和传统设备完全不同，/dev/block/bootdevice/by-name/system可能根本不存在。得先看清楚/dev/block/by-name/下面到底有什么，或者去/dev/block/mapper/里找。

还有个衍生概念要留意：只读挂载 + 完整性校验。系统启动时会校验关键分区的哈希，如果分区内容和预期不符，可能拒绝启动或者降级运行。所以在恢复一个"非原厂"的 system 镜像之后，通常还需要处理这层校验，否则开不了机。这也是很多人"备份了但恢复后起不来"的真实原因。备份本身没错，是恢复之后的配套动作没做。

2.2 data分区：一直在变的活数据

data分区完全相反。它是读写分区，系统运行期间每秒都在变：应用写缓存、数据库落盘、日志滚动。你备份它的那一刻，数据处在什么状态是不确定的。

这就引出一个概念叫一致性。如果你直接dd一个正在运行的 data 分区，途中某个应用刚好在写数据库，你拿到的镜像里那个数据库文件可能是半截的——文件长度对，但内容内部结构错乱。恢复之后应用一打开就闪退，而且很难查原因。

解决办法有几个层次：

• 停机备份：进入恢复环境，此时系统服务全停，data 分区不再有写入，块级备份就是一致的。这是最干净的方案。
• 文件级备份 + 应用静默：不追求全盘一致，只保证单个文件完整。归档工具读取文件时会加锁或者读到的是当时的完整快照，虽然跨文件之间可能有一点点状态错位，但绝大多数场景够用。
• 先冻结再备份：部分设备支持在系统运行状态下暂停写入，备份完再恢复。这个操作对普通用户门槛较高，需要额外的工具配合。

日常做 data 备份，我一般走第二条路。真要做"全盘可还原"，就老老实实进恢复环境停机备份。

data 分区里还有一个必须单独处理的东西：/data/media。这个目录在很多机型上被单独挂载成"内部存储"，里面是照片、视频、下载文件这些大块头。它往往占了 data 分区 80% 以上的体积。备份整个 data 之前，先决定这部分要不要包含进去——做系统迁移就包含，只做配置备份就排除掉，能省下大量时间和空间。

2.3 分区布局差异带来的实操坑

不同设备的分区方案差异极大，动手前必须现场勘查，不能照抄网上的路径。

A/B 槽位这个坑特别值得说。这类设备有两套系统分区轮换使用，系统更新时把新版本写进空闲槽位，重启切过去。你备份了system_a，某天系统更新切到system_b，再想恢复就发现备份对不上当前槽位。所以要么两个槽位都备，要么明确记录下备份时的活动槽位，恢复时确保写回同一个槽位。记录槽位状态有个简单办法：读一下系统属性里的当前槽位后缀，把这个值写进备份文件的命名里，比如system_a_20250101.img，一眼就知道对应关系。

3. 工具方案怎么选

工具没有绝对好坏，只有匹配不匹配。我把常用几条路线摆出来，你按自己的环境挑。

3.1 块设备直读：最原始也最可靠

核心就一条命令：dd。它做一件事——从输入读字节，往输出写字节，中间不做任何解释。正因为"不解释"，它不会因为文件系统类型不识别、权限位读不懂而报错，对任何块设备都一视同仁。

参数上最关键的是bs（块大小）。默认 512 字节，一次搬 512 字节，读几个GB要等到天荒地老。设成4M或8M，吞吐量能提升一个数量级。实测在多数设备上bs=4M已经能跑满 USB 2.0 的带宽瓶颈，再往上加收益不明显，反而更容易因为单次读写过大而失败。

写回的时候还有个细节：dd结束后要执行sync，确保内核缓冲区里的数据真正落到存储介质上。少了这一步，命令返回成功但实际没写完，拔线重启就是灾难。

3.2 恢复环境整盘打包：最省心的停机方案

进入一个支持文件系统和 shell 的恢复环境（第三方 Recovery 或者设备厂商提供的维护模式），此时系统服务全停，data 分区干净，可以直接整盘打包。这条路线的优势是"一次性解决"，system 和 data 都能在同一个环境里备份，一致性有保证。

代价是需要设备支持进入这类环境，部分机型门槛较高；而且恢复环境自带的工具集可能比较精简，tar的参数支持不一定完整，尤其是 SELinux 上下文相关的选项，要先--help看一眼。

3.3 运行状态下的文件级归档

在系统正常运行时，用 root shell 做文件级归档，这是最灵活的方案，适合日常增量备份和跨设备迁移。

# 在设备端执行，归档 system 目录树（需 root） cd / && tar --selinux -cpf /data/local/tmp/system_files.tar system/

这里--selinux是关键，它会把每个文件的安全上下文一并存进归档。少了这个参数，恢复出来的文件上下文全是默认值，系统服务会大面积启动失败——这个现象很有迷惑性，因为文件明明都在，权限看着也对，就是起不来。

归档 data 时同理，但要排除一些不需要的东西：缓存目录、临时文件、以及可选的/data/media。

cd /data && tar --selinux -cpf /data/local/tmp/data_core.tar \ --exclude=./media \ --exclude=./local/tmp \ --exclude=./dalvik-cache \ --exclude=./cache \ ./

排除dalvik-cache是个人习惯，它会在系统首次启动时自动重建，没必要占备份体积。/data/local/tmp也要排掉，因为你的输出文件很可能就在里面，不排除会陷入自我包含的死循环。

3.4 三条路线的横向对比

我的默认组合是：system 走块设备直读，data 走文件级归档，重要节点再加一次恢复环境的整盘快照做兜底。三层下来，基本没有还原不回去的情况。

4. 完整实操流程

下面这套流程我反复用过很多次，性能稳定。命令里的分区路径用的是示例值，你执行前必须换成自己设备上的真实路径，这一步千万别偷懒。

4.1 环境确认与设备连接

先确认设备和连接状态正常。

adb devices adb shell getprop ro.build.version.release adb shell getprop ro.product.cpu.abi

第一条确认设备已被识别，第二条看系统版本，第三条看架构。架构这个信息在你后面需要把镜像转成稀疏格式时会用到——不同架构对应的转换工具不一样。

进入 root shell 确认权限：

adb shell su id

输出的 uid 应该是 0。如果不是，说明 root 环境没起作用或者授权没通过，后面的所有操作都做不了。这时不要硬往下走，先把权限问题解决。

4.2 摸清分区路径和挂载状态

这一步是整个流程里最重要的勘查环节，多花五分钟不吃亏。

# 列出所有命名分区 ls -l /dev/block/bootdevice/by-name/ 2>/dev/null ls -l /dev/block/by-name/ 2>/dev/null # 列出逻辑分区映射 ls -l /dev/block/mapper/ 2>/dev/null # 查看当前挂载情况 cat /proc/mounts | grep -E "/system|/data"

看到输出后，逐项确认：system 对应的块设备节点是什么、data 对应的是哪个、有没有 A/B 槽位后缀、是不是逻辑分区。把确认好的路径用纸笔或者记事本记下来，后面所有命令都基于它。

顺手确认一下分区大小，用来核对备份文件是否完整：

cat /proc/partitions

或者直接查块设备信息：

blockdev --getsize64 /dev/block/bootdevice/by-name/system

这个数值除以 1024 三次，就是多少 GB。备份完成后对比一下产物大小，对得上才算完整。

4.3 system 分区镜像备份（流水线直出）

我偏好不在设备上落地，直接推到电脑。

# 在电脑端执行，把镜像直接写到本地磁盘 adb exec-out "su -c 'dd if=/dev/block/bootdevice/by-name/system bs=4M 2>/dev/null'" > system_$(date +%Y%m%d).img

exec-out和shell的区别值得说明：shell会对输出做换行符转换处理，二进制数据经过这种转换会被破坏；exec-out原样透传字节流，是传二进制数据的正确选择。这个细节不注意，拉回来的镜像大小会莫名其妙多出几个字节，写回去直接开不了机。

如果设备上有足够空间、想留一份在本地，可以先落盘再拉取：

adb shell "su -c 'dd if=/dev/block/bootdevice/by-name/system of=/data/local/tmp/system.img bs=4M'" adb pull /data/local/tmp/system.img ./system.img adb shell "su -c 'rm -f /data/local/tmp/system.img'"

拉完立刻删掉设备上的副本，那地方空间紧张，忘了删会影响到后续操作。

如果分区比较大，或者你想省空间、省传输时间，可以边读边压缩：

adb exec-out "su -c 'dd if=/dev/block/bootdevice/by-name/system bs=4M 2>/dev/null | gzip -1'" > system.img.gz

gzip -1用最低压缩级别换取最快速度。system 分区里有相当多的空白区域和重复内容，压缩率通常不错，实测能压到原体积的一半甚至更低。压缩级别我一般不设太高，因为-9花的时间可能是-1的好几倍，收益却只多几个百分点，不划算。

4.4 data 分区的双轨备份

data 我分两步走，先是核心数据归档，再视情况决定要不要做块级快照。

第一步，文件级归档。这里要注意一个路径技巧：不要在归档时带上绝对路径，否则解包时会覆盖到错误位置。

adb shell "su -c 'cd /data && tar --selinux --xattrs -cpf /data/local/tmp/data_core.tar --exclude=./media --exclude=./local/tmp --exclude=./dalvik-cache ./'" adb pull /data/local/tmp/data_core.tar

--xattrs保留扩展属性，对付某些把重要元信息存在扩展属性里的应用很必要。--selinux前面说过了，不再重复。

第二步，内部存储单独处理。这块数据量最大，但通常是照片、视频、下载文件，用文件同步的方式更合适：

adb pull /sdcard/Photos ./backup/Photos

或者用带断点续传能力的同步工具做增量，第一次全量之后每次只传变化部分，效率高很多。

第三步，如果确实需要 data 的块级镜像（比如要做完整的设备克隆），那就必须进恢复环境做，运行状态下做出来的镜像一致性没有保证。这一步的命令和 system 类似，只是目标路径换成 data 对应的块设备，输出体积会非常大，提前算好空间。

# 恢复环境下执行 dd if=/dev/block/bootdevice/by-name/userdata of=/external_sd/userdata.img bs=4M

注意这里的节点名字可能叫userdata而不是data，勘查时看清楚。

4.5 完整性校验：这一步绝对不能省

备份文件拉回来，第一件事是校验。我养成习惯是双端各算一次哈希，对比一致才认。

# 电脑端 sha256sum system_20250101.img # 设备端（如果保留了副本） adb shell "su -c 'sha256sum /data/local/tmp/system.img'"

用流水线直出的话，设备端没留副本，那就换一种方式：在读取的同时让哈希跟着流走。

adb exec-out "su -c 'dd if=/dev/block/bootdevice/by-name/system bs=4M 2>/dev/null | tee >(sha256sum >&2) >/dev/null'" > /dev/null

这个写法比较绕，实操中更简单的做法是读两遍：第一遍只算哈希，第二遍拿数据，两边比对。第二遍慢一点但省心。

# 第一遍：算设备端哈希 adb shell "su -c 'dd if=/dev/block/bootdevice/by-name/system bs=4M 2>/dev/null | sha256sum'" # 第二遍：拉数据 adb exec-out "su -c 'dd if=/dev/block/bootdevice/by-name/system bs=4M 2>/dev/null'" > system.img # 第三遍：算本地哈希 sha256sum system.img

两个哈希一致，说明传输链路没有损坏。这比"文件大小对得上"可靠得多——大小对得上但中间某段被改了一个字节，这种事在 USB 传输里是真会发生的。

除了哈希，还要核对文件大小和分区容量。如果用了压缩，先解压再核对。

gzip -dc system.img.gz > system.img stat -c%s system.img

得到的字节数应该等于 4.3 节查到的getsize64结果。

4.6 归档保存与命名规范

备份文件的命名很重要，尤其是你以后会有十几份的时候。

我用的格式是分区名_槽位_系统版本_日期_哈希前八位.img，例如system_a_14_20250101_3f8a2c1d.img。哈希前缀不是炫技，是为了以后文件多了、名字被改过了，还能快速确认这是哪一次生成的产物。

存放上，至少两份，其中一份离线。备份文件里包含账号信息、通讯录、聊天记录，务必加密。我一般用压缩工具自带的加密功能打成加密归档，密码单独记在别的地方，不要和文件放在一起。

5. 踩过的坑和排查思路

下面这些全是我实际遇到过的问题，按出现频率排。

5.1 权限被拒与只读文件系统

最常见的报错是dd: /dev/block/...: Permission denied。九成原因是 root shell 没真正起来。先id确认 uid 是 0，再检查是不是 SELinux 处于强制模式拦住了块设备访问。临时放宽策略可以用：

getenforce setenforce 0

但注意这会影响系统整体安全状态，只在你确认环境可控、操作完立刻恢复的前提下用，操作完setenforce 1改回去。

另一种情况是Read-only file system。这通常发生在你往/system这类只读挂载点上写文件。解决办法是先重新挂载成可写：

mount -o remount,rw /system

不过我要强调：不要为了备份去改挂载状态。备份是读操作，根本不需要写权限。你如果是为了恢复到/system目录树才需要可写挂载，那属于恢复环节，先想清楚再动。

5.2 空间不足与稀疏文件

No space left on device这个报错我至少遇上过七八次。每次都发生在"以为空间够"的时候。

计算空间要留余量。一个 system 分区报出来 3GB，dd出来就是 3GB，加上文件系统开销、临时文件、日志，实际需要至少 3.5GB 可用空间。data 分区同理，而且它体积是动态增长的，备份过程中应用还在写日志，实际占用可能比你预想的大。

排查时先看真实可用空间：

df -h /data /data/local/tmp

注意df报的可用空间和dd能用到的空间不完全一致，因为文件系统有预留块。我的经验是留 20% 余量比较保险。

另外提一个省空间的技巧：如果目标分区大部分是零字节，dd出来的镜像会有大量连续的零。转成稀疏镜像能大幅减小体积：

img2simg system.img system.simg

转换后体积可能只有原来的三分之一。恢复时先用simg2img转回普通镜像，再写回。这个工具在部分环境里需要单独装，先确认是否可用。

5.3 备份中断与校验失败

传输到一半线松了、USB 口接触不良、电脑休眠，都会导致镜像残缺。表现是哈希对不上，或者文件大小比预期小。

排查顺序：先对比文件大小和分区容量，如果大小就不对，直接重来，没什么好查的；大小对但哈希不对，说明传输过程有字节损坏，也重来。

真正要查的是"为什么会断"。我的经验里，原因集中在三处：数据线质量差、USB 口供电不足、电脑端省电策略把 USB 设备挂起了。前两个换线换口，第三个去电源管理里把"允许计算机关闭此设备以节约电源"关掉。这个设置坑过我一次，2GB的镜像传到 1.8GB 断了，折腾半天才发现是省电策略干的。

5.4 恢复之后起不来：上下文与校验

这是最折磨人的一类问题，因为现象和原因隔得远。

现象一：恢复完 system 镜像，开机卡在启动动画。大概率是完整性校验没过。你写回去的镜像和当前系统期望的哈希不符，启动流程拒绝继续。处理方式取决于设备，通常需要一并在维护环境里处理相关标志位，具体操作各机型差异很大，动手前务必查清楚自己设备的方案，别照抄。

现象二：用 tar 恢复了 data，应用大面积闪退、系统服务起不来。十有八九是 SELinux 安全上下文丢了。验证方式是看某个文件的上下文：

ls -Z /data/data/com.example.app

正常应该显示类似u:object_r:app_data_file:s0:c...的内容。如果显示的是u:object_r:unlabeled:s0或者全问号，那就是没恢复上下文。

修复方式有两种。如果是打包时就带了--selinux，直接重新解包即可；如果是打包时漏了，可以在解包后对整棵目录树执行一次上下文重标记：

restorecon -R /data/data

这个命令会根据系统策略文件重新给每个文件打上正确的标签。执行时间会长一点，但比逐个手工设要可靠。

现象三：恢复后应用能启动但读不到自己的数据。这是所有者或权限位不对。归档时如果没保留属性，解包出来的文件 uid/gid 全变成了执行解包操作的那个用户，而 Android 上每个应用的数据目录属于独立的 uid。查一下：

ls -ln /data/data/com.example.app

正常情况目录所有者的数字 uid 是这个应用被分配的值。如果全变成了 0（root），那数据目录和应用的 uid 就对不上，应用自然读不了。这时候要用归档工具的解包保留属性选项重新解一次，手工改chown的活儿量太大，不现实。

5.5 常见问题速查表

6. 几个提高成功率的实操习惯

聊几个不属于"标准流程"、但确实让我少踩坑的习惯。

先做小样本验证。动大分区之前，先拿一个几MB的小分区试一遍完整流程——读、传、校验、写回、验证启动。这条链路跑通了，再上 system 和 data。我刚开始折腾的时候嫌麻烦跳过这步，结果在一个 4GB 的 system 上翻车，前面所有时间全废。

把命令写成脚本。手工敲容易漏参数，尤其是--selinux这种关键选项。写成脚本固定下来，每次调用只改分区路径和输出文件名，出错概率陡降。脚本里加一行set -e，任何一步失败立刻停下，不要带着错误往下走——备份流程带错前进，最后得到的往往是"看起来成功"的废文件。

记录环境的完整快照。除了备份文件本身，额外存一份环境信息：系统版本号、安全补丁级别、分区布局、槽位状态、备份时间点。用getprop把相关属性导出来存成文本文件，和镜像放在一起。以后要恢复的时候，光看文件名你根本想不起当时是什么环境，这些记录能救命。

恢复前先验证备份可用性。备份做完当场不验，等真出事才验，是自找麻烦。验证方式不用真写回，把镜像挂载到电脑上看一眼目录结构是否完整，把归档包tar -tf列出文件清单数一数条目数对不对，这些都是分钟级的事。

留一条退路。在改任何东西之前，确保设备至少还有一条能进入维护环境的路径、或者一个可用的官方恢复手段。这条路堵死了，你就只能靠祈祷了。

最后说个我自己的体会：备份这件事的成本从来不在"做"的那几分钟，而在"想到要补哪一块"。我第一次完整折腾这套流程的时候，自以为备份得很全面，结果恢复的时候发现漏了内部存储，照片全没了——技术上不算失败，块级镜像完整得很，但实际价值大打折扣。后来每次动手前，我都会先问自己一句：如果现在设备坏了，我拿这套备份能回到几成？问清楚了再动手，比事后补救划算得多。