摘要

对于每一个企业来讲,数据备份都是必不可少的一项关键性工作,它直接决定着企业能够应对什么样的数据威胁以及相应解决方案的灵活度和有效性。但是在IT飞速发展的今天,每一个企业的应用系统在不断增加,数据类型在不断的多样化,数据的量级也在不断的扩展。在这种形势下,如何能把备份系统规划的科学合理并且高效化是作为IT建设者必须考虑的问题。

本文通过大量的调研分析总结抽象出备份系统规划时必须考虑的几个关键性问题,并针对每一个问题进行分析和论述,提出解决思路。希望能给企业进行备份系统建设、改造或者升级的项目带来一些启示和帮助。

1.如何确定备份对象及备份策略

近些年来,企业的数据逐渐呈现多元化格局,从数据的模型层面可以分为结构化数据、半结构化数据、非结构化数据。从企业IT功能层面又可以将常见数据列为如下几类:

作为企业来讲,确定备份哪些数据对象,需要从数据重要性、数据量、数据特点等若干方面去评估。从企业业务角度评估的话,那么数据库保存的数据一定是最重要的,尤其是关系型数据库里面的二维表数据。其次需要根据行业特点以及具体的业务系统重要性来评估非结构化数据的重要性。比如对于金融行业来讲,记录业务过程的一些影像类数据可能在业务审核过程中经常被调出查阅,这些数据虽然没有结构化数据那么重要但是也是业务环节当中比不可少的元素,其重要性相对业务视频类以及安防类视频数据会高很多。但是如果是媒体行业的话,那么视频类数据的重要性恰恰是支撑其业务的核心数据,其重要程度不言而喻。那么如何来决定哪些数据需要备份,以什么样的策略备份?

首先,我们需要确定数据的重要性程度。本文通过结果导向的思路从以下维度来分析企业数据的重要性,最终决定哪些数据需要备份,哪些数据可以不备份,哪些数据需要根据企业的实际投资战略情况来决定。首先我们假定一个结果,那就是某个应用系统的某类型数据由于硬件故障或者其他原因导致数据丢失掉了。那么就看企业对该结果的容忍程度,假设不能容忍,那么就没什么好商量的了,肯定要做备份。接下来,最重要的事情是我们如何定义数据备份的策略,包括备份的频度、备份的模式、归档的档期等等一系列备份作业元素。这部分内容需要考虑到数据本身的量级、数据的具体类型、极端条件下对数据恢复时间及数据丢失量的容忍程度、数据备份系统以及备份介质本身的性能特性、业务发展的规模及趋势判断等等。本文从以下几个原则来进行评估:

以上是对备份对象的确定以及如何把握具体的备份策略的分析和描述,具体细节及关键方法在接下来的章节会有详细的剖析和介绍。

2.如何选择备份架构的问题

2.1 备份系统涉及到的关键对象

所谓备份系统中的一些关键对象包括:备份软件、备份介质、备份管理服务器、备份作业服务器、备份路径等。这些关键元素共同组成了一个完成的备份系统。

2.2 基于容灾功能的备份架构

一般的企业可能只需要进行本地备份即可,但是对于某些行业尤其是金融行业,备份要求比较高,需要采用主数据中心和备数据中心联动的高可用备份架构。具体如下图所示:

itunes有备份无法恢复备份_备份集中的数据库与现有的数据库不同_钛备份+备份应用数据

整体架构从上到下分为三层:备份客户端层、备份控制层以及数据存储层。中间通过网络(以太网络或者是光纤网络)相连接。红色线表示控制信息流向,蓝色线表示备份过程中的数据流向。

2.3 备份架构高可用性分析

整个备份系统的高可用性是由每一个部分服务的高可用配置来保障的,主要包括备份控制层、备份存储介质层以及跨数据中心级别的高可用架构配置。下面我们分别来做剖析:

3.如何解决非结构化数据备份的问题

3.1 非结构化数据备份面临的困境

对于存储在传统NAS文件系统上的文件类数据,如果用通用的备份方法只能通过文件复制的方式来实现其全量和增量备份。但是随着日积月累的非结构化数据增长,这类数据可能会从TB级别发展到10TB甚至PB级别。这类数据存储组织的方式是文件系统的树目录形式,随着数据的增加,其目录的深度和规模也会呈现剧增趋势。备份软件在扫描文件目录的时候会变得非常非常慢,最终导致备份作业慢到超过备份窗口的程度。

