NAS的数据管理，备份和使用

1. 总体介绍

我们需要先确定通过NAS我们要存储些什么。
只有知道要存储些什么了，才能制定更好的数据管理和备份策略。
根据我的需求，我主要存放下面三种类型的数据：

Docker容器中需要持久保存的数据。
需要自己编写处理的各类文档。
通过各种渠道收集整理的资源。

对于Docker容器，在通常情况下我是不会直接将其部署在NAS上的，而是部署在我搭建的k3s集群上。
这样做虽然可能会导致Docker提供的服务出现较高的延迟，但对我来说是值得的。
因为虽然通过QNAP的软件我们可以的在NAS上快速搭建k3s集群和部署Docker容器。
但这个工具使用起来还是有很多限制的，导致我无法对容器和集群进行细致化的配置,从而无法到达我自己想要的效果。
而且因为这些限制会导致我无法通过实践学到太多东西。
对于这样做带来的高延迟现象，我相信在我之后不断的学习和尝试下，能够逐渐解决。

而对于那些我自己编写和处理的文档来说，我想让NAS成为一个只用来集中存储和管理各式文档的设备。
在绝大部分情况下我们需要直接通过网络共享协议处理存储在NAS上的数据。
即使遇到网络不稳定等特殊情况，必须在本地进行文档的处理。
在网络恢复并同步完数据后也要需要继续通过网络共享协议使用NAS上的数据。
这样做是有很多好处的。
首先这样做能够减少数据的管理难度，提高数据的安全性。
当我们将文档分散的保存在手机、平板和电脑当中时，如果想要操作特定的文件就必须在指定的设备中进行，这极大的增加了管理难度和数据丢失的风险。
虽然我们可以通过通过数据同步解决这一问题。
但这样做会占用设备较多的空间并且增加数据管理的成本（需要购买数据同步服务）。
而当我们集中管理和存储数据时，不仅可以避免上述的问题，并且可以通过共享文件夹的统一管理来增强对数据的掌控力。
但集中管理数据是存在一个致命问题，那就是一旦NAS出现了问题，可能会导致数据全面丢失。
为了解决这一问题我们需要良好的数据管理和备份策略来避免这样严重问题的出现。

为了能够按照我们的需要存储和使用上述所说的数据，我们需要能够通过公网使用NAS中的某些服务。
我将在介绍完NAS的管理和备份方案后，详细讲解如何实现公网访问NAS。

2. NAS管理和备份方案

我将管理和备份方案分成了对每种数据类型都适应的通用方案和根据数据的特点制定的特殊方案。
通用方案由定时备份、快速备份和共享文件夹名称管理三部分构成。
特殊方案有针对Docker容器中需要持久保存的数据的提高高可用性策略，以及针对需要自己编写处理的各类文档的本地化存储。
因为这是我是第一次认真思考有关数据安全的问题，所以我将以严格的标准制定方案，来让自己在一开始就有一个良好的数据备份和管理意识。
也因为还是一个新手，所以一定会存在各种各样的问题。
如果大家发现了，还请大家多多见谅并在评论区指出我的问题,感谢感谢。

注意：下面的配置我都是在QNAP的TS-564上进行的。
虽然可以配置方法可以不适用于其他品牌的NAS设备，但备份和管理的思想我想还是可以给大家带来一点启发的。

2.1 通用方案

2.1.1 定时备份

对于那些具有一定重要性的数据，我们需要对它们进行定时的备份。
我的定时备份一共分为定时热盘备份,定时网盘备份和定时冷盘备份三部分。
之所以备份三份，并且一份备份在云盘上,一份备份在冷盘是有原因的。

首先是因为如果只拥有一份备份，在对数据进行恢复时，可能因为出现操作失误，造成备份数据的丢失。
如果我们至少要拥有两份备份，便不会让这样的情况发生。

其次是因为将数据用同种介质保存在同样的环境下是极度危险的。
在同种环境下运行的同种介质所受的环境影响是极度相似的，如果一块介质出现了问题，那么其他的介质也很可能存在问题。
并且如果发生自然灾害或其他会对某处空间造成毁灭性影响的事件，保存在相同环境中的所有的数据都将发生丢失。
所以我要将一份数据放到云盘进行异地备份。
但需要注意的是通过云盘进行异地备份是有很多限制的。
例如拥有版权的电影、漫画等等很容易被封禁掉。
有些私密的数据存放上去有很大的泄密风险。

最后如果所有的备份都处在通网通电的状态下，很有可能遭到网络攻击,让全部数据遭到劫持。
因此还需要定期将数据备份到冷盘中以防万一。
而且因为冷盘备份不太适合自动化进行，需要手动进行备份，所以我们还可以在进行冷备的过程中顺便进行一些也无法进行自动化运维的事情，例如对QNAP的系统配置进行备份等。

