存储快照

物理卷相关

≡放荡痞女 提交于 2019-11-27 20:53:14
一、理解快照的含义 所谓快照就是照下来的那一刻保留起来作为文件的访问通道,将没修改之前保存在快照存储空间中一份,访问的是外面的数据,如果数据修改出现错误时,可以通过快照的访问路径把存储在快照存储空间中的数据放到被修改的数据中,快照存储空间中只存储没修改前的数据,占据空间比较小。 快照的主要作用是保留数据在你做快照那一刻的状态,创建的快照文件本身和你装的操作系统所对应的那块虚拟磁盘本身的大小不一样,快照比原数据小很多,跟文件软链接一样,自己本身不大,但自己所指的文件是很大的。 默认情况下,访问数据时只有一条路径,给磁盘上对应的文件系统做一快照以后,意味着在它之上安装一条访问路径,但这个路径不仅仅是路径而已,它也可以用于用户访问对应的磁盘上的通路。 二、物理存储介质、物理卷、逻辑卷、卷组、快照卷之间的联系 》物理存储介质(PhysicalStorageMedia):指系统的物理存储设备==>磁盘,如:/dev/hda、/dev/sda等,是存储系统最底层的存储单元。 》物理卷(Physical Volume,PV):指磁盘分区或从逻辑上与磁盘分区具有同样功能的设备(如RAID),是LVM的基本存储逻辑块,但和基本的物理存储介质(如分区、磁盘等)比较,却包含有与LVM相关的管理参数。 》卷组(Volume Group,VG):是由一个或多个物理卷所组成的存储池

Redis系列四:redis持久化

╄→尐↘猪︶ㄣ 提交于 2019-11-27 18:41:10
redis支持RDB和AOF两种持久化机制,持久化可以避免因进程退出而造成数据丢失。 两种持久化可以单独使用其中一种,但更多情况下是将二者结合使用。 一、RDB持久化 RDB持久化把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,有手动触发和自动触发。 redis会在以下几种情况下对数据进行快照。 a)根据配置规则进行自动快照; b)用户执行save或bgsave命令; c)执行flushall命令; d)执行复制(replication)时; 1、根据配置规则进行自动快照 允许用户自定义快照条件,当符合快照条件时,redis会自动执行快照操作。进行快照的题哦啊键可以由用户在配置文件中自定义,由两个参数构成:时间窗口M和改动的键的个数N。每当时间M内被更改的键的个数大于N时,即符合自动快照条件。 如redis安装目录中包含的样例配置文件中预置的3个条件: save 900 1 save 300 10 save 60 10000 每条快照条件占一行,并且以save参数开头,同时可以存在多个条件,条件之间是“或”的关系。上例中,save 900 1的意思是在15分钟(900秒)内有一个或一个以上的键被更改则进行快照,同理,save 300 10表示子啊300秒内至少有10键被修改进行快照。 2、手动触发有save和bgsave两命令 除redis自动进行快照外,服务重启

ceph中rbd的增量备份和恢复

断了今生、忘了曾经 提交于 2019-11-27 12:09:25
ceph中rbd的增量备份和恢复 ceph的文档地址: Ceph Documentation ​ 在调研OpenStack中虚机的备份和恢复时,发现OpenStack和ceph紧密结合,使用ceph做OpenStack的后端简直是不要太爽,于是调研了使用ceph中的块设备rbd来对虚机进行增量备份和恢复。以下是虚机备份和恢复的实验步骤: 1. 前言: ​ 快照 的功能一般是基于时间点做一个标记,然后在某些需要的时候,将状态恢复到标记的那个点,这个有一个前提是 底层的数据没有破坏 ,举个简单的例子, Vmware 里面对虚拟机做了一个快照,然后做了一些系统的操作,想恢复快照,前提是存储快照的存储系统没用破坏,一旦破坏了是无法恢复的。 ​ ceph也有快照功能,同样,在这里的快照是用来保存存储系统上的状态的,数据的快照能成功恢复的前提是存储系统是好的,而一旦存储系统坏了,快照同时会失效的,所以最好是能够将数据备份下来。本篇博客主要是调研使用ceph的rbd命令来对存储设备进行基于快照的增量备份。 2. ceph中rbd的常用命令: 2.1列出存储池 ceph osd pool ls 2.2 查看存储池的内容 rbd ls --pool pool_name 例子 rbd ls --pool volumes 2.3 打快照 rbd snap create {pool-name}/

Redis持久化

拥有回忆 提交于 2019-11-27 09:27:29
1、 简介 数据存放于: 内存 => 高效、断电(关机)内存数据会丢失 硬盘 => 读写速度慢于内存,断电数据不会丢失 2、 持久化方案之 RDB 2.1. RDB ( Redis DataBase )简介 RDB :是 redis 的默认持久化机制。 RDB 相当于快照,保存的是一种状态。 几十 G 的数据 = 》 几 KB 的快照 快照是默认的持久化方式。这种方式是将内存中的数据以快照的方式写入到二进制文件中,默认的文件名叫 dump.rdb 。 2.2. RDB 优缺点 优点: 快照保存数据极快,还原数据极快 适用于灾难备份 缺点: 小内存机器不适合使用, RDB 机制符合要求就会照快照。 2.3. 快照条件 1、 服务器正常关闭时 ./bin/redis-cli shutdown 2、Key 满足一定条件,会进行快照 命令: vim redis.conf 搜索 save : :/save 3、 持久化方案之 AOF ( Append-only file ) 3.1. AOF 简介 由于快照方式是在一定时间间隔做一次的,所以如果 redis 意外 down 掉的话,就会丢失最后一次快照后的所有修改。如果引用要求不能丢失任何修改的话,可以采用 aof 持久化方式。 Append-only file :比快照方式有更好的持久化性,是由于在使用 aof 持久化方式时, redis