3.2 业务管理层面的解决方案

如果从业务管理层面来解决该问题的话,那么就是要让备份作业在一定时间段内保持在合理的数据量范围之内,也就是说要形成合理的多级数据缓存,根据数据使用频度建立多级转储以及归档体系。保障使用频度高的数据在日常备份作业范围内,合理归档使用频率非常低的历史数据。拿金融行业的票据、信贷类系统来说,我们可以将合理业务周期内的非结构化数据存在在一级缓存当中,保障业务复核阶段的数据读取;将业务周期外的非结构化数据转储到二级NAS平台上,保障近期内可能使用到的业务场景;将较长周期之前的数据定义为离线数据,归档到归档存储设备当中。备份仅仅涉及到归档之前的数据。这样既可以保障数据存取的性能,又能保障备份作业的长期稳定性,最终保障备份系统整体的安全稳定。

3.3 技术管理层面的解决方案

通过3.1章节对问题的原因分析,我们知道导致备份无法进行的原因在于备份软件对于庞大文件系统目录的扫描时间过长。那么顺着这个思路,如果我们在备份的时候能避免去扫描整个文件系统目录,而是通过别的方式来完成备份,就可以解决这个问题。通过调查研究我们发现目有两种方法可以实现:

1)传统NAS的快照方式。对于传统的NAS存储来讲,快照是非常普遍的功能,通过NAS本身的快照复制,我们可以不用扫描文件系统没目录,仅仅基于某一个时刻点的快照,进行卷级别的复制实现全量备份;通过块儿级别的对比实现增量备份,因为NAS设备底层还是基于块儿设备实现的。当然这种技术需要对存储本身的快照功能有非常强的依赖性。

2)分布式NAS存储的日志记录方式。某些基于分布式技术实现的NAS存储可以对外提供日志操作的接口,也就是说对文件数据的增加和更新会记录到存储本身的底层日志当中,那么我们仅仅需要调用日志比对的接口就可以快速找到更新的目录和文件,仅仅需要扫描更新的部分做增量的复制来完成备份。

以上的两种技术方案需要我们在做备份规划之前的选型阶段对不同的备份软件及存储介质等进行深度调研和分析,尽可能科学合理组合实现以上解决方案。

4.如何解决平衡数据库归档频度和数据恢复完整性

4.1 数据库恢复的基本原理

对于数据库的恢复来说有很多种,我们只讨论需要介质恢复的情况。在这种场合下,首先我们需要找到一个最近时刻点的全量备份进行恢复;然后需要从备份介质上找到这个时刻点之后的重做日志进行数据追平,最后我们需要找到本地没有丢失的重做日志进行再次追平直到没有可用日志。如下图所示:

itunes有备份无法恢复备份_备份集中的数据库与现有的数据库不同_钛备份+备份应用数据

如图所示,在时刻A,我们开始做在线全库备份,在B时刻全库备份结束。当数据库运行到E时刻之后数据库发生了重大介质故障,只能通过介质恢复。那么在A~C时间段内,大部分REDO日志文件都已经归档到备份介质池当中,服务器本地存储目录当中只剩下C~E(小于一个归档备份时间间隔)的归档日志和没有来得及归档的REDO日志文件。假设发生的故障严重到服务器本地存储目录也无法恢复的时候,那么相当于在C-E这段时间产生的重做日志就丢失掉了。相当在这种极端场合下,数据丢失的最大窗口就是一个归档间隔时间段。当然如果把这个间隔设置的足够小的话,那么另外的问题就产生了,备份作业随着系统增加会呈爆发式并发启动状态,最终会影响到整个备份系统的健康运行导致归档无法及时转储,最终还是可能会导致数据库的宕机。这就是一个矛盾,需要我们去很好的平衡。

4.2 平衡数据库归档频率的方法

数据库归档备份的频率是指一天24小时内间隔多长时间进行一次归档日志的备份,一方面是要保障增量数据备份的完整性,另外一方面是要避免因为恢复空间不足导致数据库的宕机时间。要平衡这个频率窗口需要采集以下几类数据:

1)单位时间内不同数据库系统平均的归档日志量。

采集这个数据的目的在于详细分析不同业务系统在不同时间段的写操作频繁程度。对于日志归档速度较快的系统,我们需要提高其恢复区的空间大小,同时加快归档备份的频率,使得数据库既能处于安全运行状态又能保障极端故障场合下数据丢失的量在较小范围之内。

2)业务系统类型。

所谓业务系统类型即OLTP或者是OLAP,因为对于OLAP来讲,每次的读写操作都会是批量的执行,它的归档速度是正常OLAP系统的几十倍甚至上百倍。最麻烦的是两者皆有的业务系统,比如说银行业中的交易系统备份集中的数据库与现有的数据库不同,白天跑联机交易,晚上跑核算批量,白天和晚上的日志归档速度有着巨大的反差。那么我们就需要在批量作业时间段内将备份频率调快,将恢复区空间设置提高。

3)备份系统可以容忍的最大并发量。

备份系统可以容忍的最大并发Jobs,不仅仅取决于备份软件系统可以并发调度的作业数目和备份作业服务器的数目,还要取决于备份介质池可以容忍的资源消耗限制。及时我们可以同时调度几百个作业,但是当几十个作业同时写入备份介质池时就会把备份介质池的计算资源或者是IO资源使用殆尽。那么最终整个备份系统的并发数取决于短板因素。

4)不同数据库系统恢复区能够支撑最小时间窗口。

这个最小时间窗口是我们用数据库的恢复区可用空间大小/单位时间内的最大归档速度来估算出来的时间窗口。因为我们在安装数据库或者是做变更的时候不可能按照每一个系统的特点详细计算出其日志存储空间的大小,只能按照有限的几个规格来做初始规划。

有了以上数据之后备份集中的数据库与现有的数据库不同,我们需要根据以下几个原则来详细设计我们的归档作业频率。

首先,根据4当中采集到的数据,将时间窗口较小的几个系统进行存储空间调整,使其日志存储空间能够满足我们期望的最小时间标准。

然后,将一天24小时定义为几个时间段,批量业务集中的时间段、联机业务集中的时间段、特殊任务集中的时间段等。当然这个定义主要是根据1&2中采集到的详细数据来定义的。

接着,我们需要根据1中数据估算出一个归档作业大概持续的时间长度。为保障每一个时刻点的并发执行备份作业数目远小于3中估算出来的数据。

最后,需要把备份作业的频度根据不同的时间段特点调整到以上条件都满足的状态,并在此前提条件下可以为了保障极端情况下的数据完整性而适当调快归档作业的备份频率。下图是一个根据以上采集数据进行多维分析的实例,仅仅是一个方法示意,归档频率根据数据重要性分级、归档速度、业务时间段分类等前提进行的粗略分析,最下面的一行数字表示每一个时刻点并发的归档备份数目,其目标在于平衡每一个时间间隔内的平均备份作业数。实际情况会比以下情况复杂很多,我们可以将时间间隔划分的更小,涉及的因素更多,分析的更加细致。

5.如何评估数据库全量备份的策略

数据库的全量备份来讲,随着数据量的不断增加,其备份作业耗费的时间也就会越长,耗费的数据库资源也越多,对在线业务的影响也就越大。另外同一个时间段内发起的全量备份越多,那么其占用的备份系统整体资源(备份服务器、备份介质池、链路带宽等)也就会越多,其影响范围也会越广。

首先,这个问题是一个需要不断优化的问题。对于每一个应用系统来讲,根据业务服务的特点,其备份的时间窗口也是不同的。可能初期备份作业能够在备份窗口内完成,但是随着数据量的增长,后期的备份作业就会超过备份时间窗口。所以我们需要定期监控数据库的全量备份作业时间,在事件窗口范围内尽量通过调整合适的调度时间来完成全量备份。但是当数据量增长到完全没办法在备份窗口完成的时候,那么我们就需要进行调整全量备份的频度和具体调度时间点了。