其中对我来说最重要的和配置耗时最长的是热盘的定时备份。
说它重要是因为其他的备份都是对热备盘中的数据进行重新备份得到的。
我这样做是因为QNAP中的HBS3备份工具需要一个个点击共享文件夹才能进行定期备份，比较麻烦，而且在新建共享文件夹后还需要对已经创建的备份作业进行修改才行。
为了减少这样麻烦而且无意义的工作，我将热备份统一放在热备盘的一个共享文件夹里，其他备份通过HBS3备份此文件夹即可。
说它麻烦是因为它需要通过命令行进行配置比较复杂。
先简单讲一下思路，然后再进行详细的配置。

在热备份中我通过crontab定时执行rsync同步操作，备份NAS设置的共享文件夹中的全部数据及其权限。
之所以是通过rsync而不通过HBS3上面已经给出了解释，通过rsync我们直接备份共享文件夹所在的目录,使得在创建新的共享文件夹时不需要修改备份任务。
因为QNAP会在重启后抹除所有通过命令行对系统配置的修改，所以为了能够在重启后正常使用crontab中的配置，我们还需要配置QNAP自带的开机自启动脚本来实现开机时对系统配置的重新写入。
下面我们来详细的讲解热备份的实现步骤。

配置前提：

在web版QNAP界面中打开ssh连接并允许启动时运行用户定义的进程(autorun.sh)。
拥有一定的命令行使用经验

2.1.1.1 配置用于打开autorun.sh的脚本

首先我们需要创建一个共享文件夹用来存放这些我们自定义的配置，然后编写一个用于打开并配置autorun.sh的脚本start.sh并存放在其中。
在QNAP的目录中共享文件夹都放在/share/CACHEDEV1_DATA文件夹中。
在这里为了方便期间我都进行省略，简化为init文件夹，并在其中创建一个名为autorun中文件夹进行脚本的存放。
start.sh中的内容为：

mount $(/sbin/hal_app --get_boot_pd port_id=0)6 /tmp/config
touch /tmp/config/autorun.sh
chmod +x /tmp/config/autorun.sh
sudo vim /tmp/config/autorun.sh

#备份autorun.sh配置
sudo cat /tmp/config/autorun.sh > /init/autorun/autorun.sh

umount /tmp/config

因为我们只备份共享文件夹而autorun.sh文件不再共享文件夹中，所以如果想要对autorun.sh配置文件进行备份，需要将其拷贝到共享文件夹中。
在这里为了方便管理我存放在和start.sh相同的文件夹中。
编写好加上可执行权限后，我们就可以通过执行/init/autorun/start.sh命令，来配置开机自启动脚本了。

2.1.1.2 配置备份脚本

我们配置好用于打开autorun.sh的脚本后，就需要思考在autorun.sh中编写些什么命令才能将定时任务写入crontab的配置文件了。
这里需要注意一点那就是QNAP的autorun.sh脚本是在很多系统进程执行前进行执行的。
这些在autorun.sh之后执行的进程,可能存在对crontab进行重新配置的进程。
如果我们直接将定时备份任务写入crontab的配置文件，可能会被覆盖。
并且在NAS运行过程中也可能出现进程对crontab重新进行配置，覆盖我们之前的配置。
因此我们需要找到一个可以长久的保存crontab配置的方法。
我想到的方法是让autorun.sh执行一个设置为后台执行的脚本/init/crontab/crontab.sh。
这一脚本会通过sleep命令已阻塞的方式每两分钟执行一次crontab自定义配置写入命令组,保证自定义配置的长久存在。

在sleep命令之后执行的crontab配置命令组我是这样规划的。
我不会直接修改crontab的配置文件，而是通过crontab <文件>命令指定/init/crontab/crontab.init为crontab的配置文件。
这一文件会先通过复制cronatb原先的配置文件来获得系统设置的定时任务。
并且为了防止自定义配置的重复写入，在写入我们自定义命令之前会尝试删除一遍可能存在的自定义配置。
做完这些事情后我们就要写入我们自己的自定义配置了,在这里我们只写入备份脚本。
这里我们使用rsync命令进行备份操作，通过这一命令我们可以将所有的共享文件夹镜像到热备盘的backup共享文件夹中。
备份时间设置为每天1点。
具体内容如下

#通过死循环让这一脚本持续运行下去
while((1))
do
  #每两分钟重新写一次crontab配置
  sleep 2m

  #为了避免系统在上次工作期间设置了新的定时任务，我们需要先更新crontab配置。
  crontab -l > /init/crontab/crontab.init

  #清除原先可能已经存在的自定义设定
  sed -i '/rsync -a --delete /d ' /init/crontab/crontab.init

  #重新写入我们自己的定时任务
  #rsync默认就之同步只有发生数据修改的文件。
  #-a选项表示同步包含连接以及权限，并且进行递归拷贝。
  #--delete选项表示删除备份文件中不存在与被备份文件中的数据,及让备份完全是被备份文件的镜像
  echo "* 1 * * * rsync -a --delete 需要备份的文件夹  用来备份的文件夹" >> /init/crontab.init/crontab.ini

  #将我们自己的文件设置为crontab的配置文件
  crontab /init/crontab/crontab.init
