快照（snapshot）是从正在运行的 Elasticsearch 集群中获取的备份。你可以获取单个索引（indices）或整个集群的快照，并将其存储在共享文件系统上的存储库中，并且有支持 S3、HDFS、Azure、Google 云存储等远程存储库的插件。
3月23号，Elastic又发布了最新的7.12版本。在这个版本中，最重要的一个更新是frozen tier的发布。相比于之前版本的cold tier（关于cold tier的细节，可以查看之前的博文：Elastic Searchable snapshot功能初探、Elastic Searchable snapshot功能初探 二 （hot phase）），其最大的不同是我们可以直接在对象存储里面进行数据的搜索，即我们能够保持对象存储里面的快照数据一直在线可查，通过构建一个小规模的，只带基础存储的计算集群，就可以查阅保存在快照中的海量数据！做到真正的计算和存储分离，并且极大的降低查阅庞大的历史冷冻数据的所需的成本和提高查询效能。（可参考官方博客：使用新的冻结层直接搜索S3）
作为最常用的本地数据保护手段，快照已经成为企业级存储阵列上的必备功能之一，主要用于在线数据备份与恢复，可防范逻辑故障风险，比如病毒攻击、文件格式损坏、系统崩溃以及误删除操作等。
Elasticsearch 提供快照和恢复功能，我们可以在远程文件系统仓库（比如共享文件系统、S3、HDFS 等）中为部分索引或者整个集群创建快照。快照有以下使用场景：
Elasticsearch 可搜索快照是 7.10 版本才有的新功能，之前呼声非常高。
“备份”想必大家都很熟悉了，在日常工作生活中也会经常用到。但是，大型数据集的完整备份可能需要很长时间才能完成，大型企业的数据流是源源不断的。如果用户将文件移动到已备份的目录中，则备份介质上将完全丢失该文件，因为在添加文件之前已进行了备份操作。
在 Searchable snapshots 可搜索快照功能发布之前，通过调用 _snapshot API 对索引打的快照，不管是存储在 S3 还是 HDFS 或者是腾讯云的对象存储 COS上，都是不能够直接进行查询的。
(该请求检索有关快照的基本信息，包括开始和结束时间，创建快照的Elasticsearch版本，包含的索引列表，快照的当前状态以及快照过程中发生的故障列表。)
Longhorn 设计有两层：数据平面(data plane)和控制平面(control plane)。Longhorn Engine 是存储控制器对应数据平面，Longhorn Manager 对应控制平面。
云计算是庞大的IT技术的结合，例如我们经常在云主机ECS中使用的快照功能，仔细研究起来，每一个功能实现都沉淀着“攻城狮的智慧”。今天我们来看一下云快照的两种不同实现机制。
存储网络行业协会SNIA（StorageNetworking Industry Association）快照的定义：关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。
导语 | Elasticsearch 7.10 版本最近发布，该版本有一个重磅特性：Searchable snapshots （可搜索快照功能），可以大幅度地降低存储成本。那么 Searchable snapshots 的使用方式和实现效果是怎样的呢，下面就让我们来一探究竟吧！
一、什么是快照？ 快照可保存虚拟机在特定时刻的状态和数据。 • 状态包括虚拟机的电源状态（例如，打开电源、关闭电源、挂起）。 • 数据包括组成虚拟机的所有文件。这包括磁盘、内存和其他设备（例如虚拟网络接口卡）。 虚拟机提供了多个用于创建和管理快照及快照链的操作。通过这些操作，我们可以创建快照、还原到链中的任意快照以及移除快照。
存储虚拟化可以提高硬件资源的使用效率，简化系统管理的复杂度，增强云存储平台的可靠性。
原因：如果只有一组策略，面向不同的写的场景，会导致数据丢失 - 针对不同读写速度，设置不同策略，进行交叉保存快照，满足各种情况下数据的保存策略
CSI snapshot是由华为在Kubernetes社区主导开发的存储特性，在K8S 1.12进入Alpha阶段。接下来，我们将分为上下两篇，分别介绍snapshot的创建删除等API以及从snapshot还原数据卷，同时，我们将使用CSI hostpath 插件来演示，如何使用这两种特性。
同时，浪尖也在知识星球里发了源码解析的文章。spark streaming的Checkpoint仅仅是针对driver的故障恢复做了数据和元数据的Checkpoint。而本文要讲的flink的checkpoint机制要复杂了很多，它采用的是轻量级的分布式快照，实现了每个操作符的快照，及循环流的在循环的数据的快照。详细的算法后面浪尖会给出文章。
上述问题涉及到集群备份、索引数据备份、数据迁移、数据恢复等问题，而数据备份和恢复又分为：
如果你创建了多于一个的虚拟机快照，那么，你将有多个还原点可以用于恢复。当你创建了一个快照，那快照些现在可写的在那个点上就变成了只读的。使用in-file delta技术就能创建新文件记录所有的关于原始磁盘文件的变更（delta）。
Elasticsearch 支持多种存储库的配置，如 S3、Azure、Google Cloud Storage 和 HDFS 等，具体可参阅「Snapshot And Restore」。在此，我们仅详述如何配置 HDFS 存储库以及利用 HDFS 进行快照和还原的方法。
仓库被注销时，ElasticSearch 只删除仓库存储快照的引用位置，快照本身没有被删除并且在原来的位置
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但某些操作会记住多个事件的信息（例如窗口算子）。 这些操作称为有状态的(stateful)。
我们已经多次关注亚马逊S3、阿里云oss这类对象存储的安全性问题，比如Bucket的权限管理，上传文件的xss问题、AK\SK的保护。如果说对象存储Object Storage Service像云盘，而本文所说的块存储Block Storage是类似于机械硬盘、固态硬盘的“云硬盘”。亚马逊方面在Elastic Compute Cloud (EC2)的实例的持久块存储称为Elastic Block Storage。阿里云EBS是指为ECS云服务器提供的块设备，高性能、低时延，满足随机读写，可以像使用物理硬盘一样格式化、创建文件系统，可用于云硬盘、快照、模板。在底层所承载的分布式存储系统是盘古系统，技术实现类似于HDFS，分为Master、Client、Chunk Server，基本的产品矩阵如下：
K8s 中通过 pvc 以及 pv 的设计体系来简化用户对存储的使用，而存储快照的设计其实是仿照 pvc & pv 体系的设计思想。当用户需要存储快照的功能时，可以通过 VolumeSnapshot 对象来声明，并指定相应的 VolumeSnapshotClass 对象，之后由集群中的相关组件动态生成存储快照以及存储快照对应的对象 VolumeSnapshotContent。
点击上方蓝字每天学习数据库 作者介绍：林锦，腾讯云数据库团队高级工程师，曾任云计算初创公司系统架构师，从事分布式系统研发7年，2017年加入腾讯云，从事NewSQL研发工作，目前主要负责CynosDB for PostgreSQL开发工作。 写在前面：本文主要讲解 CynosDB for PostgreSQL的备份和回档机制及流程，包括数据库实例备份、备份策略、备份流程、内部备份调度、定期快照生成、回档新实例、故障异常、优缺点等。 概述 当前信息时代，数据已成为企业最重要的资产之一，数据丢失引起的后果非常
Elasticsearch 提供了 replica 解决方案，它可以帮我们解决了如果有一个或多个 node 失败了，那么我们的数据还是可以保证完整的情况，并且搜索还可以继续进行。但是，有一种情况是我们的所有的 node，或者有一部分 node 失败，可能会造成我们的数据的丢失。也就是说 replca 不能提供一种灾难性的保护机制。我们需要一种完整的备份机制。
我在之前的博文《Elasticsearch引入可搜索快照（searchable snapshot）》中介绍过Searchable snapshot这个功能，简单来说，通过这个功能，我们能够解锁对象存储简单用作快照备份的功能，实现：
快照模块是 ES 备份、迁移数据的重要手段。ES 快照支持增量备份，支持多种类型的仓库存储。
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service（ES）。
创建快照以后，如果源卷的数据发生了变化，那么快照系统会首先将原始数据拷贝到快照卷上对应的数据块中，然后再对源卷进行改写。
在正常进行索引快照备份的过程中，快照备份任务突然失败。查询仓库，发现仓库不可用，并返回以下异常日志信息。
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但有些操作会记住跨多个事件的信息（例如窗口操作符）。 这些操作称为有状态的。
DeFi、GameFi等去中心化应用的蓬勃发展，极大地增加了对低交易费用的高性能区块链的需求。然而，构建高性能区块链的一个关键挑战是存储爆炸。下图是取自 Etherscan 的图表，它说明了一个以太坊全节点（存档）的区块链数据大小。
DB4AI这个方向中，数据库通过集成AI能力，在用户进行AI计算时就可以避免数据搬运的问题。不同于其他的DB4AI框架，本次openGauss开源的原生框架是通过添加AI算子的方式完成数据库中的AI计算。
一、RAID 独立冗余磁盘阵列 条带化技术，分散存储在多个盘上 (做切割数据的，存在盘上的对应位置，在外观看来就是条带状的) raid的一种 raid级别，仅仅代表raid的组成方式是不一样的，没有上下级之分 raid级别：速度、可用性 利用校验码的形式来保证数据的可靠性（比较麻烦）浪费比例1/n raid类型： 1、raid0 （条带） 性能提升：读写 冗余能力：不具备 空间利用率：n 至少两块盘 2、raid1 （镜像） 性能提升：写性能下降，读性能提高 冗余能力：具备 空间利用率：1/2 正好两个
一、概述 数据一致性是指关联数据之间的逻辑关系是否正确和完整。问题可以理解为应用程序自己认为的数据状态与最终写入到磁盘中的数据状态是否一致。比如一个事务操作，实际发出了五个写操作，当系统把前面三个写操作的数据成功写入磁盘以后，系统突然故障，导致后面两个写操作没有写入磁盘中。此时应用程序和磁盘对数据状态的理解就不一致。当系统恢复以后，数据库程序重新从磁盘中读出数据时，就会发现数据再逻辑上存在问题，数据不可用。 二、Cache引起的数据一致性问题 引起数据一致性问题的一个主要原因是位于数据I/O路径上的各种Cache或Buffer（包括数据库Cache、文件系统Cache、存储控制器 Cache、磁盘Cache等）。由于不同系统模块处理数据IO的速度是存在差异的，所以就需要添加Cache来缓存IO操作，适配不同模块的处理速度。这些Cache在提高系统处理性能的同时，也可能会“滞留”IO操作，带来一些负面影响。如果在系统发生故障时，仍有部分IO“滞留”在IO操作中，真正写到磁盘中的数据就会少于应用程序实际写出的数据，造成数据的不一致。当系统恢复时，直接从硬盘中读出的数据可能存在逻辑错误，导致应用无法启动。尽管一些数据库系统（如Oracle、DB2）可以根据redo日志重新生成数据，修复逻辑错误，但这个过程是非常耗时的，而且也不一定每次都能成功。对于一些功能相对较弱的数据库（如SQL Server），这个问题就更加严重了。 解决此类文件的方法有两个，关闭Cache或创建快照（Snapshot）。尽管关闭Cache会导致系统处理性能的下降，但在有些应用中，这却是唯一的选择。比如一些高等级的容灾方案中（RPO为0），都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的，所以就必须要关闭Cache。 快照的目的是为数据卷创建一个在特定时间点的状态视图，通过这个视图只可以看到数据卷在创建时刻的数据，在此时间点之后源数据卷的更新（有新的数据写入），不会反映在快照视图中。利用这个快照视图，就可以做数据的备份或复制。那么快照视图的数据一致性是如何保证的呢？这涉及到多个实体（存储控制器和安装在主机上的快照代理）和一系列的动作。典型的操作流程是：存储控制器要为某个数据卷创建快照时，通知快照代理；快照代理收到通知后，通知应用程序暂停IO操作（进入 backup模式），并flush数据库和文件系统中的Cache，之后给存储控制器返回消息，指示已可以创建快照；存储控制器收到快照代理返回的指示消息后，立即创建快照视图，并通知快照代理快照创建完毕；快照代理通知应用程序正常运行。由于应用程序暂停了IO操作，并且flush了主机中的 Cache，所以也就保证了数据的一致性。 创建快照是对应用性能是有一定的影响的（以Oracle数据库为例，进入Backup模式大约需要2分钟，退出Backup模式需要1分钟，再加上通信所需时间，一次快照需要约4分钟的时间），所以快照的创建不能太频繁。 三、时间不同步引起的数据一致性问题 引起数据不一致性的另外一个主要原因是对相关联的多个数据卷进行操作（如备份、复制）时，在时间上不同步。比如一个Oracle数据库的数据库文件、 Redo日志文件、归档日志文件分别存储在不同的卷上，如果在备份或复制的时候未考虑几个卷之间的关联，分别对一个个卷进行操作，那么备份或复制生成的卷就一定存在数据不一致问题。 此类问题的解决方法就是建立“卷组（Volume Group）”，把多个关联数据卷组成一个组，在创建快照时同时为组内多个卷建立快照，保证这些快照在时间上的同步。之后再利用卷的快照视图进行复制或备份等操作，由此产生的数据副本就严格保证了数据的一致性。 四、文件共享中的数据一致性问题 通常所采用的双机或集群方式实现同构和异构服务器、工作站与存储设备间的数据共享，主要应用在非线性编辑等需要多台主机同时对一个磁盘分区进行读写。
在使用存储时，为了提高数据操作的容错性，我们通常需要有对线上数据进行 snapshot ，以及能快速 restore 的能力。另外，当需要对线上数据进行快速的复制以及迁移等动作，如进行环境的复制、数据开发等功能时，都可以通过存储快照来满足需求，而 K8s 中通过 CSI Snapshotter controller 来实现存储快照的功能。
作者 | Xing Yang, VMware & Xiangqian Yu, Google
Kubernetes 卷快照功能现在Kubernetes v1.17中处于beta版。它在Kubernetes v1.12中作为Alpha引入，在Kubernetes v1.13中是作为第二个Alpha版，并作了很大的改动。本文总结了beta版本中的变化。
导语 | CBS云硬盘为腾讯云客户提供了⾼可靠、⾼可⽤和低成本的统⼀块存储服务。CBS针对数据安全、云服务器⽣产、资源均衡、云盘介质升级等场景下的数据调度能⼒需求，抽象出统⼀数据调度平台。本文是对腾讯云存储专家工程师——杨光超在云+社区online的分享整理，希望与大家一同交流。
关于如何创建快照和恢复快照，可以参考这篇：干货 | Elasitcsearch7.X集群/索引备份与恢复实战。
Apache Flink提供了一个容错机制来持续恢复数据流应用程序的状态。该机制确保即使在出现故障的情况下，程序的状态也将最终反映每条记录来自数据流严格一次exactly once。 请注意，有一个开关可以降级为保证至少一次(least once)（如下所述）。
之前我们生产 ES 集群因为数据分片过大，导致集群重启无法选举，具体可以看这篇文章。当系统分片数据量越来越大，给生产集群造成一定压力，同时也会影响数据检索和查询效率。为了减轻集群压力，缩小集群分片数，减少集群故障，需要考虑数据归档方案，将查询频率低的数据从集群中归档到一个集中区域。
请注意，在恢复快照时，任何在创建快照之后对虚拟机所做的更改都将被丢弃，并还原为快照创建时的状态。因此，请确保在执行恢复操作之前备份重要数据。
点击上方“腾讯云TStack”，关注我们，获取最in云端资讯和海量技术干货~ ●导语● 快照一般是指数据存储的某一时刻的状态记录，类似于给数据按下快门拍了一张照片，所以也叫snapshot。而存储系统的快照在云计算中广泛使用，比如块存储的快照。很多其他高级功能基本都要依赖快照来实现，比如备份、热迁移等。而对于快照，我们经常会问的一个问题就是快照的数据是不是完整的，会不会出现快照回滚之后数据丢失。其实这也就是我们常说的快照数据一致性问题。 下面主要分以下几点进行讨论： (1) 一致性的分类 (2)
RHEL7如何对磁盘进行分区和格式化以及如何配置LVM，与以前版本的RHEL区别不大，可以通过disk工具（在图形桌面中运行）或命令工具（如：fdisk、gdisk、parted）管理硬盘设备。fdisk可以配置MBR格式； gdisk配置gpt格式， parted可以自己选择。 传统的硬盘分区都是MBR格式，MBR分区位于0扇区，他一共512字节，前446字节是grub引导程序，这个会在后面学习；中间64字节是分区表，每个分区需要16个字节表示，因此主分区和扩展分区一共只能有4个分区，超过4个的分区只能从扩展分区上再设置逻辑分区来表示。每个分区的大小无法超过2T。 MBR的最后2个字节是结束符号 GPT格式，打破了MBR的限制，可以设置多达128个分区，分区的大小根据操作系统的不同有所变化，但是都突破了2T空间的限制。支持高达 18EB (1EB=1024PB，1PB=1024TB) 的卷大小，允许将主磁盘分区表和备份磁盘分区表用于冗余，还支持唯一的磁盘和分区 ID (GUID)。 与 MBR 分区的磁盘不同，GPT的分区信息是在分区中，而不象MBR一样在主引导扇区。为保护GPT不受MBR类磁盘管理软件的危害，GPT在主引导扇区建立了一个保护分区 (Protective MBR)的MBR分区表，这种分区的类型标识为0xEE，这个保护分区的大小在Windows下为128MB，Mac OS X下为200MB，在Window磁盘管理器里名为GPT保护分区，可让MBR类磁盘管理软件把GPT看成一个未知格式的分区，而不是错误地当成一个未分区的磁盘 在MBR硬盘中，分区信息直接存储于主引导记录(MBR)中（主引导记录中还存储着系统的引导程序）。但在GPT硬盘中，分区表的位置信息储存在GPT头中。但出于兼容性考虑，硬盘的第一个扇区仍然用作MBR，之后才是GPT头。
小伙伴们思考一下，都能回答上来么，如果对于某些问题你还有疑问，楼主会通过本篇文章帮你解答这些问题，理清这些概念！
虚拟机提供了多个用于创建和管理快照及快照链的操作。通过这些操作，您可以创建快照、还原到链中的任意快照以及移除快照。可以创建层层快照树。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