其次,这个问题是一个跟业务特点密切相关的的问题。有些人喜欢把所有的业务系统都按照一个标准去定义其数据库全量备份的策略。比如说TB以下的数据库,每天一次全量备份;比如说业务等级属于重要的系统,每天一次全量备份;比如说只要能备份的系统,全部进行每天一次的全量备份等等策略。这些都是不科学的策略。应该从业务系统的数据重要性去评估数据库全量备分的频率,在现有备份系统有限的处理能力内保障数据重要性高的系统完成相应的全量备份。

最后,这个问题是一个需要从各个方面着手去解决的问题。从备份网络的带宽和隔离性考虑,应该用单独的告诉备份网络,备份客户端应该设置区分于业务的单独网络通道及配置。从备份作业服务器的配置层面,我们应该配置相对合理的资源(内存、磁盘)来保障备份片在作业服务器层没有瓶颈。从备份介质池层面,我们需要保障备份介质的IO处理能力不能成为备份作业底端的性能瓶颈。

6.如何解决备份作业分布合理性问题

其实这个问题很简单,目的就是要保障备份时间窗口内调度起来以及运行过程中的备份作业处于一种平衡状态,不能使其作业调用或者是并发运行过于集中。但是当系统数目非常多,系统特点复杂,数据重要性级别有很多种,数据量以及数据增速各不相同时,这个问题就变得比较复杂。我们很难有一种精确的计算方法来实现其做到绝对,但是我们可以根据以下的方法进行定性的分析和调整。

假设我们定义一个系统的备份作业在备份体系当中必须具备的属性为:

P1 – 应用系统数据的重要性级别属性,可以通过业务分析划分为有限的几个级别。

P2 – 应用系统在不同时间段内的数据增量属性,需要通过梳理历史数据来评估。

P3 – 应用系统当前的备份作业的时间长度属性,需要通过历史数据结合数据量来评估。

P4 – 应用系统是否是具备双重业务特性,比如兼备批量和联机业务特性。

通过以上几个属性的加权计算或者其他方法的定性分析,计算出每一个系统的不同备份作业的定性矢量,然后我们可以将这些矢量根据其具体备份窗口设置初始的调度时间点,然后分析其具体分布图是否均衡稳定并且进行微调。例如下图是一个粗略的分析实例,可以提供相关的参考思路:

以上案例仅仅是一个相对粗略的分析方式,仅仅是一个基于某一特定案例的分析思路。我们可以根据业务系统特点结合更好的专业工具进行更加细节的分析。但是总体目标是让我们的备份作业分布达到一定范围内的平衡,另外在某些特定的业务场合或者特定的设备场合下,可能会有一些特殊的时间窗口需要和备份作业适当分割开来,比如说基于文件系统技术实现的备份介质存储池,由于我们的周期性归档配置,它会定期去做文件系统的清理作业,而且时间段比较长,耗费资源比较高。我们尽量要讲备份作业的分布策略与这些时间段保持适当的分割。这样才会保证备份系统运行的长久安全稳定。

7.如何解决业务发展与备份系统有限性瓶颈

所谓的业务发展在备份体系建设过程中包括几个方面的影响。一方面业务量的增长会导致备份作业的不断增加,另外一方面业务量的增长会导致现有备份作业负载的不断加剧,再有就是各种新业务的增加会带来新型模式数据备份的挑战。这几方面的因素不但会对现有备份系统的负载扩展能力提出巨大挑战,也会对现有备份系统功能扩展能力提出巨大挑战。

解决以上问题,本文认为唯一可行的方法就是从单一传统的备份系统逐渐过渡到完善的备份体系。传统的备份软件形成的格局只是这个体系的一个元素,基于快照的备份接口、基于软件加速的接口、基于异构平台转储的模块儿都应该成为这个体系当中的扩展元素;同时备份介质也应该从单一的带库、DD等传统备份介质扩展到由现有备份介质池和分布式存储池、对象存储池、云端备份池等多种元素组成的广义备份介质池;单一的备份恢复模式也应该转换为多级数据一体化模式,既包括多级数据的转储归档机制,又包括数据自动化下沉和上浮的机制,数据流向实现自动化平滑轨迹。

目前可以实现以上体系的软硬件产品组合有很多,各家都有各家的特点和局限。关键是要靠规划者根据自己的业务特点和长远的发展预测来选择和集成合适的解决方案。