done

最后我们可以通过先注释掉sleep命令和死循环，然后直接执行cronatb.sh脚本查看是否重定向cronatb配置文件并添加上我们自己的定时任务,以确保cornatb.sh的有效性。

2.1.1.3 写入autorun.sh

通过上面两步我们获得了/init/autorun/start.sh和/init/cronatb/crontab.sh两个脚本。
执行/init/autorun/start.sh脚本之后我们会用vim打开authrun.sh脚本，我们在里面输入命令/init/crontab/cronatb.sh &即可。
然后我们就可以重启NAS查看脚本是否能正常进行了。
有一说一QNAP重启速度是真的慢，习惯使用linux后真受不了,感觉比云主机的重启速度还慢。

2.1.2 快速备份

对于那些我们认为重要的数据，在进行完处理后我们会想要在第一时间进行快速备份。
我认为快速备份应该分两种，一种是对指定的共享文件夹进行快速备份;另一种是不需要指定共享文件，而是设置的一个共享文件夹列表,对里面所有的共享文件进行快速备份。
虽然我们现在可以简单的直接将定时备运行一遍来达成快速备份，没有必要麻烦的指定特定的共享文件夹或文件夹组进行快速备份。
但随着到NAS使用率的提高，平均每秒上传到NAS的数据会越来越多。
如果快速备份时直接使用全备份会向热备盘中上传很多没必要实时备份的数据，不仅会占用带宽还会增加NAS的运行压力浪费NAS的系统资源，降低NAS的性能。

下面我将说明我是如何实现快速备份的。
对于第一种快速备份方法，我们需要先获取拥有的所有共享文件夹名称，然后将输入的想要进行快速备份的文件的名称与此列表做匹配，如果文件名属于列表则进行快速备份。
对于第二种快速备份的方法，我们不直接创建一个默认快速备份列表，而是通过共享文件夹的名称来判断此共享文件夹是否可以进行默认快速备份。
具体内容在下一节共享文件的命名中做详细介绍，现在只需要知道如果文件夹中有qk标志则进行默认快速备份，如果有unqk标志则不进行默认快速备份。
这一用来进行快速备份的脚本(nas_quick_backup.sh)需要放在NAS中才能顺利执行，所以我们需要远程执行此命令。
对于pc端和ipad端我们可以通过ssh命令远程执行脚本,并且为了更加方便的使用，我们还需要进行NAS用户免密使用sudo命令和ssh免密登陆。
具体的实现方法我们将在下面进行一一讲解。

2.1.2.1 快速备份脚本的实现

首先我们要进行实现nas_quick_backup.sh脚本的实现。

#判断参数是否属于数组
JudgeArry()
{
  for judge in ${DIR[*]}
  do 
     if [ $1 = $judge ]
     then
        return 0
      fi
   done

    return 1
}

#共享文件夹目录
share_dir=/share/CACHEDEV1_DATA
backup_dir=/share/CACHEDEV2_DATA

#如果有输入参数
if [ $1 2> /dev/null ]
then
  #获取所有共享文件夹名称列表
  DIR=($(ls $share_dir |grep _))
  #判断输入的参数是否属于共享文件夹名称
  if JudgeArry $1
  then
      sudo rsync -a --delete $share_dir/$1/  $backup_dir/backup/$1/
  elif [ $1 = list ]
  then
      echo ${DIR[*]}
  else
    echo "$1 不是有效的共享文件夹名称,可以输入参数list查询所有共享文件的名称"
  fi
else
  #获取默认进行快速备份的共享文件夹列表
  ALLOW_DIR=($(ls $share_dir | grep **_qk_{*}*)) 
  #进行共享文件的逐一备份
  for dir in ${ALLOW_DIR[*]}
  do
    sudo rsync -a --delete $share_dir/$dir/  $backup_dir/backup/$dir/
  done
fi

2.1.2.2 远程调用快速备份脚本

编写完nas_quick_backup.sh并添加上可执行权限后，我们就需要在其他用来进行数据处理的设备上配置远程执行脚本了。
这一脚本我们命名为nasqkbk,具体的实现非常简单就是通过ssh向NAS传递一个执行nas_quick_backup.sh脚本的指令。

ssh user@ip  nas_quick_backup的绝对地址

