改坏一个站不可怕，改完发现退不回去才叫难受。网站修改这活儿，翻车的点八成不在技术难度上，而在动手前那几分钟——原来那套东西有没有原样留一份。后台点两下、文件往上一盖、刷新一看样式全散了，然后满世界翻“之前那个版本”，翻得到算运气好，翻不到就只能熬夜重做。技术再硬的人也怕这个，因为不是能力问题，是顺序问题。
网站修改前，先定好“退回到哪一步”
我自己的习惯是动手前先问一句：要是十分钟后必须全部还原，我靠什么还原？答案一般有三块——文件、数据库，还有那些根本不在网站目录里的配置。三块里缺一块，这个“底”就是漏的，平时不觉得，真要往回退的时候才发现少了个角。很多人只想到第一块，把目录一打包就算交差，剩下的靠“我记得改过哪儿”——记忆这东西，改到第八个文件的时候基本就不可信了。
文件和数据库是两套账，时间点还得对上
整站目录打包这一步大部分人记得。但数据库呢？文章、用户、订单、后台设置项，全在库里。只留文件不留库，恢复出来是个空壳子；只留库不留文件，模板又对不上。更隐蔽的是时间差——文件是上午打的包，库是下午导出的，中间那几个小时发的文章、改的价格就丢了。所以要么两边一起做，要么清清楚楚记下各自的时间点，写在一个你三天后还找得到的地方。别写在聊天记录里，那玩意儿翻起来比翻日志还累。
那些“不在网站目录里”的东西最容易漏
nginx 或者 apache 的站点配置、.htaccess、伪静态规则、PHP 版本、crontab 里的定时任务、SSL 证书和私钥，再往外还有 DNS 那几条解析记录。这几样平时一点不显眼，动一下可能直接全站 502、白屏或者证书报警。我吃过亏，一次只改了个跳转规则，站点标题没变、路径没变，看着一切正常，第二天才发现某个栏目的入口全废了，回头找旧规则，早被覆盖。改之前把配置文件原样拷一份出来，截图也行，别指望自己记得那几行写的是什么。
复制一份不叫备份，能恢复才叫
备份文件躺在和网站同一台机器、同一个账号下，这种我见得太多。机器一挂，站点和备份手拉手一起走，谁也没救谁。至少往外挪一份，对象存储、另一台机器、自己的移动硬盘都行。挪完还要验证：包能不能解开、库能不能导进去、解出来的目录结构对不对。没验证过的备份只能算心理安慰，真要用的时候八成打不开。命名上加个日期和一句改动说明，一个月后你会谢谢当时的自己。
改的时候小步走，别一把梭
网站修改的顺序也有讲究。能先在测试目录、子目录或者临时域名上试的，就别直接在生产环境上动。一次只改一处：先把模板改完看正常，再动配置，最后才碰数据库。改完记得刷缓存，CDN 那一层尤其要刷，不然你以为没生效又改了一遍，越改越乱，最后连哪一步出的问题都说不清。顺手记一笔：动了哪个文件、几点动的、为什么动。就这几行字，出事的时候能省下半个通宵。
回滚这件事，得真练一次
备份勤快、回滚从来没试过的人大把。真要恢复的时候问题一个接一个冒：文件属主不对、目录权限没给够、数据库字符集不匹配、配置文件里写的是绝对路径而新位置压根不是那个路径。这些毛病备份的时候看不出来，只有恢复才现原形。找个不忙的时段，拿备份在临时位置真恢复一次，从头走到尾，把卡住的地方记下来。走一遍比多备三份都实在，因为你练的是手，不是运气。
啰嗦一圈，落到手上就那么几件事。动手前把整站目录打包，带上隐藏文件；数据库单独导出，顺手记下字符集和版本；nginx 或 apache 的站点配置、伪静态规则、crontab 各留一份；SSL 证书和私钥确认手上还有副本；DNS 那几条记录截个图。然后把备份挪到站点以外的地方，试着解开一次，最后想清楚从哪一步往回退。这些加起来撑死十几分钟，看着不产生任何价值，可一旦用上，它顶得上一个通宵，也顶得上你重新做一遍站。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