8.总结和展望

本文基于企业备份系统建设过程遇到的一些问题进行深入调查和剖析,并切合企业具体问题案例从特定问题角度出发给出分析思路。随着目前的分布式技术、云计算技术、互联网技术等的不断发展,备份体系建设的内容会呈现越来越多的新模式和新思路。解决的方法也不局限于企业的数据中心内部,一些结合云计算的整体解决方案也在不断诞生,它会涉及到数据的整个生命周期,当然这个根据不同的行业也会呈现不同的思路和模式。本文将次作为一个基础性的思考,更重要的是希望能引起更多从业者从不同角度的思考和提炼,并分享出来供大家参考。

作者:赵海,在某城商银行系统规划设计中心任系统架构师,专注于银行数据中心解决方案规划及设计工作。是twt社区“虚拟化”、“数据复制技术”等多个领域的专家。

限时特惠:本站每日持续更新海量设计资源,一年会员只需29.9元,全站资源免费下载
站长微信:ziyuanshu688

svn库备份_钛备份怎么备份多个数据_备份集中的数据库与现有的数据库不同

近年来,随着高校师生敏感数据泄露、篡改等多种安全事件的不断发生,各高校越来越重视数据库的安全防护和加固。

本文结合浙江大学数据库现状,对现有的安全策略和正在推进的强化措施进行介绍。

浙江大学数据库现状

浙江大学现阶段使用的是一种集中专用的数据库硬件架构,即“服务器+数据库+存储设备”的数据处理架构。

针对浙江大学真实的数据库应用环境,以及每年递增的数据库使用需求,目前浙江大学信息技术中心已先后在三个机房部署多套数据库集群,这些集群分别部署在虚拟机和物理PC服务器上。

以前的数据库运行在不同物理服务器的不同平台上备份集中的数据库与现有的数据库不同,设备普遍比较老旧。此外各套数据库之间版本不统一且普遍版本过旧,漏洞多,性能低下,维护成本较高。

同时,随着硬件技术的改进,尤其是CPU数量的增加,服务器能够处理更多的工作负载,而数据库只使用了服务器硬件容量的一部分,导致硬件资源无法得到充分利用,造成一定的资源浪费。上述种种原因造成了在现有的数据库环境下,直接添加安全防护措施的难度和成本将大大增加。

因此,浙江大学信息技术中心目前正在全面推进数据库的整合升级工作。基于浙江大学现有的硬件环境,依然采取传统的数据库集群架构,通过软件层面升级,实现数据库软件及硬件的整合统一,调整后的架构如图1。

钛备份怎么备份多个数据_svn库备份_备份集中的数据库与现有的数据库不同

数据库整合统一后,信息技术中心维护的所有数据库将共用同一套服务器、数据库系统和存储设备,在安全方面最直接的好处是所有的安全防护设备可以统一部署,为后续安全工作的开展打好基础。

数据库安全策略配置

访问控制和权限控制

1、基本参数设置

要对一些基本参数进行设置,如:用户密码必须为复杂密码;设置密码失效时间和密码过期提示;密码使用一段时间后强制要求重置密码;限制登录失败重试次数;设置账号锁定时长等等。

2、用户权限控制

要对用户的权限进行严格控制。申请用户权限需提交书面申请,同时数据库维护人员要对用户申请的权限进行审核。仅授予用户所需的权限,限制用户操纵数据库的权利;仅允许用户对其名下的数据库实体进行存取执行,阻止用户访问非授权数据。

3、视图机制

要采用视图机制,限制用户存取基表的行和列集合。

数据库备份

1、数据库启用自动归档

归档日志是非活动的重做日志备份。通过使用归档日志,可以保留所有重做历史记录,可用于用户数据文件的恢复。

2、数据库启用自动物理备份

物理备份是对数据库的物理文件(数据文件、控制文件、参数文件、归档日志文件)进行转储,一旦数据库发生故障备份集中的数据库与现有的数据库不同,可以利用这些文件恢复到数据库的失效点。

物理备份分为热备份和冷备份。由于冷备份需要数据库暂时处于关闭状态,因此浙江大学的数据库采用热备份的方式。