redis 两种持久化方式以及数据备份与恢复方案

白昼怎懂夜的黑 提交于 2019-11-27 05:51:20
前言 redis提供了数据持久化的方式,提供数据持久化的意义在于数据的恢复、生产环境下的灾难恢复。 本文将会围绕redis的两种持久化方式对于它们的运行机制、注意事项、备份方案以及基于灾难恢复的场景下的数据恢复方案。 RDB和AOF两种持久化方式 RDB方式 RDB持久化会对redis中的数据进行周期性的持久化,生成一份快照文件,存放在配置文件声明的目录下面的dump.rdb文件。在redis配置文件中可以通过配置dir属性来指定持久化文件存放目录。默认情况下RDB持久化是打开的,可以在配置文件中找到如下内容: save 900 1 save 300 10 save 60 10000 上述命令之的是如果900秒内有1个key发生了变化,生成一份快照文件,如果再300秒内有10个key发生了改变,生成一份快照文件,如果在60秒内有10000个key发生了改变,生成一份快照文件。 save可以设置多个,就是多个snapshotting检查点,每到一个检查点,就会去检查一下,是否有指定的key数量发生变化,如果有就生成一个新的dump.rdb文件 也可以通过save或者bgsave命令同步或异步指定rdb快照生成。 RDB持久化的工作流程 redis根据配置自己尝试生成rdb快照文件 fork一个子进程出来 子进程尝试将数据写到临时的rdb快照文件中 完成rdb快照文件的生成之后

Redis持久化rdb&aof

╄→гoц情女王★ 提交于 2019-11-26 14:26:32
Redis持久化rdb&aof 前言 持久化:即把数据存储于断电后不会丢失的设备中,通常是硬盘 常见的持久化方式: 主从:通过从服务器保持持久化,如mongoDB的replication sets配置 日志:操作生成相关日志,并通过日志来恢复数据 Redis持久化之 RDB(Redis DataBase)   介绍 在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存里。 每隔N分钟或N次写操作后,从内存dump数据形成rdb文件,压缩放到备份目录。 持久化过程 Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写到一个临时文件中,待持久化过程结束了,再用这个给临时文件替换上次持久化好的文件。 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常的敏感,那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。 Fork Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。 补充: Rdb保存的是dump.rdb文件。 参数 Save 1分钟内改了1万次 5分钟内改了10次 15分钟内改了1次

Elasticsearch 备份数据到 AWS S3

我是研究僧i 提交于 2019-11-26 00:46:40
ES集群备份数据到S3 集群环境: 系统版本:centos 7.3 安装方式 : yum ES版本环境: 6.0.1 基本概念 使用 Elasticsearch Snapshot 时需要有一些基本概念澄清,他不是拿指定的 Indices 文件做个压缩包丢在 S3 完事,他是有控制的。 snapshot 结构 Elasticsearch 的 snapshot 是由其自身控制的,整个系统保持了一个如下的从下到上的控制结构,他们具备包含关系: snapshot --> repository --> single snapshot --> indices snapshot 这里将 snapshot 单独列出,是因为在 Elasticsearch 中 snapshot 独占性工作的,他更像是一个管道,任何一个 repository 在工作的时候是排他的,虽然他并不阻止 indices 的写入。 repository 这个仓库应该是一组 snapshot 备份的集合,也可以认为是一个目标的选择。在一个 Elasticsearch 系统中你可以根据自己的意愿设定不同的 Repository。 Single snapshot 这个指的是在 Repository 中我们进行的每个备份内容,他更像一个集合,包含了这次 snapshot 中所有的 Indices。 Indices 在一个

[leetcode 周赛 148] 1146 快照数组

南楼画角 提交于 2019-11-25 21:58:33
目录 1146 Snapshot Array 快照数组 描述 思路 代码实现 1146 Snapshot Array 快照数组 描述 实现支持下列接口的「快照数组」- SnapshotArray: SnapshotArray(int length) - 初始化一个与指定长度相等的 类数组 的数据结构。初始时,每个元素都等于 0 。 void set(index, val) - 会将指定索引 index 处的元素设置为 val 。 int snap() - 获取该数组的快照,并返回快照的编号 snap_id (快照号是调用 snap() 的总次数减去 1)。 int get(index, snap_id) - 根据指定的 snap_id 选择快照,并返回该快照指定索引 index 的值。 示例 输入 :["SnapshotArray","set","snap","set","get"] [[3],[0,5],[],[0,6],[0,0]] 输出 :[null,null,0,null,5] 解释: SnapshotArray snapshotArr = new SnapshotArray(3); // 初始化一个长度为 3 的快照数组 snapshotArr.set(0,5); // 令 array[0] = 5 snapshotArr.snap(); // 获取快照,返回 snap