我们唯一需要注意的是，我们选定的user在执行脚本时会执行sudo命令。
这一命令会需要我们输入用户的密码，但因为我们是通过远程执行命令，因此无法输入密码。
因此为了能够顺利执行脚本，我们需要让user可以免密使用sudo命令，并且具有通过超级权限使用rsync的能力。
这又需要对NAS的系统配置进行修改，因此需要我们使用/init/autorun/start.sh脚本，编写开机自启脚本。
在开机脚本中我们需要对sudo的配置文件进行修改，在QNAP的系统中其位于/usr/etc/sudoers，并且具有可写权限。
因此我们只要在autorun.sh添加如下内容即可：

sed -i '85i uesr ALL=(ALL) NOPASSWD:rsync ' /usr/etc/sudoers

我们将nasqkbk脚本添加可执行权限并加入PATH中的某一文件，就可以在设备上直接使用nasqkbk进行快速备份了。
唯一存在麻烦的地方是执行ssh命令时我们需要输入一遍user的密码来进行联系。
我们可以在设备中通过命令：
ssh-copy-id user@ip
拷贝一份密钥来实现免密登陆ssh。

最后我们需要注意的是因为这里我们还没有通过内网穿透获得公网ip,所以我们只能在局域网中通过使用NAS内网ip才能远程调用脚本。

2.1.3 管理共享文件夹

在NAS中我们通过共享文件夹进行数据的存储和管理。
我们既可以通过QNAP自带的软件Qfile登陆不同的用户查看特定的共享文件夹视图,也可以直接通过NFS服务在电脑上挂载需要的共享文件夹。
我们经常会忽视对共享文件夹的管理,这会给我们的使用造成很大的影响。
对于个人使用来说很容易出现在几页甚至几十页共享文件中寻找几个我们需要使用的共享文件夹情况，增加数据查询难度。
而在多人使用同一台NAS时就更加致命了，缺乏管理会导致某些用户拥有其不该拥有的共享文件夹的读写权限，降低数据的安全性。
我们可以通过权限管理和命名管理两种方法来进行共享文件夹的管理，下面我们分别进行介绍。

2.1.3.1 权限管理

权限管理主要分为，用户权限管理，NFS主机访问管理和Microsoft网络主机访问管理三类。
因为Microsoft网络主机访问管理与NFS主机访问管理是极度相似的，因此在这里就不做介绍。

2.1.3.1.1 文件权限管理

文件权限管理一般在使用web端和Qfile时被体现出来。
文件权限分为读取、读取/写入、禁止访问三种，我们可以在每个共享文件夹的配置中为每一个用户设置使用权限，也可以通过群组一次性为多个用户设置使用权限。
如果对于某个用户某个共享文件夹的权限被设置为禁止访问，则在此用户的共享文件夹视图中便不会显示此共享文件夹。
对于个人用户来说，我们可以通过这一点在不同用途时使用不同的用户，来精简共享文件夹视图更加方便和安全的使用和管理文件。

对于一个用户来说，根据使用的权限可以将共享文件夹分为多人共享文件夹、私人共享文件夹和只读共享文件夹三类。
多人共享文件一般用在团体协作当中，有多个用户拥有此文件夹的读写权限，一般存放公开的非私密的内容。
私人共享文件夹只有用户自己拥有读写权限，用来存放属于用户自己的私密数据。
只读共享文件夹可以说是多人共享文件夹的一个变种。
在这类文件夹中用户并没有文件夹的写入权限，只能读取文件夹中已经写入的内容。

我们需要根据实际的使用来进行文件夹的权限配置，在这里我就抛砖引玉一下。
例如我在通过Qfile访问文件夹时，基本不会访问存储Docker容器中需要持久保存的数据的共享文件夹，但这类数据存在很多的共享文件夹，给我的使用造成了一些不必要的麻烦。
因此我们可以创建一个禁止访问此类数据的用户，来减少不必要的共享文件夹出现在视图中影响我们的正常使用。

2.1.3.1.1 网络共享协议的权限管理

在手机，平板等移动设备上我们可以使用QNAP自带的Qfile软件来进行NAS中共享文件的管理。
但到了PC端我们就需要通过网络共享协议来管理NAS中的共享文件了。
在这里我主要使用SMB和NFS两种网络共享协议，当然如果是苹果则需要使用AFP网络共享协议，因为我没有使用过所以这里不进行介绍。
在这里我们只根据使用上的不同对NFS和SMB做一定的对比，并不深入的探索它们的实现方法。
注意在NAS中我们需要开启相关的服务才能进行使用。

