写在开始
2024-09-25凌晨五点,我睡得正香,蛆厂的服务器被无缘无故的ban了,说什么DD系统逃脱KVM监管,我真是服了,系统是他官网原装的CentOS 7.9,自己装了个vnc,三四个月都没出事,突然给我ban了,关键是这个服务器肩负了几个重任:第一个是实验室管理系统的隧道搭建在那台服务器上,第二个是武汉的几台服务器的隧道在那上面,几个人靠这个ssh呢,第三个是,我所有的博客数据都在那台服务器上。
蛆厂就是蛆厂,半天也找不到人,下午有人回了,一口咬着我有问题,真是一脸懵逼,早上五点封我机器?后来我给客服看了docker应用,他便一口咬定是我挂了梯子的问题,我真是服了,我只是在docker的miniflux中个挂了个局部的clash,直接定了死罪。我想封了就封了吧,跪着求求让他解封吧,我里面还好多数据,一开始还说能解开,然后这客服说,没办法解开,解开什么是毫秒级的识别又被封。我心想:完了,我的数据,卧槽,拿不出来了?更搞笑的是:香港的那台不是“毫秒级的识别”,常州的那台又是“毫秒级的识别”,我的内心:?,在反复询问下,就是不能把数据拿出来,内向逐渐丧失希望,最后彻底心灰意冷。
我想到之前每天凌晨0:30会自动备份一次数据库,博客的一些文件,比如图片也是备份到webDav中,webDav是我自己部署的cloudreve系统,是每天凌晨0:40自动执行,但cloudreve系统在我自己的电脑中,之前放在地大的实验室那边确实每天都开着,每天都备份,但是到了安理这边,放在了住的地方,住的地方电费是要自己出的,这就导致我舍不得24小时开着那台电脑,而最近睡得有比较早,0:40还开着电脑(电脑开着cloudreve服务自动会开)的概率非常小,这就导致近期自动备份的可能性大大下降了,万念俱灰的情况下,我于2024-09-25的晚上打开了我的电脑,寻找了以下上次备份的文件(保留三份备份文件),惊奇的发现,最近一次备份居然是2024-09-23,我突然记起来我2024-09-23凌晨因为喝了咖啡而睡不着写代码写到了凌晨五点,这使得这一天成功备份了博客的所有数据,而2024-09-23到2024-09-25期间似乎也没发什么内容,说说内的最后一张图片是2024-09-21发的,唯一在这两天内发的,是《我们能够预测种群未来演化的演化趋势吗?》文章中的一张图片,和《分享一个自己开发的Typecho访问日志插件VisitorLogger》中的一个ZIP压缩包,这让我激动不已啊!这份名为:“web_www.maisblog.cn_20240923_004002_MDtlKy.tar.gz”的文件,拯救了我几个月的心血,让我“死而复生”!由此可见,备份的重要性,尤其是自动备份的重要性。言归正传,我们来谈谈怎么对Typecho博客进行自动备份。
Typecho博客数据的自动备份
众所周知,Typecho博客的数据包含数据库数据与一些文件数据,数据库数据是重中之重,它记录了我们几乎所有的博客的内容,孕育的博客内容全部存于其中,一旦数据库丢失,所有的努力将付之一炬;文件数据保留着Typecho的工程内容,包含主题、插件、用户上传的一些文件,图片等。如果没使用别的网络图床,一旦文件数据丢失,则文章中所有的图片将全部丢失;包括插件、主题、修改后的Typecho源码,也会全部丢失。所以对含数据库数据与文件数据的备份都是非常重要的,特别是数据库的备份。
数据库的备份
由于数据库所占用的空间相对于文件数据小得多,我运行了3个月的博客数据库占用空间才711Kb,完全可以使用邮件的方式每日进行备份。
1. 配置AutoBackup插件
由泽泽社长重新维护的AutoBackup插件可以完美的做到这一点,下图可以看到,可以设置SMTP进行邮件的发送(不知道如何设置的请自行搜索),同时可以选择备份的数据库,全选即可。
2. 设置定时备份数据库任务
设置完“定时任务接口秘钥”后,我们可以得到一个定时任务接口,访问这个接口,便会执行备份任务,我们下一步要做的就是使用一些执行定时任务的工具定时访问这个接口,拿宝塔面板为例,选择计划任务,然后添加任务,任务类型选择Shell脚本,任务名称自填,执行周期自选,执行用户选root,脚本内容填写:
curl -k [AutoBackup提供的接口]
比如:
curl -k https://www.maisblog.cn/index.php/autobackup?taken=XXXXXX
测试执行后,如果能够收到备份邮件,说明大功告成。
文件数据的备份
文件数据相比数据库来讲,要大得多,如果博主积极维护的话,博客的运行时间越长,所占存储空间几乎是线性增长。我运行100天的博客,每天大约以2~3MB的速度增长(我喜欢发一些图片动态),现在所占用的存储空间大概是400Mb左右。这么大的文件使用邮件发送是不切实际的,邮件服务器也不会让我们如此白嫖。如果直接备份到部署博客的服务器,又显得多此一举了,源服务器一炸,管你备没备份,照样全军覆没。所以备份到源服务器之外别的介质是最理想的。
第一种是自动备份到一些服务可靠的大厂网盘,比如百度云盘、夸克网盘、阿里云盘,这些网盘麻烦,首先,这些网盘不支持WebDav,要去寻找和了解这些网盘的上传接口(且不知道有没有),学习成本很大;其次这些网盘下载限速,没有会员只能看着20Kb/s的下载速度头疼。第二种是自动备份到自部署的网盘,这种方式可行,像如Cloudreve此类自部署的网盘都支持WebDav对文件进行操作,但缺点就是需要自部署,部署起来虽然不费劲,但是也有一些门槛,为了保障数据的完全可控可靠,需要有一台区别于博客源服务器的本地计算机,如果要实现自动备份,这台计算机还需要实时开机,成本太大。第三种是自动备份到支持WebDav的网盘,支持WebDav的网盘数量比较少,也比较小众(可能是在国内比较小众),有博主2023年专门对支持WebDav的网盘进行了对比测评,经过我的更新后,大致对比如下表所示,我们可以看到大部分容量都比较小,我了解了一下,坚果云的付费服务是42G存储空间需要199元/年,价格高昂。此时从表中可以观察到一个鹤立鸡群的网盘:InfiniCloud,InfiniCloud是一款支持WebDAV同步并且无需魔法网络即可访问的日本网盘。免费用户默认20G永久空间,输入注册码还能得到5G,网盘提供的带宽为200M,薄纱百度云这些“无良”商家。如果博客内容不是特别大的话,完全可以使用InfiniCLOUD对博客文件系统进行备份,本文使用InfiniCLOUD实现对博客内容自动备份。
名称 | 免费容量 | WebDAV地址 |
---|---|---|
坚果云 | 1GB | https://dav.jianguoyun.com/dav/ |
Dropbox | 2GB | https://dav.dropdav.com/ |
box | 10GB | https://dav.box.com/dav |
InfiniCLOUD | 25GB | https://XXXX.teracloud.jp/dav/ |
4Shared | 15GB | https://webdav.4Shared.com |
PowerFolder | 5GB | https://my.powerfolder.com/webdav |
CloudMe | 付费 | https://webdav.cloudme.com/XXXXXX |
iDriveSync | 5GB | https://dav.idrivesync.com/zotero |
Yandex Disk | 10GB | https://webdav.yandex.ru |
Koofr | 2GB | https://app.koofr.net/dav/Koofr |
MyDrive | 100M | https://webdav.mydrive.ch |
Memopal | 3GB | https://dav.memopal.com/ |
Storage Made Easy | 5GB | https://webdav.storagemadeeasy.com |
FileAnywhere | 付费 | https://webfolder.filesanywhere.com |
iCloud | 5GB | http://iCloud.com/en/webdav |
1. 注册InfiniCLOUD
首先自行注册InfiniCLOUD,验证邮箱后,可以获得20GB的永久免费空间,然后填写邀请码:HJVD3,会获得5GB的永久免费空间(填写这个码,我也会获得2GB的有效期1年的空间)。注册完成后,进入个人页面,将App Connections勾选上,勾选后会生成一个密码,这个密码只会显示一次,所以一定要保存下来,做完了上述的操作后便是打开了WebDav功能,记住你的WebDav的Url与账户密码。
2. 运行自动备份脚本
回到博客服务器,选择一个合适的位置,创建一个Shell脚本,内容如下,根据提示修改配置选项,运行该脚本即可实现备份到InfiniCLOUD的功能,这个脚本默认保留SAVE_COUNT份备份在你的博客服务器中。
执行成功后会输出以下消息:
# 文件压缩过程
adding: www/wwwroot/www.maisblog.cn/ (stored 0%)
adding: www/wwwroot/www.maisblog.cn/var/ (stored 0%)
...
Folder /www/wwwroot/www.maisblog.cn compressed to /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240928131601.zip
# 文件压缩上传过程
Starting to upload file /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240928131601.zip to https://XXXX.teracloud.jp/dav/maisblog_backups/
0.0%
####### 10.0%
###################################### 52.8%
######################################################################## 100.0%
File /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240930122816.zip uploaded successfully to https://XXXX.teracloud.jp/dav/maisblog_backups/
# 如果本地备份数量 > SAVE_COUNT,则会输出删除消息
Deleted old backup file from WebDAV: https://XXXX.teracloud.jp/dav/maisblog_backups/www.maisblog.cn_20240928124005.zip
Deleted old backup file: /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240928124005.zip
----------------------------------------------------------------------------
★[2024-09-30 12:32:02] Successful
----------------------------------------------------------------------------
如果你的服务器空间不足,你可以选择备份文件不在博客所在的服务器保存,只保存在InfiniCLOUD中,你需要把脚本替换为以下内容,请注意:已经存在博客服务器备份数据需要您手动删除。
执行成功后会输出以下消息:
# 文件压缩过程
adding: www/wwwroot/www.maisblog.cn/ (stored 0%)
adding: www/wwwroot/www.maisblog.cn/var/ (stored 0%)
...
Folder /www/wwwroot/www.maisblog.cn compressed to /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240928131601.zip
# 文件压缩上传过程
Starting to upload file /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240928131601.zip to https://XXXX.teracloud.jp/dav/maisblog_backups/
0.0%
####### 10.0%
###################################### 52.8%
######################################################################## 100.0%
File /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240930122324.zip uploaded successfully to https://XXXX.teracloud.jp/dav/maisblog_backups/
Deleting local backup file /www/backup/site/www.maisblog.cn/www.maisblog.cn_20240930122324.zip
Fetching list of backup files from WebDAV
Backup files on WebDAV:
www.maisblog.cn_20240930121316.zip
www.maisblog.cn_20240930120419.zip
www.maisblog.cn_20240930001001.zip
www.maisblog.cn_20240930115744.zip
www.maisblog.cn_20240930122324.zip
# 如果云端备份数量 > SAVE_COUNT,则会输出删除消息
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Deleted old backup file from WebDAV: https://XXXX.teracloud.jp/dav/maisblog_backups/www.maisblog.cn_20240930120419.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Deleted old backup file from WebDAV: https://XXXX.teracloud.jp/dav/maisblog_backups/www.maisblog.cn_20240930115744.zip
----------------------------------------------------------------------------
★[2024-09-30 12:32:02] Successful
----------------------------------------------------------------------------
3. 设置定时自动备份文件系统任务
上述备份需要手动执行,要实现自动备份,要做的就是使用一些执行定时任务的工具执行该脚本,同样以宝塔为例,选择计划任务,然后添加任务,任务类型选择Shell脚本,任务名称自填,执行周期自选,执行用户选root,脚本内容填写为上述脚本即可。看到这里,大家就能理解了,整个过程就是把文件夹压缩上传到WebDav网盘中,不光是博客可以这么备份,所有的数据都能以这种方式进行备份。
Typecho博客的恢复
恢复就不细讲了,大致分为两步,第一步是恢复数据库,创建一个与原来相同名称的数据库,账号密码也尽量一样,可以少改设置,然后导入数据库即可;第二步,将备份的文件夹放到指定路径解压即可。如果有主题参数,看你备份没备份在数据库中,比如handsome主题就可以备份在数据库中,然后恢复的时候可以从数据库中一键恢复,如果没有备份,只有重新再设置了,不过这都是小事。
如果有宝塔面板,就会更方便,直接再数据库界面,添加数据库,建立原来相同名称的数据库,账号密码设为也一样,然后点击导入,从本地上传,再点击导入即可导入博客数据库。
写到最后
最后经过数据库的还原、文件的还原,发现,确实仅仅丢了上述两个内容,这真是不幸中的万幸了。这件事彻彻底底让我知道了备份的重要性,干什么事情都要 备份 备份 备份!还有就是千万不要贪便宜买小厂的云,产品质量没有保障,一天断线七八次,服务态度非常不好,真正的狗屎!这里点名批评“樱*云”,真是屎中屎,彻彻底底的垃圾。
2 条评论
为什么不试一试 git进行备份呢?,图文,数据都可以备份
倒是真没试过,数据比较大可以吗?带宽咋样