简介Rancher平台部署与运维.docx是一份面向容器云运维与架构设计人员的实操手册围绕Rancher PaaS平台从环境规划到集群上线的完整流程展开涵盖Docker、Harbor、RKE及kubectl/helm等核心组件的部署与配置。资源为1个docx文档大小6.16MB内容以章节化目录组织便于按步骤查阅与落地。已有543人学习适合需要快速掌握Rancher部署与容器云环境搭建的运维工程师、DevOps人员及Kubernetes入门者。手册从软硬件要求、集群拓扑规划入手对比了开发测试环境与生产环境的Etcd/Control集群设计并给出时钟同步、Harbor镜像仓库安装与清理、Rancher实例部署、RKE集群搭建的详细步骤同时包含Dockerfile示例及镜像构建推送说明可直接参照在生产或测试环境执行。1. Rancher 平台部署与运维先想清楚它到底解决什么问题两套 K8s 集群摆在面前一套裸装一套套了 Rancher刚上手你会觉得差别不大等集群从 1 套长到 4 套、5 套研发天天找你要 kubeconfig、要 namespace、问你“服务起不来是不是集群又挂了”的时候差别就出来了。Rancher 平台部署与运维这件事本质不是“多装一个管理界面”而是把多集群的认证、权限、监控、应用分发收拢到一个控制面上。现在很多团队用 K8s 承载大模型推理和微调任务GPU 集群和业务集群同时存在Rancher 这类平台更成了刚需。这篇文章适合正在选型、准备部署或已经被多集群运维折磨过的工程师。我必须先说破一件事Rancher 的安装不算难真正的成本在后面的升级、证书、备份和排错。2. 部署 Rancher 前的架构选型RKE2 还是 K3s单节点还是高可用2.1 先看清三个层次Rancher Server、local 集群、下游集群部署 Rancher 前最容易被绕晕的是“Rancher 自己也得跑在 K8s 上”。Rancher 不是一个可以直接systemctl start的独立进程它本质是一组控制器和 Web UI运行在一个 K8s 集群里。这个集群用官方工具 RKE2 或 K3s 创建Rancher 装进去之后会在 UI 里管它自己住的这个集群叫local集群。很多人一看local以为是把业务放这里的这是一个会持续误导人的命名最佳实践是 local 集群只跑 Rancher 自身业务负载统统放到导入进来的下游集群。另一层关系是Rancher 管理下游集群时靠的是在下游集群里安装一个rancher-agent这个 Agent 主动连回 Rancher Server 的 443 端口。换句话说下游集群不需要暴露任何入站端口只有出站连通性要求。理解这三层之后你才能判断一次故障是哪一层引起的是 Rancher Server 崩了还是 local 集群的 etcd 出问题还是某个下游集群的 Agent 失联。这三层的故障边界非常清晰排查时不要一上来就趴在业务 Pod 日志里先分清是哪一层。2.2 RKE2 与 K3s 的选型边界RKE2 和 K3s 都是 Rancher 团队维护的 K8s 发行版但定位完全不同。RKE2 特意强调“合规”和“面向生产”默认集成 etcd、containerd、CoreDNS 和 Nginx Ingress镜像签名和安全基线做得更完整适合正式环境和受监管的业务RKE2 被社区称为 RKE Government注意它并不是 K3s 的新版本。K3s 主打轻量默认用 SQLite 也可以切 etcd内存占用低部署快适合边缘节点、IoT 和资源受限的场地。你如果只是在一台 2C4G 的机器上体验 RancherK3s 就够但凡是打算跑真实业务、要保证升级不翻车我一般会直接上 RKE2省得后面换底座时哭一场。还有一个选型细节Rancher 官方把 RKE2/K3s 都作为“内置发行版”在创建下游集群时可以直接选择由 Rancher 托管它们的生命周期。如果你自建的是标准 K8s、OpenShift 这类集群也能通过导入方式纳入管理但 Rancher 对它们的控制力弱一些比如节点池管理、一键升级这些能力就没有了。所以采购或者选型时先想清楚新集群用 RKE2 建、老集群外接导入这是一种常见且让我比较安心的组合。2.3 高可用部署的组件清单与资源估算不推荐单节点部署 Rancher 做生产。常见做法是搭一套三节点 RKE2 高可用集群外部用四层负载均衡把 TCP 443、6443 流量分发到三台 server然后再在集群里用 Helm 安装 Rancher。组件层面RKE2 已经内置了 etcd、kube-apiserver、kubelet 和 Ingress ControllerRancher 的 Helm chart 会额外带上 cert-manager或者你提供自有证书和 Rancher 自身的 controller、UI、API 服务。资源估算方面我不想只给你一个最低配置就把你带偏。Rancher Server 本体建议至少 4GB 内存生产环境按 8GB 起步更稳妥。三台 server 节点如果还要跑监控和日志采集单台 16GB 内存是舒适线CPU 方面一台 4 核起控制面负载不重但 API 请求多时会突然飙高。磁盘推荐单独的 etcd 盘SSD 至少 100GB日志和数据目录分开。表里面我觉得最值得注意的是证书更新和快照这两个需求建议预留 20% 的磁盘余量。高可用入口还需要一个 LB没有硬件 LB 就用 keepalived nginx 或者 MetalLB不要把 Rancher 的地址直接暴露在某一个节点的 IP 上后面节点挂了你会很被动。3. 用 RKE2 高可用方式部署 Rancher一步步落到命令3.1 准备三台节点的系统与网络节点建议用 Ubuntu 22.04 LTS 或 Rocky Linux 9这两套是我在 RKE2 上踩坑最少的系统。拿到机器后先做四件事同步时间、配 hosts、关 swap、调内核参数。时间不同步会导致 K8s 证书校验和 etcd 心跳出现神秘故障现象往往是节点间歇性 NotReady排查半天最后发现是时钟漂移。hosts 里要把三台机器的内网 IP 和主机名写全保证彼此互通。swap 必须关K8s 对 swap 的支持很有限开着容易让 kubelet 的内存判断失真。内核参数里net.ipv4.ip_forward必须为 1否则 Pod 网络转发不了。另外把fs.inotify.max_user_watches调大建议 1048576否则 etcd 和 Prometheus 这类组件跑一段时间后会因为 inotify 限制报错。可以直接用一个小的配置片段写进/etc/sysctl.d/99-k8s.confcat /etc/sysctl.d/99-k8s.conf EOF net.ipv4.ip_forward 1 fs.inotify.max_user_watches 1048576 fs.inotify.max_user_instances 1024 EOF sysctl --system这段配置的作用是让 Linux 内核允许 IP 转发同时放大 inotify 上限。你可能暂时感觉不到它的必要性但集群里 Pod 数量过百之后因为 inotify 资源耗尽导致 kubelet 无法 watch 文件变更的情况并不少见。IP 转发看起来只跟路由有关其实 flannel 或 Cilium 的 VXLAN/BPF 模式都依赖它。三台机器都执行后用sysctl net.ipv4.ip_forward验证一下输出是否为 1。另外防火墙放行规则也放在这一步确认好服务器之间 2379/2380etcd、9345RKE2 supervisor、6443apiserver要互通外部访问只需要放行 443。3.2 安装 RKE2 并搭建高可用集群每台机器上先执行 RKE2 的官方安装脚本第一台作为初始 server 节点后续两台通过相同的 token 加入组成三节点 etcd 集群。装之前准备好/etc/rancher/rke2/config.yaml这是 RKE2 的主配置入口把它写好能省掉后面大量麻烦。我常用的配置如下token: my-shared-secret-value tls-san: - rancher.example.com - 10.0.0.10 etcd-snapshot-schedule-cron: 0 2 * * * etcd-snapshot-retention: 7token是 server 和 agent 之间的共享密钥三台机器必须一致tls-san这个参数很容易被忽略它决定 apiserver 证书里包含哪些域名和 IP。如果你之后通过rancher.example.com访问 API而证书里没有这个地址所有客户端都会报证书校验失败而且这个错误在 K8s 里极具欺骗性。etcd-snapshot-schedule-cron和etcd-snapshot-retention是内置的 etcd 定时快照策略每天凌晨 2 点打快照、保留 7 份这一步相当于给集群控制面的数据上了后悔药强烈建议一开始就配上。配置文件写好执行安装curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPEserver sh - systemctl enable --now rke2-server.service mkdir -p ~/.kube ln -s /etc/rancher/rke2/rke2.yaml ~/.kube/config export PATH$PATH:/var/lib/rancher/rke2/bin kubectl get nodes第一条命令从官方入口拉取安装脚本INSTALL_RKE2_TYPEserver决定了安装的是 server 组件而不是 agent。命令执行后rke2-server.service会拉起整套控制面。后面三条命令是配置 kubectl 的访问凭证RKE2 安装时会自动生成rke2.yaml和使用者证书。需要注意的是默认的rke2.yaml里 server 地址写的是https://127.0.0.1:6443在第二、第三台节点加入后你要把本地 kubeconfig 里的地址改成集群的 LB 地址或第一台 server 的内网 IP否则远端操作会指向本机回环地址而无法访问集群。两台后续节点安装时在 config.yaml 里放相同的 token然后同样执行安装和启动命令。等三台都变成 Ready确认 etcd 集群状态正常kubectl get nodes -o wide /var/lib/rancher/rke2/bin/etcdctl \ --cacert/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \ --cert/var/lib/rancher/rke2/server/tls/etcd/client.crt \ --key/var/lib/rancher/rke2/server/tls/etcd/client.key \ endpoint health --clusteretcdctl endpoint health --cluster会依次探测集群内所有 etcd 成员返回is healthy才算过。这一步别省RKE2 安装失败的常见原因是 etcd 成员之间地址不通这时候看systemctl status rke2-server和journalctl -u rke2-server能快速定位。三个节点都 healthy 之后再把外部负载均衡的 443 和 6443 端口指向三台 server这些准备工作都为下一节安装 Rancher 或者将来跑大模型工作负载时的弹性扩展打好了底。3.3 在 K8s 上安装 Rancher用 Helm 一次装好Rancher 官方推荐用 Helm 安装。先装 cert-manager 作为证书签发组件再装 Rancher 本体。cert-manager 可以从官方 release 页下载对应版本的清单文件直接应用或者用 Helm 装。我这里用 Helm 一条链走完注意把version换成你选定且验证过的版本号helm repo add jetstack https://charts.jetstack.io helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager --create-namespace \ --set crds.enabledtrue helm repo add rancher-latest https://charts.rancher.io helm repo update kubectl create namespace cattle-system helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostnamerancher.example.com \ --set bootstrapPasswordAdmin2024 \ --set replicas3 \ --set tlsexternalhostname必须和证书 SAN 完全匹配也就是你前面在外网 DNS 里解析到 LB 地址的那个域名。bootstrapPassword是第一次登录 Rancher Web UI 时用的初始管理员密码这里建议用强随机串。replicas3让 Rancher 的三个副本分别调度到三台节点上避免一台故障导致控制台全挂。tlsexternal表示证书由外部 CA 签发此时 Rancher 不会自己申请证书你需要提前把 TLS 证书做成 Secret 放到cattle-system命名空间如果是测试环境把tls改成letsEncrypt或者直接用 cert-manager 自动签发会更省事。安装过程中最容易翻车的点有两个。一个是 helm 仓库里默认的 chart 版本与你当前 RKE2 的 K8s 版本跨度太大Rancher 对上游 K8s 版本有兼容矩阵建议装之前先看一眼 chart 的version和当前集群版本是否在支持范围内。另一个是bootstrapPassword如果含有$、反斜杠这类特殊字符即使加了引号shell 解释时仍可能出问题写成单独的文件里用--set-file会更稳妥。安装后先等一下等cattle-system命名空间下所有 Pod 变为 Runningkubectl -n cattle-system rollout status deploy/rancher kubectl -n cattle-system get pods -o widerollout status会阻塞到 Deployment 更新完成或超时这样你能明确知道安装是否成功。之后浏览器访问https://rancher.example.com用bootstrapPassword登录Rancher 会提示你修改初始密码并设置 Rancher Server 的访问地址。3.4 导入第一个下游集群Agent 是主动连回来的Rancher 的高可用部署本身只是第一步真实场景里你要往下游集群塞业务而“导入集群”这个过程是我见过误解最多的地方。在 Rancher UI 里选“导入现有集群”它会给你一段 kubectl apply 的命令本质上是在下游集群里去创建cattle-system命名空间、rancher-agent和一堆相关 CRDAgent 会主动向 Rancher Server 注册不需要下游集群对你开放端口。这里有一个架构上的安全点既然 Agent 是主动外连那你的下游集群只要能出网到 Rancher Server 的 443 就行尤其在混合云、跨机房的场景这比维护一堆反向代理要干净得多。导入之后在 UI 里看到集群状态为 Active 就算成功。如果一直处于 Connecting 状态多半是 Agent 访问不到 Rancher Server需要检查下游集群的网络安全组、代理设置以及 DNS 解析的地址是不是hostname对应的那个域名而不要看 UI 提示的临时 IP。另外Rancher 也支持直接从 UI 创建新集群底层调用 RKE2 或 K3s 的 provisioning API你只需要提供节点 IP 和 SSH 密钥但这要求节点能由 Rancher 所在网络直接访问和导入是两条相反的路径先搞清楚自己网络拓扑再做选择。4. 日常运维操作从证书到期到备份恢复4.1 证书管理是 Rancher 运维的第一根隐雷Rancher 部署完之后头号运维任务不是看 Pod 状态而是盯证书。整个链路里至少有三层证书RKE2 自签的 apiserver/etcd 证书、cert-manager 签发的 Rancher 访问证书、下游集群 Agent 与 Server 通信时用的客户端证书。任何一个到期表现都是早上到公司发现 UI 打不开、kubectl报证书错误。RKE2 的服务证书默认有效期一年它会在到期前自动轮换但如果你用了自定义 CA 或者手工改过证书文件这套自动流程可能会失效所以要主动监控。我检查证书的固定动作是看每个证书的剩余天数openssl s_client -connect rancher.example.com:443 -servername rancher.example.com 2/dev/null | openssl x509 -noout -enddate openssl x509 -enddate -noout -in /var/lib/rancher/rke2/server/tls/server.crt kubectl -n cattle-system get certificates第一条命令看浏览器实际访问到的证书什么时候到期第二条看 RKE2 内置服务证书第三条看 cert-manager 管理的证书资源。kubectl get certificates的输出里如果出现ReadyFalse不要犹豫直接看这个 Certificate 关联的 Order 和 Challenge 事件。常见的失败原因是 DNS 验证失败或者签发时依赖的 CA 不可用。解决时先看是不是域名解析问题再检查 cert-manager 的 Pod 日志。注意不要手动去改 Secret 里的证书内容后面会有控制器把它又改回来形成无限循环遇到这类情况去修 Certificate 资源本身这才是正规途径。4.2 备份与恢复分层备份才有后悔药很多人以为备份 Rancher 就是给 etcd 打个快照这是安全意识不足。Rancher 的所有配置数据集群定义、用户、角色、项目、全局设置都是存放在 local 集群里的 CRD 里etcd 快照当然能覆盖这些数据但等真出问题时你会发现从裸机重搭一套 RKE2 再恢复 etcd 的代价远高于先做 Rancher 层的配置备份。常见做法是两层备份都做RKE2 定时 etcd 快照保底Rancher 层用官方 backup-restore 插件把配置数据定期导出到对象存储。Rancher 的 backup 插件以自定义资源方式运行安装后创建一个 Backup 资源即可apiVersion: resources.cattle.io/v1 kind: Backup metadata: name: daily-rancher-backup spec: storageLocation: s3: bucketName: rancher-backup endpoint: minio.internal:9000 region: us-east-1 credentialSecretName: s3-creds resourceSetName: rancher-resource-set schedule: 0 1 * * * retentionCount: 30这个资源配置每天凌晨 1 点把 Rancher 的 CRD 配置数据打包推送到内网的 MinIO。注意endpoint写内网地址这个备份文件不应该经过公网里面包含 kubeconfig、密码哈希这些敏感信息访问 MinIO 的密钥要单独放在s3-creds这个 Secret 里。resourceSetName用内置的rancher-resource-set就行它已经预定义了需要备份的全部 CRD 类别和全局配置。恢复的时候在同一个命名空间里创建一个 Restore 对象指向备份文件名控制器会负责把整个配置状态还原并要求 Rancher 相关组件重新加载。这个流程我建议你在测试环境完整演练一遍别等线上出事才第一次尝试恢复恢复不演练等于备了个寂寞。4.3 监控与告警把这几条规则设好就不用天天盯屏Rancher 上传了内置的监控方案基于 Prometheus 和 Grafana。部署它之前先想清楚集群多了以后监控本身的资源消耗不小所以建议收割聚焦在关键指标上不要所有 exporter 都开。我个人最关注四件事节点内存和磁盘、etcd 健康状态、Rancher Server 证书剩余天数、备份任务是否成功。Prometheus 里可以内置告警规则阈值建议这样设监控对象推荐指标告警阈值节点磁盘node_filesystem_avail_bytes剩余空间低于 15%节点内存node_memory_MemAvailable_bytes可用内存低于 1GBetcd 写延迟etcd_disk_wal_fsync_duration_secondsp99 大于 2 秒持续 5 分钟证书剩余天数certmanager_certificate_expiration_timestamp小于 14 天备份状态Backup 资源状态连续 2 天未成功etcd 延迟这个指标我专门标红了它出问题比节点 CPU 满还难排查因为表现是 API server 响应慢、Pod 分配延迟、甚至 kubelet 心跳超时但看起来哪都不忙。监控可以解决大部分常态问题真正的排障功底还得靠基础的 Linux 命令比如df -h看磁盘、free -h看内存、ss -lntp看端口监听这套基本功在 Rancher 的集群节点上依然管用。你再看多少个仪表板最后定位的时候还是要落到这些命令上。4.4 升级 Rancher 的节奏和避雷路径升级是运维里最容易翻车的环节。先说顺序永远是先升级 Rancher chart再升级 RKE2最后升级下游集群的节点。这个顺序反过来就会出现新版本 Rancher 和旧版本 K8s API 不兼容、控制器报错、甚至控制面组件反复重启的情况。Rancher 官方对版本跨度有明确建议比如跨度较大的升级不能一次跳太多版本中间要过一个大版本。升级前先读一下目标版本的 release note看有没有破坏性变更。实操上我用的是 helm upgrade 加独立的 values 文件不推荐直接在命令行里加一堆--set。因为 Rancher 的 chart 参数很多散落的--set时间长了没人说得清哪些是自己设置的、哪些是默认的升级时容易带歪。用文件管理的话helm upgrade rancher rancher-latest/rancher \ -n cattle-system \ -f values-prod.yamlvalues-prod.yaml里集中记录 hostname、replicas、tls、ingress 这些关键配置升级前先 diff 一下新旧版本的参数变化。RKE2 那边升级时会自动从旧版本轮换证书需要确认磁盘空间充足。升级完成后检查一遍 Rancher 的 Pod 版本、kubectl get nodes的 K8s 版本以及下游集群的 Agent 是否都重新连接上。我自己的习惯是升级窗口放在业务低峰期升级前打一次备份出问题马上回滚到上一个 chart 版本这个后悔药必须提前准备好。5. Rancher 部署与运维常见问题排查5 个让我翻过车的坑5.1 UI 打不开提示证书无效或空白页现象浏览器访问 Rancher 地址出现证书告警或者页面转圈后一片空白控制台看不到任何内容。原因最常见是证书过期或证书 SAN 不匹配另外 Rancher UI 依赖的 Ingress 在某些升级后没有正确 reload。解决先用openssl s_client确认实际返回的证书是否过期再查kubectl -n cattle-system get certificates看 cert-manager 的状态是否 Ready。如果证书没问题看 Ingress 后端是否指向了正确的 Service改过 hosts 或域名后给 Rancher 的 Ingress 加一条注解让它强制重新加载。手动改了 Secret 里的证书但状态一直不恢复的注意看一下是否需要删除旧 Secret 让 cert-manager 重建而不是直接在原 Secret 上覆盖后者会被控制器回滚。5.2 etcd 成员显示不健康集群进入只读模式现象集群功能正常但 kubectl 执行写操作报错etcd 日志里出现 leader 丢失或心跳超时。原因磁盘写入延迟过高是头号原因特别是把 etcd 数据目录放在机械盘或者共享存储上其次是某台节点时钟漂移导致选举超时这是 K8s 里典型的“玄学”问题。解决先跑etcdctl endpoint health --cluster确认哪些成员不健康用chronyc tracking检查时钟偏差。磁盘慢就换 SSD迁移 etcd 数据目录前必须先把该节点从集群里摘除不要直接挪目录。时钟漂移的处理是重新同步时间并检查节点的 NTP 服务是否正常。不要试图在 etcd 不健康时强行重启全部成员那只会让数据不一致的问题雪上加霜。5.3 下游集群 Agent Pod 一直在 CrashLoopBackOff现象导入的集群在 UI 里状态是 ConnectingAgent Pod 反复重启日志里出现连接被拒绝或者 TLS 握手失败。原因最常见是下游集群的节点无法访问 Rancher Server 的 443 端口安全组或者防火墙没放行还有一个隐蔽原因是导入时用的 Rancher Server 地址是内网 IP而下游集群在外面访问不到。解决先从下游集群的节点手动curl https://rancher.example.com看连通性不通就放通网络或把地址改成公网可达的域名。再看kubectl -n cattle-system logs里 Agent 的具体报错如果是 TLS 证书校验失败说明 Agent 保存的 Server URL 和证书不匹配需要删除已创建的 Agent Secret 重新导入。重新导入会重置整个cattle-system命名空间不影响已有业务负载可以放心操作。5.4 节点内存长期高位Rancher 本身成了资源大户现象三台 server 节点内存一直 80% 以上明明业务集群的负载不重Rancher 集群却看起来很吃力。原因Rancher 控制器加上监控组件在集群数量多时内存开销确实不小但更多是没有设置资源 limitsPrometheus 和各个 exporter 把内存吃光了另一个容易被忽视的是 etcd 在堆外内存里缓存了大量 key。解决给 Rancher 和监控组件配置合理的resources.limits通过 values 文件控制把普罗米修斯的retention时间从默认的长周期缩到 7 天或者 15 天不需要的 exporter 直接关掉。另外 etcd 的内存与 key 数量成正比注意不要在一个集群里无节制地创建 namespace 和 CRD很多历史数据会占住内存。5.5 Helm 升级后 Rancher 配置被重置现象helm upgrade 后 Rancher UI 里的某些自定义配置丢了比如认证方式、全局设置、甚至集群的显示名称。原因升级时没有把之前用--set传过的参数补齐新版本 chart 默认值覆盖了你手改的配置。解决办法是前面说的用一个稳定的 values 文件管理所有关键参数升级前先helm get values rancher -n cattle-system把当前运行配置导出来和你准备升级的 values 做 diff确认没有字段被重置再执行升级。这类“配置漂移”问题在 Helm 管理的组件里非常普遍不只是 Rancher养成先用helm get values再升级的习惯能少踩很多坑。6. 进阶多集群策略管理和部署后的健康验证到了这一步集群已经在稳定运行日常运维也有了章法下一步值得投入的是策略级管理和验证。Rancher 自带 Fleet它把 GitOps 的思想内建到了平台里你可以把一个 Git 仓库里的应用定义通过 Fleet 批量下发到多个下游集群并对集群分组来做灰度。团队里如果再配合 Ansible 这类自动化工具做节点配置的下发基础设施即代码的链路就完整了。对于新建集群Rancher 的 Cluster Template 非常实用它允许管理员预置集群的版本、网络插件、etcd 快照策略等参数研发或者业务方用模板自助创建集群时没有权限改这些安全基线这比建完再检查要好得多。健康验证方面我每次部署完或者升级完都会跑一遍近乎固定的检查清单这里给你一个可以照着做的版本kubectl get nodes -o wide kubectl -n cattle-system get pods -o wide kubectl -n cattle-system get certificates kubectl get events --sort-by.metadata.creationTimestamp | tail -30四个命令分别回答了四个问题节点和 K8s 版本是否一致、Rancher 组件是否全部 Running、证书链是否 Ready、近期有没有异常事件。再配合前面提到的 etcdendpoint health --cluster这一套组合能覆盖大多数部署和升级后的健康状态。建议把它写成一个小脚本每周跑一次输出存日志而不是每次都手动敲人总会偷懒脚本不会。说到底Rancher 平台部署与运维这件事部署只是入场券持续的证书管理、备份演练和升级纪律才是决定你能不能安稳用下去的关键。我现在的习惯是每周一看证书剩余天数和备份任务执行情况每月在测试环境做一次恢复演练备份如果没验证过等于没有备份。这些习惯帮我避开了很多次潜在的事故希望帮到你。本文还有配套的精品资源点击获取