NFS和SMB都既可以用在Linux上也可以用在Windows上，但它们在验证机制上存在很大的不同。
SMB拥有用户验证机制，我们在使用SMB时需要登陆NAS中的某个用户，我们拥有的共享文件权限和此用户的权限相同。
因此我们不需要为SMB重新配置权限。
而NFS是通过IP地址进行验证的，文件的权限与IP进行挂钩。
我们需要为每一个共享文件夹配置不同IP的使用权限。
但在公网的环境下，我们是很难有一个固定的IP的，因此在Linux的环境中我推荐在局域网下使用NFS,在公网下使用SMB。
如果是Windows环境下我推荐使用SMB,因为配置最简单，速度也很快。
当然在NAS没有公网IP的时候，我们只能能通过局域网使用网络共享服务。
在下一大节公网访问中我将介绍如果在不同模式的内网穿透下实现通过公网访问NAS。
并在那是在详细的介绍这两种网络共享服务的配置方法。
那是我们可以根据我们自己的需求选择访问NAS的方式和使用的网络共享服务了。

2.1.3.2 文件夹名管理

我们在使用一个共享文件夹时首先看到的是它的名字。
如果我们能够通过文件夹名称就能直接了解文件夹的大致信息，那么就能极大的方便我们使用、管理和检索文件夹。
使得即使在文件夹检索功能单一的情况下，也能够进行高级查询功能。

因为我们需要的是通过文件夹名称直接了解文件夹的大致信息，因此我们需要知道对于一个共享文件夹来说有哪些重要的信息。
在这里我总结了五点分别是：
共享文件夹中存储的数据的存储类型。
这一点我们在一开始进行进行了讨论，主要分为三类：

Docker容器中需要持久保存的数据(ctn)。
需要自己编写处理的各类文档(pvt)。
通过各种渠道收集整理的资源(ifmt)。

为了方便在共享文件夹的名字中指示出这些类型出来，我在每种类型后面都添加上了对应的英文简写。
这些都是我自己指定的，大家可以根据自己的要求指定自己想要的英文简写。

共享文件的类型以及共享数据属于的组织。
我们在共享文件夹的权限一节中对这些共享文件夹类型已经有了详细的介绍，它主要分为下面三种:

你用有读写权限的多人共享文件夹(ShareRW)
用户只有只读权限的多人共享文件夹(ShareRO)
只有用户自己有读写权限其他人禁止访问的私人共享文件夹(PrivateRW)

一般我创建在共享文件夹会将用在不同组织的数据分开进行存储的。
例如我自己收藏的图片会和家人和朋友之间的共同保存的图片分开保存;
用来完成学校作业而收集的各种资料会和我自己在爱好中需要用到的材料进行分开保存。
这样细化共享文件夹能让每一个共享文件夹都尽可以少的保存文件，方便管理和查询。
我常用到的组织有个人(mine)，学校(school)，家人(family)，朋友(friend)等。

还有一点与备份相关。
在快速备份一节中我说过"对于第二种快速备份的方法，我们不直接创建一个默认快速备份列表，而是通过共享文件夹的名称来判断此共享文件夹是否可以进行默认快速备份"。
在这里我们通过简写qk表示共享文件夹可以进行默认快速备份,用unqk表示文件夹不能进行默认快速备份。

最后一个是共享文件夹的详细的名称，也就是我们常规中会为文件夹的命的名。
最终我确定的共享文件的命名规则是：
进行存储的数据的类型_共享文件夹类型_所属的组织_是非进行快速备份_文件夹的详细名称

2.2 特殊方案

2.2.1 高可用性

现在好像每台NAS都使用上了RAID，但我想说的是RAID对大部分用户并不是一个好的选择。
RAID的定位是一种提高硬盘可用性的技术。
所谓的高可用性是指在组成阵列的某几块硬盘发生故障时，让阵列的读写操作仍能正常进行,并且可以通过一定的技术将故障硬盘的数据恢复到新硬盘中。
但需要注意的是虽然RAID具有一定的数据恢复功能，但需要重点重点强调的是这项功能并不能让RAID作为一种备份技术使用。
所有将RAID当作一种备份技术的行为，都将付出惨重的代价。
而对于大多数人来说就是将RAID当作一种备份技术的。

首先是因为将硬盘组成RAID后，在使用期间内每块硬盘的写入次数大致是相同的，如果使用的是类似于RAID5的阵列,则每块硬盘的读取次数也是大致是相似的。
这就使得每一块盘的状态具有一定的相似性。
而且个人用户在购买时一般都是选定一个品牌的某一型号的硬盘后，直接买下和组成阵列的所需硬盘数相同数量的产品。
这就导致组成阵列的都是同一品牌同一型号同一批次的硬盘，从而使使用过程中每一块硬盘的状态更加相似。
因此当一块硬盘出现问题时，其他硬盘的状态也可能不太好。
最后因为RAID的重组恢复过程会对硬盘造成极大的负荷，在恢复过程中其他硬盘也很有可能发生不可避免的故障，最终导致数据的丢失。
虽然现在有故障硬盘数据恢复技术，但组成RAID的硬盘数据恢复比起普通硬盘要难得多。
需要花费更多的时间和金钱才有机会恢复一部分的数据。
其次大容量的而RAID重组恢复需要消耗时间的数量也是恐怖的。
而且及时在重组过程中没有磁盘发生故障，恢复也是也有一定的概率失败的。

