容器集群中的持久化数据（数据库类）的建议备份方式?

数据库类不要用容器，获益不多，烦事不少

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

容器存储形式：
1、容器外部卷使用存储, 以插件的形式支持容器持久化数据。
2、 容器本身与外部卷均使用device mapper作为底层，没有选择分布式存储原因，主要是为了简化实现，更稳定。
3、 通过限制每个容器的BlkioDeviceReadBps, BlkioDeviceWriteBps, BlkioDeviceReadIOps, BlkioDeviceWriteIOps, 使磁盘 IO 稳定地达到相当于 95% 物理机性能。
通过运行容器存储数据库动态数据，从场景经济性上不建议采用这种方式，数据依赖性的业务系统，对数据I/O要求和数据一致性要求都比较高，对容器开销、维护成本极高。容器时随着业务发展扩缩的，有可能下一秒就会被收回释放，如果用于存储数据就容易造成业务数据丢失和不一致情况，容易出现业务系统中运行业务崩溃。

目前数据库存放容器云，还没有最完美的方案
1、DBA通常反对用容器存放数据库，灾难恢复担心丢失数据，操作起来也麻烦
2、容器云架构师一般给出的方案是
      a、使用pv做持久化，先保证数据持久化

  b、pv尽量挂载ceph集群而不是物理机，保证数据不会因为硬件问题丢失，避免容器故障漂移后导致数据不一致。 需要充分考虑io和网络io
  c、容器使用stateful,保证多个副本，主从切换，读写分离。并做好数据库备份（不能简单的只保存镜像）

数据库容器化还是要慎重

数据库目前用在容器还很少吧，如果用mysql用集群，主从可以起到备份的作用吧

1，中大型数据库一般有着极高的的IO要求以及数据一致性要求，容器作为轻量级工具，不适合承载数据库的运行。
2，容器对数据持久化不是很友好，若要进行数据持久化，一般需要将宿主机的独立空间映射给容器，数据落到映射盘上。
3，容器随时可自由重构，一般不需要单独备份。容器内的数据，备份方式及颗粒度受备份恢复软件能力影响，若是有数据持久化需求，建议使用独立存储作为容器数据空间，备份从存储上进行。

首先数据库备份肯定非常有必要的和必须的，不管是出于什么原因和放在何种载体里（大小型机，普通x86物理，虚拟机，又或者是容量中）；数据库备份的频率和是否全部以及如何增量备份，可根据公司现状，所在行业的要求规范，具体承载业务系统的重要级别，以及承载体的特性来匹配个性化的方案和策略；建议是先做刚开始的一个全量备份，然后按照一定的频率做增量备份；备份又分位容器级的备份和容器内数据的备份，二者结合备份这样能保障绝大部分中情况下的吴操作以及异常（非操作）数据恢复，从而保障数据不丢失，业务不受影响。

1. 数据库类的应用不太建议容器化，采用数据库自带的备份机制基本可以满足需求
2. 容器备份一般是备份持久化存储，容器本身不需要备份，随时可以获取。
3. 现在主流的备份软件厂商都在逐渐开始支持容器备份，如nbu、veeam，可以到产品官网了解下，如果有迫切的需求直接联系厂商做方案咨询，并做相应的测试。

首先回答数据库类是否可以容器化，个人建议是可以容器化，就是数据库有些业务对磁盘IO要求有点高，这类应用场景对分布式存储性能要求高。

备份，分为etcd备份和业务数据备份：
1、etcd备份有现成的工具可以备份，可以备份在本地，也可以备份到对象存储；
2、业务数据备份是运行在容器内业务数据备份(PV)，一般有状态业务我们建议使用分布式存储，可以借助分布式存储本身的备份功能完成备份，另外有状态业务也可以使用本地存储、NAS这类存储，这类存储备份可以使用存储本身的备份功能(如NAS)，也可以用第三方功能实现备份功能。

一般都是跑mysql这种非共享存储的数据库，以前用备份软件怎么备份，现在还是怎么备份。可以考虑搞个虚拟机来 作为从节点专门用于备份。