3、数据库启用自动逻辑备份

逻辑备份是对数据库对象(用户、表、存储过程等)进行转储。

4、数据库启用控制文件自动备份

控制文件是一类物理文件,它的重要性在于它记录了数据库名字、数据文件位置等信息,一旦控制文件被损坏,数据库将会宕机。因此,需要在不同的物理路径下备份控制文件。

5、数据库启用归档日志自动删除

数据库已开启了自动物理和逻辑备份,因此归档日志存在大量冗余,为提高空间的可用性和利用率,需对已备份的归档日志进行自动删除,充分利用存储空间。

数据库审计

数据库审计可以记录对数据库对象的所有操作。无论哪种数据库系统,均会提供不同的审计方法来监控使用何种权限,以及访问哪些对象。审计不会防止使用这些权限,但可以提供有用的信息,用于揭示权限的滥用和误用。

审计一般可以分为三类:语句审计、权限审计和对象审计。但过度的审计可能会对数据库性能产生负面影响,因此应该先对关键的权限和对象进行基础审计,然后根据需要再扩展审计。

浙江大学现有的数据库审计采用对更新、删除等权限以及重点单位名下对象进行基础审计的模式,扩展审计根据重要级别按需增加。整合后的数据库系统上将继续采用原有的审计模式。

考虑到新数据库性能更优,将适当调整审计范围和程度,保证在基本不影响性能的情况下,实现最大程度的审计力度。后续还将考虑添加数据库外部审计,如基于网络侦听的外部审计设备等。

其他安全防护措施

1、数据库灾备

数据库灾备包括数据库容灾和数据库备份。容灾在数据库遭遇人为或自然灾害时保证业务的正常运行;备份保证灾难来临时不会造成数据的丢失。数据库灾备为数据库实现高可用性提供重要保障。

目前浙江大学一些核心系统已实现灾备。在数据库整合统一后,将搭建统一的灾备系统,为主生产系统提供保障,一旦主生产系统因人为攻击或自然灾害而无法继续提供数据服务时,灾备系统可以立刻接管业务,并在主数据库恢复后将业务回切,以保证业务的不中断,同时硬件资源也能达到最大化的利用。

2、堡垒机

堡垒机是一个统称,不同的生产厂商对其有不同的命名。它运用各种技术手段实时收集和监控网络环境中每一个组成部分的系统状态、安全事件和网络活动,并对收集到的信息进行集中报警、记录、分析和处理,从而保障系统不受来自外部和内部用户的入侵和破坏。

以往,一旦发现疑似数据库安全事件,往往需要数据库维护人员根据已有的线索,翻阅日志,分析原因并采取措施。而考虑到数据库性能,数据库审计往往不会过于精细,导致可参考的审计内容有限,增加了分析处理的难度。

此外,以往对数据库访问的控制往往通过用户账户密码和IP地址过滤来实现,局限性大,且无法审计用户连接数据库后的操作,存在很大的安全隐患。

堡垒机通常具备跨平台管理、多维度访问控制与授权、运维行为审计、审计信息管理等功能。将堡垒机采用“物理旁路、逻辑串联”的方式部署在数据库系统上后,所有的用户必须通过堡垒机才能访问数据库,用户的所有操作行为都将被记录存储下来,从而实现对用户的操作审计。

对高校而言,堡垒机通过集中的账号管理、运维操作访问控制和全程运维操作审计,能帮助高校信息部门转变传统的安全运维被动响应模式,建立面向用户的集中、主动的运维安全管控模式,降低人为安全风险,保障高校运维的安全稳定运行。

浙江大学在确保服务器及网络环境安全的前提下,合理配置数据库安全策略,结合数据库审计、数据库灾备和即将配置的堡垒机,将全面保障学校数据库系统的安全稳定运行。

技术在不断革新,数据库技术日新月异,随之而来的安全隐患也源源不断。除了不断更新数据库安全防护策略和措施外,也应加强对数据库用户、管理员的安全意识和安全操作培训,从多方面保障数据库的安全。

限时特惠:本站每日持续更新海量设计资源,一年会员只需29.9元,全站资源免费下载
站长微信:ziyuanshu688