但对于我来说是需要使用RAID的。
因为我需要通过容器部署许多重要的服务，为了让容器能够持续平稳的提供这些服务，需要NAS具有一定的可用性。
保证即使在某些硬盘出现问题的情况下，也能继续为容器提供服务。
我用的TS-564一共有三个机械硬盘位，因此我可以使用下面几种RAID:

RAID0：需要使用两块硬盘进行组合，总容量为一块硬盘的容量。
RAID0是读写速度最快的RAID,在带宽足够时,总体的读写速度为两块硬盘的读写速度。
将RAID的容量和读写速度发挥到极限是有代价的。
RIAD0并不会进行冗余备份，只要组成RAID的硬盘组中有一块发生损坏，整个RAID都将无法进行读写工作，已经写入的数据也将发生丢失。
因此其不行满足我们需求。

RAID1: 和RAID0一样需要使用两块硬盘才能进行阵列搭建,阵列的总体容量为一块硬盘的容量,总体的读写速度为一块硬盘的读写速度。
只要还有一块硬盘未发生故障，整个阵列就可以以正常的速度进行的读写操作。
可以满足我的需求。

RAID5: 需要三块硬盘进行搭建，阵列容量为两块硬盘的容量。
允许在阵列中出现一块硬盘故障的情况下，根据数据校验位对丢失数据进行还原，使阵列以较低的速度进行读写操作
可以满足我们的需求。

最终我选择了组建RAID1。
首先是因为我认为RAID1比起RAID5具有更高的可用性。
组成RAID5的硬盘在使用是具有相似的读写次数，因此硬盘的运行状态都差不多。
在一块硬盘出现问题时，其他两块盘的状态也不容乐观。
在降级状态下可能很快就会出现新的损坏硬盘，导致NAS不能继续提供服务。
而RAID1的状况就好上很多。
RAID1的镜像硬盘在大部分情况下只进行写入操作,运行状态一般都优于主硬盘,在降级模式下很可能能坚持很长时间。
其次是因为RAID5有诸多不方便的地方，例如在降级模式下需要进行校验和的计算才能获得原始数据，读取速度会比原来慢上很多。
而且使用大硬盘容量时迁移和重组阵列需要花费大量的时间，并且有很大的失败概率。
最后是因为RAID5需要使用三块硬盘才能组成，进行热盘备份时需要格外购置硬盘盒和硬盘，需要很多成本。
具体如何配置因为没有什么可以讨论的，网上也有很多的教程，这里就不做过多赘述了。

2.2.2 本地化存储

前面说过我想让NAS真正成为一个只用来集中存储和管理各式文档的设备。
本地设备应当只专注于数据的处理，NAS就应当只专注负责数据的保存和备份。
因此我一般会通过网络共享服务直接在NAS上的创建和处理原数据。
但多设备之间的通信是需要网络进行的，一旦有网络延迟过大甚至是断网的情况出现，就会让手边的工作无法继续进行下去,这是我无法接受的。
为了在网络异常的情况下仍然能正常工作，需要在本地也拥有一份实时的备份。
在网络出现异常时，我们就可以通过本地备份继续进行数据的处理。
而当网络恢复使用后，再将本地备份的数据同步到NAS上，然后使用网络共享服务处理NAS上的数据。
为了保证保证本地备份的时效性和安全性。
我将在进行快速备份的同时更新本地备份，并且只更新已经挂在到本设备上的共享文件夹。

#进行快速备份
ssh user@ip "/backup/quick_back.sh $1"

#进行本地备份
#确定被挂载的共享目录及其挂在的位置
share_dir=($(df | grep nas的ip | awk '{print $1}' | awk -F/ '{print $2}' ))
mount_dir=($(df | grep nas的ip | awk '{print $6}'))

