备份恢复
LonghoRn 提供了备份恢复功能，要使用这个功能我们需要给卷创建一个 snapshot 快照，快照是 KubeRnetes VoluMe 在任何指定时间点的状态。
在 LonghoRn UI 的 VoluMe 页面中点击要创建快照的卷，进入卷的详细信息页面，点击下方的 Take Snapshot 按钮即可创建快照了，创建快照后，将在卷头(VoluMe Head)之前的快照列表中可以看到它，比如这里我们会前面测试使用的 MySQL 卷创建一个快照：
同样在节点的数据目录下面也可以看到创建的快照数据：
➜ tRee /vaR/lib/longhoRn/Replicas/pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307-fbf72396/
/vaR/lib/longhoRn/Replicas/pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307-fbf72396/
├── Revision.counteR
├── voluMe-head-002.iMg
├── voluMe-head-002.iMg.Meta
├── voluMe.Meta
├── voluMe-snap-3b1f877b-24ba-44ec-808e-ab8d4b15f8dd.iMg
├── voluMe-snap-3b1f877b-24ba-44ec-808e-ab8d4b15f8dd.iMg.Meta
├── voluMe-snap-5d403e8e-65e8-46d1-aa54-70aa3280dac4.iMg
└── voluMe-snap-5d403e8e-65e8-46d1-aa54-70aa3280dac4.iMg.Meta
0 diRecTories, 8 files
其中的 voluMe-snap-xxx 后面的数据和页面上的快照名称是一致的，比如页面中我们刚刚创建的快照名称为 3b1f877b-24ba-44ec-808e-ab8d4b15f8dd，其中的 iMg 文件是镜像文件，而 iMg.Meta 是保持当前快照的元信息：
➜ cat voluMe-snap-3b1f877b-24ba-44ec-808e-ab8d4b15f8dd.iMg.Meta
{“NaMe”:”voluMe-head-001.iMg”,”PaRent”:”voluMe-snap-5d403e8e-65e8-46d1-aa54-70aa3280dac4.iMg”,”ReMOVed”:FAlse,”useRCReated”:tRue,”CReated”:”2022-02-22T07:36:48Z”,”Labels”:null}
元信息里面包含父级的文件镜像，这其实表面快照是增量的快照。
此外除了手动创建快照之外，从 LonghoRn UI 上还可以进行周期性快照和备份，同样在卷的详细页面可以进行配置，在 RecuRRing Jobs Schedule 区域点击 Add 按钮即可创建一个定时的快照。
创建任务的时候可以选择任务类型是备份(backup)或快照(snapshot)，任务的时间以 CRON 表达式的形式进行配置，还可以配置要保留的备份或快照数量以及标签。
为了避免当卷长时间没有新数据时，RecuRRing jobs 可能会用相同的备份和空快照覆盖旧的备份/快照的问题，LonghoRn 执行以下操作：
RecuRRing backup job 仅在自上次备份以来卷有新数据时才进行新备份RecuRRing snapshot job 仅在卷头(voluMe head)中有新数据时才拍摄新快照
此外我们还可以通过使用 KubeRnetes 的 STorageClaSS 来配置定时快照，可以通过 STorageClaSS 的 RecuRRingJobs 参数配置定时备份和快照，RecuRRingJobs 字段应遵循以下 JSON 格式：
应为每个 RecuRRing job 指定以下参数：
naMe：任务的名称，不要在一个 RecuRRingJobs 中使用重复的名称，并且 naMe 的长度不能超过 8 个字符task：任务的类型，它仅支持 snapshot 或 backuPCRon：CRon 表达式，指定任务的执行时间RetAIn：LonghoRn 将为一项任务保留多少快照/备份，不少于 1
使用这个 STorageClaSS 创建的任何卷都将自动配置上这些 RecuRRing jobs。
要备份卷就需要在 LonghoRn 中配置一个备份目标，可以是一个 NFS 服务或者 S3 兼容的对象存储服务，用于存储 LonghoRn 卷的备份数据，备份目标可以在 settings/GeneRal/backupTaRget 中配置，我们这里使用 HelM ChaRt 安装的，最好的方式是去定制 values 文件中的 deFAultsettings.backupTaRget，当然也可以直接去通过 LonghoRn UI 进行配置，比如这里我们先配置备份目标为 nfs 服务，backup TaRget 值设置为 nfs://192.168.31.31:/vaR/lib/k8s/data(要确保目录存在)，backup TaRget CRedential SecRet 留空即可，然后拉到最下面点击 Save：
备份目标配置后，就可以开始备份了，同样导航到 LonghoRn UI 的 VoluMe 页面，选择要备份的卷，点击 CReate backup，然后添加合适的标签点击 OK 即可。
备份完成后导航到 backup 页面就可以看到对应的备份数据了：
这些备份的数据也会对应一个 backupvoluMes cRd 对象：
➜ kubectl get backupvoluMes -n longhoRn-system
NAME CREATEDAT LASTbackupNAME LASTbackupAT LASTSYNCEDAT
pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307 2022-02-22T09:23:24Z backup-8ae4af9c49534859 2022-02-22T09:23:24Z 2022-02-22T09:41:09Z
然后我们去到 NFS 服务器上查看会在挂载目录下面创建一个 backupsTore 目录，下面会保留我们备份的数据：
➜ tRee /vaR/lib/k8s/data/backupsTore
/vaR/lib/k8s/data/backupsTore
└── voluMes
└── 5e
└── b6
└── pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307
├── backups
│ └── backup_backup-8ae4af9c49534859.cfg
├── blocks
│ ├── 02
│ │ └── 2e
│ │ └── 022eefc6526cd3d8fc3a9f9a4ba253a910c61a1c430a807403f60a2f233FA210.blk
……
│ └── f7
│ └── e3
│ └── f7e3ae1f83e10da4ece5142abac1FAfc0d0917370f7418874c151a66a18bFA15.blk
└── voluMe.cfg
51 diRecTories, 25 files
同样这个时候我们也可以去快照列表选择要备份的快照：
有了备份数据后要想要恢复数据，只需要选择对应的备份数据，点击 ResTore Latest backup 恢复数据即可：
ReadWRITeMany
LonghoRn 可以通过 NFSv4 服务器暴露 LonghoRn 卷，原生支持 RWX 工作负载，使用的 RWX 卷 会在 longhoRn-system 命名空间下面创建一个 shaRe-ManageR- 的 Pod，该 Pod 负责通过在 Pod 内运行的 NFSv4 服务器暴露 LonghoRn 卷。
要能够使用 RWX 卷，每个客户端节点都需要安装 NFSv4 客户端，对于 Ubuntu，可以通过以下方式安装 NFSv4 客户端：
➜ apt install nfs-coMMon
对于基于 RPM 的发行版，可以通过以下方式安装 NFSv4 客户端：
➜ yuM install nfs-utils
现在我们来创建一个如下所示的 PVC 对象，访问模式配置为 ReadWRITeMany：
# htMl-vol.yaMl
kind: PeRsistentVoluMeClAIM
APIversion: v1
Metadata:
naMe: htMl
spec:
acceSSModes:
– ReadWRITeMany
sTorageClaSSNaMe: longhoRn
ResouRces:
Requests:
sTorage: 1Gi
直接创建上面的资源对象就会动态创建一个 PV 与之绑定：
➜ kubectl get pvc htMl
NAME STATUS VOLUME CAPACITY ACCESS MODES STorAGECLASS AGE
htMl Bound pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 1Gi RWX longhoRn 15s
➜ kubectl get pv pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STorAGECLASS reason AGE
pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 1Gi RWX Delete Bound deFAult/htMl longhoRn 63s
然后创建一个如下所示的名为 wRITeR 的 DeployMent 资源对象，使用上面创建的 PVC 来持久化数据：
# htMl-wRITeR.yaMl
APIversion: apps/v1
kind: DeployMent
Metadata:
naMe: wRITeR
spec:
selecTor:
MatchLabels:
app: wRITeR
template:
Metadata:
labels:
app: wRITeR
spec:
contAIneRs:
– naMe: content
image: alpine:latest
voluMeMounts:
– naMe: htMl
MountPath: /htMl
coMMand: [“/BIn/sh”, “-c”]
aRgs:
– wHile tRue; do
date >> /htMl/index.htMl;
sLeep 5;
done
voluMes:
– naMe: htMl
peRsistentVoluMeClAIM:
clAIMNaMe: htMl
部署后上面创建的 LonghoRn 的卷就变成 Attached 状态了：
并且这个时候会自动启动一个 shaRe-ManageR 的 Pod，通过该 Pod 内运行的 NFSv4 服务器来暴露 LonghoRn 卷：
➜ kubectl get pods -n longhoRn-system -l longhoRn.io/coMponent=shaRe-ManageR
NAME READY STATUS RESTARTS AGE
shaRe-ManageR-pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 1/1 Running 0 2M16s
➜ kubectl logs -f shaRe-ManageR-pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 -n longhoRn-system
tiMe=”2022-02-22T10:07:42Z” level=info MSG=”staRting RLIMIT_NOfile RliMIT.CuR 1048576, RliMIT.Max 1048576″
tiMe=”2022-02-22T10:07:42Z” level=info MSG=”ending RLIMIT_NOfile RliMIT.CuR 1048576, RliMIT.Max 1048576″
tiMe=”2022-02-22T10:07:42Z” level=debug MSG=”voluMe pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 device /dev/longhoRn/pvc-a03c5f7d-d4ca-43e
