这是一系列关于 NAS 的文章,系列的名称你们也看到了:「榨干这台 NAS」。我将尽可能详细的介绍 NAS 相关的知识,帮助你最大限度的发挥你的手中 NAS 的威力!
<!-- more -->又拖了一年,实在惭愧。今天来讲讲备份,这两天对于把 NAS 上的重要文件都做了备份,就顺便来写一下记录记录。
备份的重要性不言而喻,但是又只有当数据丢失时才会体会到它的重要。以下内容仅限于 NAS 上的文件备份,不包括手机和其他内容。大家可以定时先备份内容到 NAS 上。
备份是为了安全,安全分为两种,数据安全和隐私安全。
数据安全是指备份内容会不会丢失,损毁;而隐私安全是指你的备份数据会不会被窃取,被公开。对于数据内容的不同,两者的重要性也不一样。
一般较为简单的方式就是拷贝一份到别的盘或文件夹上。这就是内部硬盘(Internal HDD)备份方式。这种方式优点是:
备份快捷方便,只要定时复制一份就好;
成本较低,在现有硬盘空间富裕的情况下,无需多余的费用;
当然,其缺点也是显而易见的:
同盘备份容易受损或感染,例如前几年开始流行的勒索病毒,它可以感染整台设备的上的文件,无一例外的你的备份也将无法幸免;
空间是有限的,在需要备份的文件过大时,对应所需的硬盘空间也会变大。
这种方式兼顾了内部硬盘备份的方便,又保证了一定程度的安全,一般来说这也叫冷备份。方式是将需要备份的数据拷贝一份到 U 盘,移动硬盘,机械硬盘或光盘等存储介质上。并在备份完成后断电保存。其优点有:
单次备份较为快捷,在进行一次性的备份时较为方便;
支持异地备份,由于可移动的性质,这种方式符合 「3-2-1 原则」 中的 1,即一份拷贝保存在异地,这样当发生例如火灾等险情时,可以保证异地备份的安全。
这种方式的缺点有:
对于频繁增加的数据来说,例如日常生活照片,要做到及时备份会有些困难;
需要购买额外的存储设备;
可移动存储媒介的不稳定性,例如 U 盘本身不适合做为长时间的冷备份,而机械硬盘对于存放条件要求又有些高。
这里介绍一下常用介质的使用场景:
类型 | 特点和建议使用场景 |
---|---|
外部硬盘 | 大容量但体积大;易受物理损坏和退磁影响。 |
固态存储(SSD、USB) | 无机械部件,抗震耐用;价格高但寿命延长;常见于临时携带数据。 |
光盘(CD/DVD/Blu-ray) | 容量小,便宜但寿命有限;适用于长期离线存档。 |
磁带 | 超大容量且成本低;多用于企业长期备份。 |
软盘/ZIP盘 | 已淘汰,因容量太低且不再生产。 |
其实大家在生活中已经有过或多或少的备份行为,例如你把旅游的照片发了朋友圈,这是一种备份;你打开了百度云的照片自动备份功能;你购买并开启了各大手机厂商自带的云服务(iCloud)……这些都是备份。
备份本质上是把重要的数据的副本保存在其他地方,上述例子中的其他地方都是指第三方厂家的服务器。
这就是我们要说的第三种备份,我通称为云备份。云备份的优点有:
异地备份,服务器厂商位于各个不同城市的服务器机房,在采用多个厂商产品的备份下,完全可以保证异地备份这一项的安全性;
方便,无需购买多余存储设备,现在的云盘厂商,动不动 TB 起步的容量,完全够普通人的备份需求。
缺点也是有的:
依赖于网络,在第一次全量备份时,备份时间的瓶颈在上传带宽上,以目前家用的 50Mbps 上传带宽为例,如果需要备份 100GB 的数据,大概需要四个半小时。更不要说当找回数据时如果没开会员那十几 KB 的下载速度了;
隐私安全没有保障,毕竟存储在第三方的服务器下,还是会存在泄露的可能,例如阿里云盘曾经有过能看到其他人照片的恶性 bug;
存在厂商锁定风险,比如一些较为私密的照片非常有可能被某些云盘厂商封禁。
价格,这是毋庸置疑的,毕竟厂家也不是做慈善的,既然提供了服务,就必然需要收取一定的费用,例如会员费用,或者是 OSS 存储费用和流量费用。
接下来说说我这些年来的备份方法。
记得小时候充值 QB 的时候,需要去书报亭购买 QB 卡,而 30 元面值的 QB 卡背后会带有密保卡。
当有过一次丢失的经历后,我意识到这玩意需要个备份,这时候,我就用纸笔将其写在本子上,这就成了我的第一个备份。
但是不久之后,我遇到了问题,当我前往黑网吧时,我发现我没有将家中的密保卡带上,导致那天的我无法进入被密保卡保护的游戏。回家后,我立马将实体的卡片转录到了 Excel 上。
并将其存在了当时的 QQ 网络硬盘(腾讯微云的前身)上,这就是我的第一个云备份。
时代的记忆,当时的各类软件和工具,一般大家都是放在这里进行分享。由于我的最初账号已经丢失,实在是无法回忆起来当时存了什么东西。
只有百度百科还记录着零星的信息:https://baike.baidu.com/item/%E5%8D%83%E8%84%91。
后来,网盘产品如雨后春笋般出现,手机中的照片一般都是由各大网盘的默认推荐打开的自动备份功能所备份,各位可以去看看历史较为悠久的几家网盘,说不定还能在其中找到一些你觉得早已遗失的珍贵记忆。
在拥有了 NAS 之后,我的大部分文件都是会拷贝到 NAS 上一份作为一个备份。但是久而久之,在看过了网上各种硬盘损坏案例后,我开始对我这一张二手企业矿盘产生了怀疑:万一哪天坏了呢?
在刚有这念头的几天里,我显得十分焦虑,总觉得下一秒硬盘就会歇菜。尤其是想到那上万张照片可能会丢失,NAS 备份刻不容缓!
我需要备份的文件大致分为两部分,一是数量较多但是对隐私要求不高的照片视频文件;二是数量较少但是对隐私安全较为看重的数据,例如:Vaultwarden 密码数据、Teslamate 行程数据等等。
前者量大,我使用 Rclone 花了快一周时间才将其全部上传到阿里云盘。但是还是上传失败了好一部分,并且比较难确定是哪些遗失了。
后者量较少,但是对于安全保密性较高,我写了一个「导出-压缩-加密-上传-通知」的脚本,在 NAS 中以定时任务的形式每天进行全量备份。并且保存了近一年的历史备份。这对安全性要求较高的场景来说,不失为一个较为简单的方法,我将脚本分享在这里,大家改改应该就能直接用:
<script src="https://gist.github.com/AemonCao/89c6a3c4e1c53f643f101a0760a12f17.js"></script>需要注意的是上传部分使用了 AList 挂载了云盘,并使用 rclone 通过提供了 WebDAV 服务(照片部分的网盘上传也是通过这一途径)。
同上上述的脚本进行的备份,由于进行了压缩加密,可以在上传到第三方网盘的同时保证其隐私安全性,当然千万不要忘记压缩密码,不然数据虽在,但是可能永远都看不了了。
缺点也较为明显,只适用于较为小的文件备份,对于大文件的备份,由于需要加密压缩的原因,会导致最后压缩文件较大,不宜进行频繁备份。
这里再放上一个最近修改过的脚本,支持一次备份多个项目的文件:
<script src="https://gist.github.com/AemonCao/40f836abb1a9844499fa2fdb81a96c64.js"></script>以下就是我写这一篇文章的契机,在某一次冲浪时,接触到了一款叫 restic 的开源软件。在使用后我发现,它完美解决了第一版备份中遇到的问题。例如安全性保证,大量文件的增量备份,甚至它还能提供版本管理!称它为完美的备份软件也不为过。
当然事物都有其两面性,restic 是一款没有图形界面的工具,要想使用它得了解一些额外的知识。
当然事物都有其两面性,既然它这么好用,那说不定会有人为它开发图形界面呢?这就是今天的主角:Backrest。
官网是这么介绍它的:
Backrest is a web-accessible backup solution built on top of restic.
Backrest 是一个构建于 Restic 之上的可通过网页访问的备份解决方案。
通过 Backrest 我们就可以用较为简单的方式来使用 restic 备份文件。
我们可以通过 Docker 来安装 Backrest。安装命令如下:
docker run -d \
--name backrest \ # 容器名称
--net bridge \ # 使用默认的桥接网络模式
--pids-limit 2048 \ # 限制最大进程数为 2048
-p 9898:9898/tcp \ # 映射主机端口 9898 到容器端口 9898
-e TZ="Asia/Shanghai" \ # 设置时区
-e BACKREST_DATA="/data" \ # Backrest 数据目录环境变量
-e BACKREST_CONFIG="/config/config.json" \ # Backrest 配置文件路径
-e XDG_CACHE_HOME="/cache" \ # 缓存目录路径
-v /mnt/user/appdata/backrest:/config:rw \ # 映射配置文件目录
-v /mnt/user/appdata/backrest/cache:/cache:rw \ # 映射缓存目录
-v /mnt/user/appdata/backrest/data:/data:rw \ # 映射数据目录
-v /mnt/user/appdata/backrest/repos:/repos:rw \ # 映射备份仓库目录
-v /mnt/user:/backup:ro \ # 映射只读的备份源目录
-v /mnt/user/appdata/rclone:/root/.config/rclone:rw \ # 映射 rclone 配置目录
garethgeorge/backrest:latest # 使用的镜像名称
上述命令在使用时需要去除注释并按照自身情况修改映射的目录和端口。
需要注意的有:
-v /mnt/user:/backup:ro
这部分是只读(ro),当需要恢复文件时,这部分可以临时修改为读写(rw),或者挂载另外一个恢复目录,由于大部分时间还是读为主,所以这里为了源数据安全考虑,还是写成只读会好一些;
-v /mnt/user/appdata/rclone:/root/.config/rclone:rw
由于我的备份目的地是 rclone,所以这里需要传入 rclone 的备份文件,当在 Backrest 配置了目的地为 rclone 的仓库时,restic 就会从这里进行读取信息。
这时我们访问宿主机的 9898
端口,就可以看到 Backrest 的图形界面了。
你需要输入一个实例ID,并创建一个用户。
在 restic 中,保存备份的地方就叫做 repository。和 git 中的 repository 一样,它是一个目录,包含一些由 restic 创建的一级目录和文件。里面存储着你的备份文件、元数据以及加密密钥。
点击页面左侧菜单的 Add Repo (下图中 1 部分)即可打开创建仓库的表单:
首先输入仓库名称(上图中 2 部分),这部分不支持中文,也不支持空格,你可以按照备份目的地和备份内容来进行取名,比如我的备份目的地是 123 网盘,备份内容是 NAS 的文件,所以我的仓库名叫做 123CloudNASBackup。
然后是 Repository URI(上图中 3 部分),这是 restic 较为关键的部分,可以把他当作连接到备份目的地的地址,这一部分根据你实际的备份目的地的不同,格式也不同。下面是一些常用的备份目的地类型:
存储库类型 | 存储库 URL 示例 | 备注(字段含义) |
---|---|---|
本地文件系统 | /srv/restic-repo |
本地路径作为存储库 |
SFTP | sftp:user@host:/srv/restic-repo |
user 是用户名,host 是远程主机,路径为远程目录 |
REST 服务器 | rest:http://host:8000/ <br>rest:https://user:pass@host:8000/ <br>rest:https://user:pass@host:8000/my_backup_repo/ <br>rest:http+unix:///tmp/rest.socket:/my_backup_repo/ |
支持 HTTP/HTTPS 或 Unix socket;可包含用户名密码、端口、路径等信息 |
Amazon S3 | s3:s3.us-east-1.amazonaws.com/bucket_name |
s3.us-east-1.amazonaws.com 是区域端点,bucket_name 是存储桶名称 |
Rclone | rclone:foo:bar |
foo 是 Rclone 配置中的远程名,bar 是远程路径 |
可以根据你的实际情况来选择不同的备份目的地,比如我是通过 AList 挂载了 123 网盘,然后又通过 rclone 提供了 WebDAV 服务,这样我的仓库地址就是:rclone:AList:/123Cloud/NASBackup
。
之后就是密码(上图中 4 部分),之前 restic 是不允许创建无密码的存储库的,但是自从 restic 0.17.0 版本开始,允许创建无密码的仓库。但是为了安全起见,我们还是设置一个密码比较好,可以点击 Generate 按钮创建一个较为安全的密码(并且需要将其保存下来,因为这个密码会在后期恢复时用到)。
接下来比较重要的是 Prune Policy(上图中 5 部分),也就是修剪策略,简单来说,由于 restic 存在快照,如果在备份文件频繁变动的情况下,存储库的将会越来越大。我们可以删除部分过时的快照,而当快照被删除时,存储库中的就会有相对于的数据不再被使用,修剪(prune)功能就是用来清除这部分数据以最大化利用空间的。
修剪时比较占用时间和带宽(特别是在远程存储库时显得尤为重要)的,因为他会将数据从远程下载并在本地重新打包后再上传。
所以这部分我推荐时按照系统默认的设置即可。
之后是 Check Policy(上图中 6 部分),检查策略也尤为重要,这能及时发现存储库中的 [bit rot]https://en.wikipedia.org/wiki/Bit_rot)(比特腐烂)和 silent corruption(静默损坏),同样默认设置即可。
上述两项配置可以根据你的源数据更新频率以及重要程度,适当的缩短一下执行频率。
然后是 Command Modifiers(上图中 7 部分),这一项可以修改备份时的 IO 优先级和 CPU 优先级,IO 优先级分为:
IO 优先级选项 | 描述 |
---|---|
IO_BEST_EFFORT_LOW | 以低于默认磁盘优先级运行(将优先考虑其他进程) |
IO_BEST_EFFORT_HIGH | 以高于默认磁盘优先级运行(磁盘 IO 队列顶部) |
IO_IDLE | 仅在磁盘带宽空闲时运行(例如,没有其他操作排队) |
CPU 优先级分为:
CPU 优先级选项 | 描述 |
---|---|
CPU_DEFAULT | 优先级没有变化 |
CPU_HIGH | 高于默认优先级(后台必须以 root 身份运行) |
CPU_LOW | 低于默认优先级 |
大家可以根据 NAS 其他服务的运行情况来设置。
最后就是 Hooks,可以在不同状态下运行各类自定义的命令,支持的状态有:
条件常量 | 描述 |
---|---|
CONDITION_ANY_ERROR | 执行任何任务时出错 |
CONDITION_SNAPSHOT_START | 开始备份操作 |
CONDITION_SNAPSHOT_END | 备份操作结束(成功或失败) |
CONDITION_SNAPSHOT_SUCCESS | 备份操作成功结束 |
CONDITION_SNAPSHOT_ERROR | 备份失败结束 |
CONDITION_SNAPSHOT_WARNING | 部分备份结束 |
CONDITION_PRUNE_START | 修剪操作开始 |
CONDITION_PRUNE_SUCCESS | 修剪成功结束 |
CONDITION_PRUNE_ERROR | 修剪失败结束 |
CONDITION_CHECK_START | 检查操作开始 |
CONDITION_CHECK_SUCCESS | 检查成功结束 |
CONDITION_CHECK_ERROR | 检查失败结束 |
我的设置是在 CONDITION_SNAPSHOT_SUCCESS
,CONDITION_SNAPSHOT_ERROR
和 CONDITION_SNAPSHOT_WARNING
时发送一条 Bark 的通知。
然后点击 Submit 按钮,等待 restic 初始化存储库即可。
现在有了存储库,我们就要开始制定存储计划了。点击左侧 Add Plan 按钮(下图中 1 部分),即可开始创建备份计划。
首先还是设置一个计划名称(上图中 2 部分),我是按照备份内容来进行命名的,例如用来备份照片的我取名叫:PhotoBackup,用来备份 NAS 的 Docker 容器数据的叫做:NASAppdataBackup,总之能让自己看懂就行。
然后是选择一个备份存储库(上图中 3 部分),下拉选择刚刚创建好的那个存储库即可。比较可惜的是这里无法多选,如果想要备份到两个不同的存储库,就需要重新再建一个新的计划。
之后是备份路径(上图中 4 部分),可以选择一个或多个路径,选择你需要备份的目录即可,注意,如果像我一样使用 Docker 容器进行部署的,则需要先将备份的路径提前映射进容器,不然将无法选到。
路径是可以多选的,并且再以后也是可以随时进行修改的。
然后是选择排除规则(上图中 5 部分),例如你有一个文件夹,其中有 100 个子文件夹,而你想备份其中的 99 个,这时,你无需再上面 Path 中一一添加 99 个需要备份的文件夹,而是只需现在 Path 中添加其父文件夹,并在 Excludes 中填写不需要备份的文件夹即可。并且排除规则支持忽略大小写(上图中 6 部分),以及正则规则,详情可以查看官方文档。
Backup Schedule 代表备份频率(上图中 7 部分),可以选择禁用,这样系统就不会自动备份,需要你按需过来手动备份。也可以按照时间间隔备份,例如每小时备份一次,每 3 天备份一次,当然也可以使用 Cron 设置。我是设置在每天的凌晨 3 点来进行备份,这样不会特别影响家庭的网络。
最后就是 Hooks,这里的 Hooks 和上方存储库的 Hooks 一样,一般如果在存储库中配置过通知 Hooks,计划中就不需要再配置了。计划中的配置一般不以通知为主,而且某些特定的备份内容,例如一些程序的运行数据,这一般都需要先停止程序运行,然后再进行备份,在备份完成后再启动程序。
点击 Submit 按钮,计划就创建完成了。
然后,只要选择你想要备份的计划,点击蓝色的 Backup Now 按钮(下图中 1 部分),就可以手动启动一次备份,第一次由于是全量备份,备份的时间会比较久。但是 restic 有一个好处是,它支持中断后的继续备份,所以不论是手动停止还是异常断电,之后 restic 都能从上次停下的地方继续,而无需从头来过。
在备份完成后,将会生成一条快照信息(上图中 2 部分),页面上会显示快照所备份文件的大小,备份时长。
当我们点击这个快照时就你看到更加详细的快照信息,例如这次快照相较于上次快照添加了多少文件(上图中 3 部分),修改了多少文件(上图中 4 部分)。以及此次备份的日志信息(上图中 2 部分)和 Hooks 调用信息(上图中 5 部分)。并且可以忘记(删除)此次快照(上图中 1 部分)。
很遗憾你需要用到这一部分,但是也很庆幸还好有做备份。
我们需要点击你想要恢复的那个快照(上图中 1 部分),然后点击 Snapshot Browser(上图中 2 部分),并在其中展开你需要恢复的目录(上图中 3 部分)。点击目录右侧的下载按钮(上图中 4 部分),选择 Restore to path(上图中 5 部分)。
然后在弹出的对话框中选择你需要恢复的路径,点击 Restore,等待其恢复完成即可。
回顾自己的备份之路,从最早的手写笔记、QQ 网络硬盘,到后来的各种网盘服务,再到现在拥有了 NAS 和更系统化的备份方案,可以说每一步都是对数据安全意识的提升。也许早期的方式略显原始,但也正是这些尝试,促使我逐步建立起属于自己的数据管理体系。
在备份这件事上,没有「之后再说」这种选择。意外总是在你最没准备的时候发生,真正能救你的,只有那个已经默默跑了几个月甚至几年的备份计划。
无论你是普通用户、创作者,还是一个像我一样喜欢折腾的技术爱好者,都建议你尽早为自己的数据上点「保险」。哪怕只是一个简单的移动硬盘,也远比什么都不做来得强。随着需求增长,再逐步过渡到更强大、更自动化的方案,比如使用 NAS 和备份工具 Backrest 等。
数据无价,备份先行。希望我的经验能为你带来一点启发,也欢迎你分享你的备份故事。