容器数据备份有哪些好的方案？容器全备份？还是提取容器中的数据来备份?

需对容器的数据做好分层规划，容器镜像放在镜像仓库中，不必做备份；容器实例存取的数据，如果是存储在分布式文件系统中，则做好分布式文件系统的高可用和备份即可。

容器的数据备份，其实就是有状态应用在k8s的备份问题（不包括容器的镜像），个人认为实际上已经不能把容器本身以及应用的数据分开来了。备份的时候，应该把应用以及应用相关的资源，如configmap，secret，pv，pvc，service，以及pv里面的数据，一起备份下来，并且拷贝或者上传到第二存储，同主存储隔离开来。

目前国外主流的产品有kasten的K10，Portworx PX backup，以及社区的开源项目velero。

这些产品的主流做法，就是把应用的资源以及数据打包，一起备份到S3对象存储，或者NFS等第二存储。其中，PV，PVC还可以抓取CSI快照，然后对快照进行备份，或者对快照进行有选择的数据导出。

之所以这样做，是因为在k8s容器时代，容器是一个动态变化的资源，例如正在运行在哪个node上、配置的参数、版本等等信息都可能是变化的。而最关键的数据，是靠PV，PVC这样的资源来描述的。换句话说，PV，PVC其实就记录了容器同应用数据的mapping关系。在备份的时候，如果容器跟底下使用的存储（如分布式存储）分开备份，这样可能带来几个问题：

1. 容器的备份时间跟存储的备份时间不一致，这样就造成版本的不一致
2. 存储的备份一般是针对存储本身的volume/LUN进行备份，恢复的时候，还要处理volume/LUN同PV的关系
3. 一个集群可能使用不止一个存储，那备份的时候还要考虑不同存储的备份策略
4. 一个分布式存储可能对多个集群供应存储，对某个集群的某个应用的细粒度的数据恢复来说，可能不好处理

总之，如果备份时候对容器和存储分开考虑，那还是基本沿用了虚机时代备份的思路，在容器时代要用的好可能有点困难。在备份的时候，把应用相关的资源一起打包备份，其实就是把资源跟数据的关系在同一个时间点一起备份下来，形成一个比较完整的可用的恢复点，将来恢复时候，也是根据应用的颗粒度来进行恢复的。

容器数据备份，首先是明确是哪些数据，是日志还是应用产生的数据，还是应用需要依赖的数据。
如果是日志数据，就可以对接日志平台，也可通过 fluentd 等日志组件收集；
如果是应用产生的数据，那么最好需要通过持久化进行备份到分布式存储中；
如果是应用依赖的数据，比如中间件数据库等应用，也可以持久化到分布式存储中，但这种情况更多会追求存储性能，就需要用本地卷如LocalPV来实现，但本身需要依赖应用自身做好数据的同步，比如mysql的主备通过binlog同步。

备份整个容器肯定不现实。提取容器中的数据也不用。因为如果是应用需要持久化存储，那么就备份持久化存储上面的数据就好。比如你是商业存储提供持久化存储，那么可以通过存储层面去做备份。如果是用ceph这些分布式存储，那么可以利用veritas结合分布式存储来备份。

这里暂且只讨论容器数据备份，而不涉及集群的备份和恢复。

容器里面实现持久化存储的方式比较多，一方面通过hostpath挂载，隐射宿主机的目录到容器的目录，另一方便通过通过storage绑定挂载持久卷到容器的任何目录。还有通过将NFS目录作为容器的卷挂载的，

当谈到备份数据时，上面的方法都存在一个相同的问题 - 如果容器内的数据在备份过程中发生变更，那么就出现了数据的不一致性，当然我们可以通过关闭卷的读写来获得数据的一致性，不过关闭卷来备份，会导致业务连续性的中断。

这里建议在k8s集群中，把有状态服务的信息存储在数据中，独立于容器的文件的系统。

这样就可以按照常规的方式备份数据，比如快照。

这里介绍几个开源项目 一个是 openebs， 比较火的开源的云原生的存储。 另外一个 就是velero项目，可对集群资源备份和恢复。

首先，容器中如果有数据，有三种方式放置，tmp、hostpath和storageclass
其次，如果要备份容器内的数据，如果使用tmp显然不可能，如果是hostpath，需要到指定的节点上去备份，但容器环境中，pod会切换，生产环境不会使用。
所以，生产的容器环境数据要备份，必然容器中的数据是storageclass，也就是说，要么是分布式存储，要么是集中存储，而这种存储，通常都是多副本的，多副本一般是无须备份的。

如果，真的一定要备份，请在容器所涉及应用的逻辑层，进行备份比较合适，比如如果是Elasticsearch，可以用reindex，把索引数据拉到另一个集群。

设计上需要把容器尽可能做的无状态服务，状态保存在外部公共存储池中或云组件里，这样才能实现容器任意调度，迁移，按需扩容缩容。状态包括内存状态（保存在缓存池），数据库（保存在云数据库），文件（保存在分布式文件系统）

典型如web服务的session信息，要么存储于公共的kv存储里，要么用类似jwt token等分布式鉴权，总之需要避免在容器内部保留超过一次交互以外的数据。
容器最大优势是便于迁移缩放，部署灵活，带上数据就失去了这个迁移能力，所以不是说不能存数据，而是从架构层面把有状态服务放容器就是错的

容器中的数据要持久化，一般会挂载宿主机上的本地存储，或者分布式存储，即使容器销毁了，数据仍然在，新建的容器照样挂在原来的存储就能恢复数据。在容器云上部署数据库，部署架构也要是高可用的集群，集群各节点间应该有数据同步机制。所以，备份容器是没用的，容器是静态的镜像运行起来后的实例，容器里本身不应该存放持久化的数据。

容器备份能不能采用快照技术，如果能够采用快照技术，可以考虑直接备份容器，最方便的。

容器备份，一般建议从容器云本身备份和容器应用备份两个层面来看。
容器云本身备份：一般备份平台自身数据库、ECTD，以及其他组件数据。
容器应用备份：容器应用数据一般都是存放在持久化的数据卷上，只要保证存储平台可靠即可。另外，可以在存储之上，基于传统数据备份做一层防护。