用好“快照”!(使用快照有什么好处理)
mhr18 2024-10-13 02:59 55 浏览 0 评论
“
5月中旬,WannaCry比特币勒索病毒
利用Windows安全漏洞,袭击全球。
我在《勒索病毒预防实战:有的PC打不上补丁咋办?》 中,
提到了如何预防以及数据备份的重要性。
然而有了备份就能万无一失吗?
”
为预防病毒而备份
却破坏了系统为哪般?
就在病毒发作的那几天,有一位网管朋友给我打电话讲了他的遭遇。
这位朋友单位有一台Windows服务器系统盘做的RAID1,上面的操作系统和应用没有备份,担心被病毒加密文件,于是用某大厂的系统备份/恢复软件进行了操作。具体来说是用光盘/U盘引导的方式,像Ghost那样将C盘中的数据先备份到后面的分区中(我理解事后还要拷出来),而在这个操作完成之后服务器操作系统起不来了…
事后朋友发现,原来他的服务器是用Windows系统做的软RAID1,BIOS里的RAID选项并没有打开(其实这也是一种软RAID,稍后再谈)。如上图所示,在Windows中对D分区的访问都是在镜像卷上操作,而在进入OS之前呢?像一些第三方引导盘有可能不会加载动态磁盘上的镜像卷,而直接对单盘进行了操作。经过数据恢复处理之后,朋友发现C盘的备份镜像只被写入了其中一块磁盘,软RAID破坏也就在所难免了。
再打个比方,如果Linux用户在物理磁盘sd*上创建了LVM Mirror,这时如果再对底层的sd*进行写操作也是同样的道理。
尽管有些操作系统支持不只一种带有容错功能的软RAID,但实际使用的人并不多,除了性能和故障之后的恢复难度之外,还有一个问题就是防呆。
所谓的“软”RAID
到底软在哪里?
不依赖操作系统的软RAID,如果扩大点范围来看也有好几种。
第一种是主板集成的RAID,无第三方控制芯片,依靠BIOS里加载的Firmware来配置。都是软RAID也有区别,比如Intel RST就是要在Windows驱动加载后才能进行Rebuild。
由于现在主板芯片组提供的SATA接口越来越多,第三方芯片生存空间不大。比较高级一些的是SAS控制器/HBA、入门级RAID卡提供的软RAID功能,比如基于LSI 2308、3008这些芯片或者Dell PERC H3xx这样的RAID卡。将它们称之为软RAID是因为不像传统SAS“硬”RAID卡(如使用LSI 2108、3108芯片或者Dell H7xx/8xx系列等)那样具备本地缓存和掉电保护设计。通常来说这类软RAID 5的性能不会好,但其保护机制基本在卡上实现,对各种操作系统不透明也就不会出现上面遇到的那种问题。
上面介绍了2类软RAID,早年还曾有更麻烦一些的。比如HighPoint有的ATA控制器在Linux中内嵌非RAID驱动,会把RAID直接认成单盘,这样加载驱动的难度就会加大。还有Adaptec在Ultra320 SCSI时代引入的HostRAID,也是能用非RAID SCSI驱动认成单盘。这些连防呆都不够好的软RAID,我遇到有些用户不愿接受。
Windows备份介质服务器
存在的潜在风险
以上讨论的主要是“隔离性”。RAID是一种物理保护,而作为数据保护的备份技术还要考虑逻辑上的隔离,一个基本原则就是恶意软件或者用户误删除等操作都不应影响到备份数据的完整性。然而并不是每一个备份部署中都做到了这点。
上图引用自《DellWorld15:图解NetVault Backup 11智能备份》一文,是以原Dell软件部门(Quest)的备份软件为例来介绍传统备份架构。这里面的基础知识我就不重复叙述了,主要说一下可能存在风险之处。
注:以下讨论并不针对具体哪家备份产品,我也不确定此次的病毒一定会破坏网络共享文件路径。但从“读取文件-加密后保存-再删除原文件”的机制来看,并不需要感染备份目标上的可执行文件并运行,此类程序就可造成破坏。
首先,物理磁带和VTL(虚拟磁带库)设备通常不在恶意软件攻击之列,因为它们不支持传统文件操作,需要用特定命令/备份软件来读写。
我还与做备份的朋友交流过,对于传统的LAN备份,Windows客户端通过网络将数据发送到备份服务器,这个过程一般是安全的。如果备份服务器也部署在Windows系统上,一旦磁盘备份介质以OS可识别的文件格式挂载上来,还是存在被恶意破坏的可能。以本次的勒索病毒为例,Windows备份介质服务器在有些情况下也要注意安全。
上图左上角部分描述的是备份NAS上的数据到磁带,目前也有一部分中小企业用户选择NAS设备做为备份目标。对于这种方式,无论CIFS文件共享直连Windows客户端还是备份服务器(其实都是介质服务器了),都有可能存在风险隐患。而如果采用DD Boost、OST、RDA这些带有源端去重的专用备份协议,或者将备份空间格式化为专用文件系统的会更安全一些。
比如我见过一种取巧的LAN-Free备份支持说法,将FC接口磁盘阵列挂给应用服务器的LUN格式化为文件系统,并做为备份目标。这样做虽然没有用磁带类设备,但数据流确实走光纤了。此时如果是Windows文件系统,备份数据显然也难逃恶意破坏的可能。
虽然从上面的例子中侧面反映出传统磁带备份的安全性,而我们也不能忽略磁带介质管理上的复杂度和高维护成本。LAN-Based磁盘备份的Client-Server架构看来也有安全性方面的可取之处,不过在云计算的时代一些厂商提倡无代理备份,甚至(站在自己角度上)说备份代理也可能成为被攻击的对象。在内网里相对还好,接入公网需要考虑的安全问题确实更多,当然这些讨论有点超出本次勒索病毒的范畴了。
影响存储快照使用率的
六大因素
前面我们讲了NAS上的用户数据有可能遇到被病毒感染/加密破坏的情况,SAN块存储阵列也不例外。但如果用户配置了快照功能,找到数据被破坏时间点之前创建的快照即可迅速恢复,验证数据的完整性也不需要等待传统备份冗长的恢复过程。从另一个角度来讲,在需要进行各种逻辑层面数据恢复操做之前,手动打一个快照也可以快速“保护现场”。
不少人说快照好,而客观上看,定时备份应该还是应用最普遍的数据保护措施,尽管一些提供CDP(持续数据保护)产品宣传他们的RPO和RTO有多么短。
对于有些新型备份技术普及的不是太好,原因无外乎两大类:一个是成本;另一个是实际效果,包括部署复杂度、对应用性能影响、能否胜任长期历史数据保护等。
其实有些CDP、Near-CDP产品底层也是基于快照,特别是即时挂载恢复的功能。有时候我觉得,朴素而不花哨的技术反而适用性更强。快照的原理讲起来并不复杂,却不是每家都容易做得很好,因为据我们了解各厂商存储快照的使用率相差还是蛮大的,下面就来谈谈影响这一选择的六大因素。
快照会不会影响生产存储的性能?
首先我承认有的存储快照会对性能产生明显的影响,一般认为ROW(写重定向)比(COFW)写时复制快照的开销要小。而同样属于ROW快照分类,大家支持的快照频率、数量等方面又有不小的差距。总的来说,影响效率的主要是元数据的管理,通常底层空间完全打散的块级虚拟化(即RAID 2.0类)阵列在这方面表现较好。
上图引用资料有点早,如今最上面的Tier1存储分层往往使用高性能SSD,用RAID 1保证写入效率;Tier3使用大容量NL-SAS硬盘RAID 6比较多。在每种驱动器类型中还可以存在不同RAID类型之间的分层,这是Dell SC的一大特色。
以Dell SC系列来说,早在多年前就将快照(Replay)技术作为自动分层存储数据调度的触发机制。大家应该了解Compellent自动分层技术在业界的地位,用SSD来加速甚至在不同闪存类型的分层,可见其对自身快照技术的性能有足够的信心。
快照占用宝贵的生产存储空间,成本上是否划算?
按照常规理解,用于生产业务数据的一级存储,其单位容量成本比用于备份、归档的二、三级存储要高。那么如果在一级存储上保留较多的历史快照数据,甚至用来部分替代备份,会不会划算呢?特别是现在许多备份存储产品还能支持重复数据删除技术。
这时又要提到自动分层存储技术了,还是以Dell SC为例,其快照数据分为“冻结可访问”(仍被活动LUN引用)和“冻结不可访问”数据页面两个区域,可以采用预置或者手动定义的策略来选择它们的存放位置。后者即传统意义上的历史备份数据,通常会放在最底层的大容量廉价NL-SAS硬盘上,RAID 6保护。由于存储快照不像多次全备份之间的冗余数据量比例那么大,再加上压缩技术就能做到不错的TCO了。
对于大型一些的存储部署,如果对2U 12个3.5寸盘位的密度不够满意,还有5U 84盘位扩展柜可选(参考《存储极客 | 高密度盘柜难点:评戴尔SCv2080结构设计》),专门适合海量非结构化数据、备份/归档等。
快照保护数据的周期有多长?
上图引用自《存储极客:多方位全面保护数据库》
根据不同的产品定位,Dell SC系列存储支持的快照总数约在4000-32000个之间,一般对于RPO要求较高的用户,其快照间隔可能会设置在5分钟-1小时。按照每个LUN最多1000个快照来计算,5分钟频率最老的一份数据是3天多之前,而1小时则可以保护长达41天的数据。要知道还有许多用户在使用每天一次的快照策略。
快照数据的一致性问题
在《GitLab事件思考:是否用的快照恢复?》一文中,我曾讨论过快照的一致性问题、性能问题、容量开销与应对这几个方面。就其中第一点还分为多个卷(LUN)之间的时间点一致性,以及快照数据的应用一致性两个方向,大多数企业级集中存储系统对此都有考虑。
上图引用自《工程师笔记:SCv2000试用之RAID分层+快照》
除了针对Oracle数据库的APM(Application Protection Manager)一致性代理之外,Dell SC ReplayManager对于VMware虚拟机以及微软环境也提供对应的插件/服务来支持。比如Window下的SQL Server、Exchange和Hyper-V等就是与VSS配合来生成一致性快照的。
多说一句,在存储写入压力大的环境,有了一致性代理也未必保证每个快照都能完美地打开数据库等应用。不过这个成功率还是比较高,并且即使没有一致性的快照也就相当于主机异常断电的数据状态,麻烦一些但还是有异常恢复的措施。
快照可以替代备份用于容灾吗?
尽管企业级存储的可用性和数据可靠性已经相当高,但就像任何数据中心设备那样,面对机房故障、站点级灾难还是无能为力。存储上的快照副本对于前端主机可以做到很好的隔离,但数据毕竟还是位于同一个(或几个)机箱中,达不到异地容灾、高等级保护的要求。
上图引用自《存储极客:大话“双十一”与经济适用型双活》一文,在支持Live Volume双活/同步复制的同时,Dell SC存储还可以将快照保护的数据,通过专线或者广域网异步远程复制到同城灾备机房,乃至数千公里之外的两地三中心部署。
这就像一种增量备份的效果,并且复制的两端可以按需保留不同的历史快照数量,定义不同的压缩开关等。值得一提的是,新兴分布式软件定义存储(ServerSAN)大多在原生复制等企业级功能上的支持还不完善。
快照要不要买License,会增加存储软件成本吗?
有些存储阵列的快照免费提供的数量很有限,要支持更多就得买License。而Dell SC的快照功能在大多数型号上全免费提供,用于容灾的远程异步复制功能收费但价格不高。
最后,希望读者朋友们也能够用好快照,在存储端提高数据保护的效率。
相关推荐
- 软考架构师-案例分析之Redis(软考架构师真题)
-
软考架构师考试中,Redis的知识考了很多回,从最近几年来看,案例分析经常考,有的时候单独考,有的时候和其他知识点一起考。Redis过往的考试中,考过的知识如下:1、Redis特点,涉及数据类型、持久...
- 揭秘:视频播放网站如何精准记录用户观看进度
-
在互联网蓬勃发展的当下,视频内容已毫无争议地成为人们获取信息、享受娱乐休闲时光的核心方式。据权威数据统计,全球每天有数十亿小时的视频被观看,视频流量在网络总流量中的占比逐年攀升,预计在未来几年内将超过...
- 量子级一致性!Flink+Redis全局状态管理
-
百万级实时计算任务如何实现亚毫秒级状态访问?本文揭秘Flink+Redis的量子纠缠态状态管理方案,将状态延迟降至0.3ms。引子:实时风控系统的量子跃迁//传统Flink状态管理(基于RocksD...
- 在 Mac 上运行 Redis 的 Docker 容器
-
在Mac上运行Redis的Docker容器,你可以按以下步骤操作,非常简单高效:一、前提要求已安装DockerDesktopforMac可通过终端验证Docker是否可用:d...
- 从 0 到 1:使用 Nginx + Lua 打造高性能 Web 网关
-
在大规模分布式架构中,Web网关扮演着重要角色,负责请求转发、负载均衡、限流、认证等功能。而Nginx+Lua结合可以提供:o高性能:Nginx是目前最流行的高性能Web服务器o动...
- 外贸独立站缓存设置黑科技:用错Redis比没缓存更致命
-
上周帮一个杭州卖家排查网站崩溃问题,发现这老铁把Redis缓存设置成128MB还开着持久化,服务器内存直接炸得比春节红包还彻底——"你这哪是缓存啊,根本是DDoS攻击自己!"最近Clo...
- Spring Boot3 整合 Redis,这些缓存注解你真的会用吗?
-
你在开发SpringBoot3项目时,有没有遇到过这样的困扰?随着项目功能不断增加,数据量逐渐庞大,接口响应速度变得越来越慢,用户体验直线下降。好不容易找到优化方向——引入Redis缓存...
- MySQL处理并发访问和高负载的关键技术和策略
-
MySQL处理并发访问和高负载的关键技术和策略主要包括以下几个方面:一、硬件优化1.CPU:提升CPU处理能力可以明显改善并发处理性能。根据数据库负载,考虑使用更多的CPU核心。2.内存:增加内存可以...
- druid解决高并发的数据库(druid多数据源配置 spring boot)
-
处理高并发的时候可以解决我们java一个核心问题java核心问题就是并发问题解决并发一个是redis一个是线程池的方式现在出来是个druid好像现在解决高并发的方式进行更换数据库的方式操作场景插入频繁...
- 高并发方案最全详解(8大常见方案)
-
关注△mikechen△,十余年BAT架构经验倾囊相授!大家好,我是mikechen睿哥。高并发是大型架构的核心,下面我重点来详解常见8大高并发方案@mikechen文章来源:mikechen.cc分...
- MySQL如何处理并发访问和高负载?(mysql如何处理并发访问和高负载访问)
-
MySQL在处理并发访问和高负载方面,采取了一系列关键技术和策略,以确保数据库系统在面对不断增长的并发需求时维持高效和稳定的性能。以下是对这些技术和策略的详细阐述,旨在全面解析MySQL如何处理并发访...
- Redis高可用集群详解(redis高可用方案以及优缺点)
-
Redis集群与哨兵架构对比Redis哨兵架构在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具监控master节点状态,如果master节点异常,则会做主从切换,将某一台sla...
- MCP协议重大升级!Spring AI联合阿里Higress,性能提升300%
-
引言:一场颠覆AI通信的技术革命2025年3月,MCP(ModelContextProtocol)协议迎来里程碑式升级——StreamableHTTP正式取代HTTP+SSE成为默认传输层。这一...
- 阿里三面被挂,幸获内推,历经5轮终于拿到口碑offer
-
作者:Java程序猿阿谷来源:https://www.jianshu.com/p/1c8271f03aa5每一个互联网人心中都有一个大厂梦,百度、阿里巴巴、腾讯是很多互联网人梦寐以求的地方,而我也不例...
- 来瞧瞧阿里一面都面些什么(笔试+机试)
-
絮叨说实话,能有机会面一下阿里对我来说帮助确实有蛮多,至少让我知道了自己的不足在哪,都说面试造火箭,上班拧螺丝。但就算是如此,为了生存,你也只有不停的学习,唯有光头,才能更强。哈哈起因2月28日在Bo...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis同步 (53)
- redis结构 (53)
- redis 订阅 (54)
- redis 登录 (62)
- redis 面试 (58)
- redis问题 (54)
- 阿里 redis (67)
- redis的缓存 (57)
- lua redis (59)
- redis 连接池 (61)