最近准备自己动手备份www服务器了
事情是这样式的：老婆的网站内容很有潜力，现在已然往事业方面在靠，这也是她的兴趣所在，往后还可以搞个NFT，网站本身以及里面的内容都可以养活我们。为此，我考虑以后申请顶级域名xxx.com给她的网站，看有没有对应的文化传媒公司愿意收购。
在此之前，内容的安全就要提上了议事日程了。我曾经遇到过两次云服务器宕机，因为连系统无法进入，所以恢复系统便是无从谈起。出这种情况唯一的办法就是利用早先的备份回滚系统，那么产生在备份之后的数据就无法挽回了。之前第一次遇到云服务器宕机是我自己的博客和SS服务器，没什么重要的文件也没花太多心思在上面，所以回滚就回滚了。最近一次是这个月，发生在4月21日也就是定期备份之后的十天，十天里老婆新文章发表了至少十篇全部丢失，文章每篇都有精美的图片，可惜现在都找不回了。
网站滚回到4.11那天的内容后我一脸无奈的给阿里云工程师一个可有可无的好评。没办法，毕竟自己才十天半月备份一次，中间丢了一个多礼拜的内容也没法怪别人，因为系统总会出问题，灾备是基本要求，灾备的冗余度和频率决定了损失的大小，问题在于我的灾备只有云端，频率半个月一次，这只适合小型博客，丢失文章是一定的，但是随着我们投入的时间和金钱越来越多，宕机一次的代价也是水涨船高。
异地灾备和频繁（及时）备份就是接下来的重点，然后才是www.xxx.com的上线是吧，不然网站太次了，浏览量也上不去。
备份交给服务器自己，备份前查看需要备份的节点，尽量节省有限的云服务器存储资源。
查询前20大文件：
du -a / | sort -n -r | head -n 20
在出来的结果里面，前20个最大文件中，有我备份的根文件两份(一个在新的17Gb在根目录
一个旧的5Gb在root名下的文件夹)和all-in-one帮我备份的wp-contents，这两个文件有些冗余和重叠，这导致一个根目录备份有18个Gb。每次备份，系统+备份文件就消耗掉44个Gb，因为all-in-one (ai1wm-backups)的5~6个Gb的内容，被弄出两份，也就是将近12Gb。如果在tar.gz整个系统的时候排除ai1wm目录不备份，然后把root文件夹下的就备份删除，这样就能省出10Gb以上。按照这个思路，我清除和排除一些文件和位置不备份， 最后备份出的整个tar.gz文件只有8Gb。