#进行本地备份
count=0
while((count < ${#share_dir[@]} ))
do
  sudo cp -a ${mount_dir[$count]}  /backup/${share_dir[$count]}
  let "count++"
done

最后我本来还想说以下有关版本控制的相关内容的，但因为我自己在这方面的使用还不算太多，所以准备等我对这方面的内容有更多的了解之后在进行介绍。
下面让我们来看一下如何进行NAS的公网访问。

3. NAS的公网访问

NAS的公网访问对我来说是必须的功能。
首先我搭建的k3s集群中的container需要通过公网才能访问到NAS中存储的数据。
其次我不可能将NAS一直放在我的身边，当我在外面办公的时候，也需要通过公网访问NAS中的文档和数据等等。

在这里我们有两种公网访问NAS的方法，分别是QNAP自带的myQNAPcloud软件和通过软件frp实现的内网穿透。

3.1 myQNAPcloud

QNAP自带的myQNAPcloud软件配置起来非常简单，通过其给我提供的域名我们可以通过公网访问web控制端。
并且移动端的Qfile pro可以直接通过myQNAPcloud公网访问NAS中的文件内容。
因此我推荐移动端用户通过myQNAPcloud公网访问NAS。
在我使用的时候上下传速度都还可以。
这一方法是通过DDNS实现公网访问的。
所谓的DDNS就是动态域名解析。
在互联网上很多设备拥有的是通过DHCP获取动态IP，这以IP会在一段时间后发生改变，让我们无法访问到设备。
但通过DDNS，我们可以实时更新这一IP，并让用户通过域名访问到该IP。
具体的实现方法是，我们在NAS上下载myQNAPcloud作为DDNS的客户端,
这以客户端会实时向DDNS服务器时时更新NAS的动态IP。
然后我们通过DDNS服务器提供的域名可以访问这一IP。
配置方法很简单就不做讲解的。

3.2 内网穿透

3.2.1 内网穿透的原理

3.2.1.1 基础知识

在解释内网穿透的原理之前，我们需要先知道我们是如何调用服务器中的服务，以及在没有公网IP时是如何与拥有公网IP的服务器建立起连接的。
一台服务器一般都会提供很多种不同的服务，那我们在连接的时候是如何让服务器知道我们需要调用的哪项服务呢？
通过的是一种叫做端口的东西，我们可以将其理解为一扇门，通过不同的门我们能进入的房间使用不同的服务。
例如我们如果想要打开一个网页，就需要指定Web服务器的443端口，形式是ip:端口。
在我们使用某项服务时，需要与服务器建立起连接。
简单的说就是我们需要知道它的IP来向它传输数据，它也需要知道我们的IP来向我们传输数据。
可在大部分情况下我们的设备是没有公网IP的，那服务器是如何向我们传输数据的呢？
这里就需要通过名为PAT的网络协议了。

运营商会将我们的设备与一台名为PAT路由器的设备连接在一起，组成内网。
PAT路由器会为我们分配一个内网IP,范围是10.0.0.0-10.255.255.255，172.16.0.0-172.31.255.255，192.168.0.0-192.168.255.255。
PAT服务器拥有公网IP，在我们的设备与服务器建立连接时，会在NAT路由表中添加上一行映射。
将我们设备的内网IP和接受服务器数据的端口映射为PAT路由器的公网IP加某一端口。
服务器将数据发送各PAT路由器的指定端口，然后PAT路由器再根据路由表将数据转发给相应设备的相应端口。

3.2.1.2 内网穿透原理

知道上面这些基础知识之后我们就可以学习内网穿透的原理了。
内网穿透可以分为传统内网穿透和P2P内网穿透两种。
它们都需要在一台拥有公网IP的服务器上安装frp服务端，在需要进行公网访问的设备上安装客户端。
不同点在与是否需要在访问端安装客户端。
以NAS为例，传统内网穿透不需要在访问NAS的用户的设备上安装frp客户端，NAS上的客户端会与拥有公网IP的服务器之间建立持久连接。
服务器的某一指定端口会与NAS的指定端口连接联系。
当我们将数据发送给服务器的这里端口后，服务器会将数据转发给NAS的指定端口。
因为需要服务器转发所以上传和下载速度受服务器宽度的限制，并会消耗服务器的流量。
因此当我们使用流量计费的服务器时需要控制流量的消耗。
在frp中我们通过TCP代理模式实现传统内网穿透。

对于P2P式的内网穿透来说，我们需要在访问端也安装frp客户端，其也需要与服务器建立联系。
但当我们访问NAS时，流量不需要经过服务器，而是直接与NAS建立连接，不受服务器流量和宽带的限制。
原理是我们在服务器的帮助下，在用户和NAS的NAT路由表上都添加上了相应的映射。
NAS可以通过用户端PAT路由器的IP+特定端口将数据发送给用户，用户也可以通过NAS端PAT路由器的IP+特定端口将数据发送给NAS。
但p2p式内网穿透的成功率和稳定性都没办法得到保证，所以不适合需要进行稳定连接的情况。
在frp中通过XTCP代理模式实现内网穿透。

3.2.2 内网穿透的使用分析

知道原理之后我们就可以开始进行内网穿透的配置了。
对于我来说我主要内网穿透NFS，SMB和SSH三项服务。
网络共享协议因为需要用在k3s集群中，所以会有较大的流量传输，并且需要较高的传输速率保证较低的延迟。
因此我选择使用p2p式的内网穿透，即XTCP代理模式。
而对于SSH,我们需要保证较高的稳定性因此选择传统的内网穿透模式，即TCP代理模式。

在进行内网穿透时我们需要注意一点，在没有进行特殊的设置时，NAS获取到的通过内网穿透而来的用户IP均为127.0.0.1。
对于网络共享协议来说是无所谓的，因为通过XTCP代理模式，只有特定的用户才能内网穿透到NAS进行使用。
但对于SSH来说，它通过的是TCP代理模式，世界上所有的设备都可以通过云服务的公网IP访问到此服务。
有很大的安全风险。
我们很可能遇到有恶意用户通过暴力破解的方式试图登陆SSH服务。
这时候我们就需要获取恶意用户的IP，禁止这些IP使用服务了(可以通过云服务器的安全组也可以通过NAS自己的设置)。
所以在对SSH服务进行内网穿透时，需要获取登陆用户的真实IP才行。
但这我还没有很好的实现，在这里就先不进行介绍了。

3.2.3 内网穿透的配置

通过前面的介绍我们可以知道如果想要通过frp实现内网穿透,必须拥有一台拥有公网IP的云服务器。
我们购买一个拥有公网IP的最低配置的流量计费云服务器即可。
因为frp本身的运行压力就很小，并且只有SSH服务这样只消耗很少流量的服务通过TCP代理需要服务器转发流量。

开始配置前需要在云服务器上安装frp服务端，然后在NAS和主机上配置frp客户端。
frps和frpc如何下载以及如何通过system控制frp我就不做讲解了，直接参考官方文档即可，在这里我只介绍配置文件的编写。
需要注意的是我使用的配置文件都是YAML格式。

3.2.3.1 frps配置文件

frps配置文件是很简单的，我们只需要规定frp服务器用于接收客户端连接的端口和设置连接密码即可。

#设置连接端口
bindPort: 7000
auth:
#只有客户端配置中的token一样时，才允许连接
  token: 123456

当然还可以对服务器端进行更加详细的配置，比如我们可以配置一个web端的管理页面。

3.2.3.2 NAS端的frpc配置文件

内网穿透使我们可以通过公网访问NAS的某些端口。
用户就是通过端口来调用服务器中的服务的。
对于需要进行p2p内网穿透的服务，我们只需要说明需要公开的NAS端口即可。
NFS我推荐使用nfsv4因为其只需要公开2049一个端口即可。
SMB服务我们需要公开445和139两个端口。
而对于需要进行传统内网穿透的SSH服务来说，除了需要说明公开的NAS端口外，还需要指定一个进行映射的公网IP的端口。
通过公网IP+这一指定的端口我们可以访问NAS提供SSH服务的端口也就是22端口。
注意我加上双引号的配置，在编写时双引号不能去掉，否则会报错。

auth:
  method: "token"
  token: "123456"
serverAddr: "公网IP"
serverPort: 7000
proxies:
  - name: "nfs"
    #代理类型
    type: "xtcp"
    #内网穿透的端口
    localPort: 2049
    #主机连接时需要的验证密码
    secretKey: "secret"
  - name: "SMB_1"
    type: "xtcp"
    localPort: 445
    secretKey: "secret"
  - name: "SMB_2"
    type: "xtcp"
    localPort: 139
    secretKey: "secret"
  - name: "ssh"
    type: "tcp"
    localPort: 22
    #映射的云服务器端口
    remotePort: 1234

3.2.3.3 主机端的frpc配置文件

通过XTPC代理模式我们可以通过127.0.0.1使用NAS上的NFS和SMB服务。
在这里为了方便使用我直接指定了NFS和SMB的默认端口，使得我们在通过mount挂在共享文件的时候不需要指定端口。

auth:
  method: "token"
  token: "123456"
serverAddr: "公网ip"
serverPort: 7000
visitors:
  - name: "client_nfs"
    type: "xtcp"
    bindPort: 2049
    serverName: "nfs"
    secretKey: "secret"
    #定期检测NAS和主机之间的连接是否正常
    keepTunnelOpen: true
  - name: "client_SMB_1"
    type: "xtcp"
    bindPort: 445
    serverName: "SMB_1"
    secretKey: "secret"
    keepTunnelOpen: true
  - name: "client_SMB_2"
    type: "xtcp"
    bindPort: 139
    serverName: "SMB_2"
    secretKey: "secret"
    keepTunnelOpen: true

3.2.4 内网穿透的使用

最后我来稍微介绍一下如何使用这三个进行了内网穿透的服务。
对于网络共享服务来说，我们只需要指定回路ip127.0.0.1即可。
而SSH服务我们需要指定云服务器IP和端口才行
使用方法是：

#NFS服务
sudo mount -t nfs 127.0.0.1:/共享文件夹名
#SMB服务
sudo mount -t cifs //127.0.0.1/共享文件夹名称 -o user=用户名,password=密码
#SSH服务
ssh -p 端口 用户名@密码