9系统和数据备份说明

xxx管理系统（项目编号XM001）系统和数据备份说明第第页目录TOC\o"1-3"\h\u28647第一章源码管理方案 230891.1.源码管理工具介绍 2272011.1.1.源码管理工具发展历程 258461.1.2.源码管理工具发对比与选择 4240871.2.源码管理工具的使用 11312411.2.1.安装部署 1117981.2.2.CI/CD实现 13234971.3.源码管理工具备份机制 1420415第二章数据管理方案 14114682.1.数据管理意义 14316862.1.1.数据管理定义 14270432.1.2.数据管理目的 15102662.2.数据管理工具选择 17192592.2.1.数据存储系统软件对比 1787582.2.2.数据存储方案选择 2421432.3.数据备份机制 24204912.3.1.备份目的 2462082.3.2.备份实现方式 2530951第三章安全管理方案 3098103.1.平台安全考虑 30323503.2.安全保障措施 31107533.3.基础安全保障 32198903.4.备份安全保障 33268833.5.部署安全保障 41218413.6.运行安全保障 4185373.7.数据存储安全 44264583.8.平台应用安全 45

源码管理方案源码管理工具介绍本项目采用Git+Gitlab实现源码的管理，Git实现源码的版本控制以及代码上传下载实现，Gitlab进行代码管理的web服务，并实现CI/CD代码自动化部署，使用Git作为代码管理工具。源码管理工具发展历程版本控制工具介绍版本控制是一种记录一个或若干个文件内容变化，以便将来查阅特定版本修订情况的系统。版本控制发展本地版本控制系统许多人习惯用复制整个项目目录的方式保存不同的版本，为了区别和方便查重会加上备份的时间。这样虽然容易简单，但是容易犯错。有时候会混淆所在的工作目录，不小心就会写错文件或者覆盖意外的文件。为了解决上述的问题，人们就开发了本地版本控制系统，大多数都是采用简单的数据库来记录文件的历史更新差异。其中最流行的是RCS。集中式版本控制系统本地版本控制系统不能解决不同系统上的开发者协同工作。于是集中式版本系统就诞生。这一类系统例如CVS/Subversion以及Perforce等，都有一个单一的集中管理服务器，保存所有的修订版本。协同工作的人们通过客户端连接这台集中管理服务器，拉去最新的文件或者提交更新。在很长的一段时间着都是版本控制系统的标准做法。集中式版本控制系统对于本地版本控制系统来说带来了很多好处。协同的每个人都可以看到项目中其他人的工作和提交。管理员也可以把控每一个开发的权限，所有人公用一个版本管理服务器。节约了在本地的资源浪费和无法共享的问题。当然集中式版本管理系统也有坏的方面。中央服务器会出现单点故障，如果故障一小时，那么在这个小时内，谁都无法提交和更新，也无法协同工作。如果中心服务器磁盘损坏并且没有备份，那么将丢失所有的数据，包括项目的整个变更历史。分布式版本控制系统基于本地、集中式版本管理系统的缺陷，分布式版本控制系统面世了。在这一类系统中，像git、mercurial、bazaari以及darcs等。客户端并不只保存最新版本的文件快照，而是把代码仓库的完整镜像下来。这样一来，任何一处协同工作用的服务器故障，事后都可以使用任意一个镜像出来的本地仓库恢复。源码管理工具发对比与选择主流的版本控制产品对比*版本库模型（Repositorymodel）:描述了多个源码版本库副本间的关系，有客户端/服务器和分布式两种模式。在客户端/服务器模式下，每一用户通过客户端访问位于服务器的主版本库，每一客户机只需保存它所关注的文件副本，对当前工作副本（workingcopy）的更改只有在提交到服务器之后，其它用户才能看到对应文件的修改。而在分布式模式下，这些源码版本库副本间是对等的实体，用户的机器出了保存他们的工作副本外，还拥有本地版本库的历史信息。*并发模式（Concurrencymodel）:描述了当同时对同一工作副本/文件进行更改或编辑时，如何管理这种冲突以避免产生无意义的数据，有排它锁和合并模式。在排它锁模式下，只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下，用户可以随意编辑或更改文件，但可能随时会被通知存在冲突（两个或多个用户同时编辑同一文件），于是版本控制工具或用户需要合并更改以解决这种冲突。因此，几乎所有的分布式版本控制软件采用合并方式解决并发冲突。*历史模式（Historymodel）：描述了如何在版本库中存贮文件的更改信息，有快照和改变集两种模式。在快照模式下，版本库会分别存储更改发生前后的工作副本；而在改变集模式下，版本库除了保存更改发生前的工作副本外，只保存更改发生后的改变信息。*变更范围（Scopeofchange）：描述了版本编号是针对单个文件还是整个目录树。*网络协议（Networkprotocols）：描述了多个版本库间进行同步时采用的网络协议。*原子提交性（Atomiccommit）：描述了在提交更改时，能否保证所有更改要么全部提交或合并，要么不会发生任何改变。简而言之，各有优缺点，git要配合hub，可以避免分布式损坏。svn有权限控制，避免全被clone走。git适合纯代码，svn适合综合性文档管理，结合起来就完美。显然最大的不同在于git是分布式的。SVNSVN原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。SVN特点概括每个版本库有唯一的URL（官方地址），每个用户都从这个地址获取代码和数据；获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据；提交必须有网络连接（非本地版本库）；提交需要授权，如果没有写权限，提交会失败；提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”…诸如此类；冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。SVN优缺点优点：管理方便，逻辑明确，符合一般人思维习惯。

易于管理，集中式服务器更能保证安全性。

代码一致性非常高。

适合开发人数不多的项目开发。缺点：服务器压力太大，数据库容量暴增。

如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。

不适合开源开发（开发人数非常非常多，但是Googleappengine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。GitGit记录版本历史只关心文件数据的整体是否发生变化。Git不保存文件内容前后变化的差异数据。实际上，Git更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一连接。在分布式版本控制系统中，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程。另外，因为Git在本地磁盘上就保存着所有有关当前项目的历史更新，并且Git中的绝大多数操作都只需要访问本地文件和资源，不用连网，所以处理起来速度飞快。用SVN的话，没有网络或者断开VPN你就无法做任何事情。但用Git的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程的镜像仓库。换作其他版本控制系统，这么做几乎不可能，抑或是非常麻烦。Git起源Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。Linus虽然创建了Linux的核心，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。Git结构组成工作区：用来保存项目的元数据和对象数据库的地方。这是Git中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。暂存区：保存了下次将提交的文件列表信息，一般在Git仓库目录中。有时候也被称作“索引”，不过一般说法还是叫暂存区域。版本库：也叫本地版本库，之所以说Git快，大部分提交都是对本地仓库而言的，不依赖网络，最后一次会推送的到远程仓库。远程仓库：可以看做是github，它是一个远程仓库，它提供web服务的供大家方便下载、查看、提交、存储。文件的状态Git文件管理状态

新建文件状态为untracked，add命令执行后状态变为staged，已存在的文件状态为unmodified，修改文件内容，文件状态变为modified，commit提交，文件状态编程unmodifed。Git特点概括Git中每个克隆(clone)的版本库都是平等的。你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。Git的每一次提取操作，实际上都是一次对代码仓库的完整备份。提交完全在本地完成，无须别人给你授权，你的版本库你作主，并且提交总是会成功。甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支。Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库，合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成。冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决。Git也可以模拟集中式的工作模式Git版本库统一放在服务器中可以为Git版本库进行授权：谁能创建版本库，谁能向版本库PUSH，谁能够读取（克隆）版本库团队的成员先将服务器的版本库克隆到本地；并经常的从服务器的版本库拉（PULL）最新的更新团队的成员将自己的改动推（PUSH）到服务器的版本库中，当其他人和版本库同步（PULL）时，会自动获取改变Git的集中式工作模式非常灵活你完全可以在脱离Git服务器所在网络的情况下，如移动办公／出差时，照常使用代码库你只需要在能够接入Git服务器所在网络时，PULL和PUSH即可完成和服务器同步以及提交Git提供rebase命令，可以让你的改动看起来是基于最新的代码实现的改动Git有更多的工作模式可以选择，远非Subversion可比综上所述，不难发现，Git已经作为版本控制的主要工具，本项目也采用Git作为源码管理。源码管理工具的使用Git本身就是由于为了帮助开发linux开发内核而使用。Linux系统本身自带Git工具，而且Git操作命令基本遵从Linux语法，这里就不说了。主要描述下Gitlab工具的安装使用已经如何实现CI/CD自动化部署。安装部署docker安装及配置Gitlab部署是基于docker实现的，首先安装docker。获取官方源wget-P/etc/yum.repos.d//linux/centos/docker-ce.repo安装dockerceyuminstall-ydocker-ce启动、开机启动systemctlstartdockersystemctlenabledockerGitlab安装及配置Gitlab镜像拉取#gitlab-ce为稳定版本，后面不填写版本则默认pull最新latest版本$dockerpullgitlab/gitlab-ce运行Gitlab镜像$dockerrun-d-p443:443-p80:80-p222:22--namegitlab--restartalways-v/home/gitlab/config:/etc/gitlab-v/home/gitlab/logs:/var/log/gitlab-v/home/gitlab/data:/var/opt/gitlabgitlab/gitlab-ce#-d：后台运行#-p：将容器内部端口向外映射#--name：命名容器名称#-v：将容器内数据文件夹或者日志、配置等文件夹挂载到宿主机指定目录配置 按上面的方式，Gitlab容器运行没问题，但在Gitlab上创建项目的时候，生成项目的URL访问地址是按容器的hostname来生成的，也就是容器的id。作为gitlab服务器，我们需要一个固定的URL访问地址，于是需要配置gitlab.rb（宿主机路径：/home/gitlab/config/gitlab.rb#gitlab.rb文件内容默认全是注释$vim/home/gitlab/config/gitlab.rb#配置http协议所使用的访问地址,不加端口号默认为80external_url'31'#配置ssh协议所使用的访问地址和端口gitlab_rails['gitlab_ssh_host']='31'gitlab_rails['gitlab_shell_ssh_port']=222#此端口是run时22端口映射的222端口:wq#保存配置文件并退出#重启gitlab容器$dockerrestartgitlab此时项目的仓库地址就变了。如果ssh端口地址不是默认的22，就会加上ssh://协议头打开浏览器输入ip地址(因为我的gitlab端口为80，所以浏览器url不用输入端口号，如果端口号不是80，则打开为：ip:端口号).Gitlab安装部署基本完成，接下来就是CI/CD实现.CI/CD实现GitLabCI/CD是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：ContinuousIntegration(CI)

持续集成ContinuousDelivery(CD)

持续交付ContinuousDeployment(CD)

持续部署持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。这些方法使得可以在开发周期的早期发现bugs和errors，从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。GitLabCI/CD由一个名为.gitlab-ci.yml的文件进行配置，改文件位于仓库的根目录下。文件中指定的脚本由GitLabRunner执行。本项目CI/CD实现基于jenkins实现的，开发人员一旦向gitlab仓库提交成功代码，gitlab就会自动触发jenkins构建项目。当然在构建后还可以添加项目部署或者自动化测试的脚本。原理是Gitlab中有有一个钩子函数，这个钩子函数基于Git的一些操作去触发的，例如，Git中提交代码，Gitlab钩子函数触发，执行jenkins中脚本，实现自动部署的功能，具体步骤就不赘述了。源码管理工具备份机制备份GitlabGitlab备份方式很简单，基于Gitlab本身的命令实现的。通过gitlab-rake命令备份gitlab。gitlab-rakegitlab:backup:create定时备份Gitlab如果要使Gitlab自动进行备份的话，我们可以通过crontab命令来实现自动备份。以实现每天凌晨4点进行一次自动备份为例，系统的crontab配置如下:vim/etc/crontab04***root/opt/gitlab/bin/gitlab-rakegitlab:backup:createCRON=1然后重启crontab服务，如下：systemctlrestartcrond数据管理方案数据管理意义数据管理定义数据管理是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程。其目的在于充分有效地发挥数据的作用。实现数据有效管理的关键是数据组织。随着计算机技术的发展，数据管理经历了人工管理、文件系统、数据库系统三个发展阶段。在数据库系统中所建立的数据结构，更充分地描述了数据间的内在联系，便于数据修改、更新与扩充，同时保证了数据的独立性、可靠、安全性与完整性，减少了数据冗余，故提高了数据共享程度及数据管理效率。数据管理目的管理阶段人工管理阶段20世纪50年代中期以前，计算机主要用于科学计算，这一阶段数据管理的主要特征是:不能长期保存数据。在20世纪50年代中期之前，计算机一般在关于信息的研究机构里才能拥有，当时由于存储设备(纸带、磁带)的容量空间有限，都是在做实验的时候暂存实验数据，做完实验就把数据结果打在纸带上或者磁带上带走，所以一般不需要将数据长期保存。数据并不是由专门的应用软件来管理，而是由使用数据的应用程序自己来管理。作为程序员，在编写软件时既要设计程序逻辑结构，又要设计物理结构以及数据的存取方式。数据不能共享。在人工管理阶段，可以说数据是面向应用程序的，由于每一个应用程序都是独立的，一组数据只能对应一个程序，即使要使用的数据已经在其他程序中存在，但是程序间的数据是不能共享的，因此程序与程序之间有大量的数据冗余。数据不具有独立性。应用程序中只要发生改变，数据的逻辑结构或物理结构就相应的发生变化，因而程序员要修改程序就必须都要做出相应的修改，给程序员的工作带来了很多负担。文件系统阶段20世纪50年代后期到60年代中期，计算机开始应用于数据管理方面。此时，计算机的存储设备也不再是磁带和卡片了，硬件方面已经有了磁盘、磁鼓等可以直接存取的存储设备了。软件方面，操作系统中已经有了专门的数据管理软件，一般称为文件系统，文件系统一般由三部分组成:与文件管理有关的软件、被管理的文件以及实施文件管理所需的数据结构。文件系统阶段存储数据就是以文件的形式来存储，由操作系统统一管理。文件系统阶段也是数据库发展的初级阶段，使用文件系统存储、管理数据具有以下4个特点:数据可以长期保存。有了大容量的磁盘作为存储设备，计算机开始被用来处理大量的数据并存储数据。有简单的数据管理功能。文件的逻辑结构和物理结构脱钩，程序和数据分离，是数据和程序有了一定的独立性，减少了程序员的工作量。数据共享能力差。由于每一个文件都是独立的，当需要用到相同的数据时，必须建立各自的文件，数据还是无法共享，也会造成大量的数据冗余。数据不具有独立性。在此阶段数据仍然不具有独立性，当数据的结构发生变化时，也必须修改应用程序，修改文件的结构定义;而应用程序的改变也将改变数据的结构。数据库系统阶段20世纪60年代后期以来，计算机管理的对象规模越来越大，应用范围又越来越广泛，数据量急剧增长，同时多种应用、多种语言互相覆盖地共享数据集合的要求越来越强烈，数据库技术便应运而生，出现了统一管理数据的专门软件系统--数据库管理系统。用数据库系统来管理数据比文件系统具有明显的优点，从文件系统到数据库系统，标志着数据库管理技术的飞跃。目前数据管理目的就是面向应用，使数据为大众服务。前面讲到数据管理经历了人工管理、文件管理、数据库管理等三个阶段，主要是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程。随着信息技术的进步，管理信息系统将面向大规模的组织提供业务支持，不仅要覆盖整个组织的各类业务，而且要覆盖整个组织(全球或者全国)。为此，作为管理信息系统的核心功能，数据管理将要进入一个新的阶段，即面向数据应用的数据管理。数据管理工具选择数据管理目的是服务应用，需要更好服务应用，就需要选择一个数据管理软件去存储、管理、使用。目前主流的数据管理软降包括oracle、mysql、db2、SQLservice等，本项目采用mysql+redis+mondgodb的数据管理方案。数据存储系统软件对比这里主要对比下mysql、oracle、redis优缺点及使用场景Oracle优点：开放性：oracle

能所有主流平台上运行（包括windows）完全支持所有工业标准采用完全开放策略使客户选择适合解决方案对开发商全力支持；可伸缩性,并行性：Oracle并行服务器通过使组结点共享同簇工作来扩展windownt能力提供高用性和高伸缩性簇解决方案windowsNT能满足需要用户把数据库移UNIXOracle并行服务器对各种UNIX平台集群机制都有着相当高集成度；安全性：获得最高认证级别的ISO标准认证。

性能：Oracle性能高保持开放平台下TPC-D和TPC-C世界记录；客户端支持及应用模式：Oracle多层次网络计算支持多种工业标准用ODBC、JDBC、OCI等网络客户连接

使用风险：Oracle长时间开发经验完全向下兼容得广泛应用地风险低

缺点：对硬件的要求很高；价格比较昂贵；管理维护麻烦一些；操作比较复杂，需要技术含量较高；MySQL优点：体积小、速度快、总体拥有成本低，开源；支持多种操作系统；是开源数据库，提供的接口支持多种语言连接操作mysql的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的MySql能很容易充分利用CPU；MySql有一个非常灵活而且安全的权限和口令系统。当客户与MySql服务器连接时，他们之间所有的口令传送被加密，而且MySql支持主机认证；支持ODBCforWindows，支持所有的ODBC2.5函数和其他许多函数，可以用Access连接MySql服务器，使得应用被扩展；支持大型的数据库，可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改。拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；

MySQL同时提供高度多样性，能够提供很多不同的使用者介面，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言介面，例如C+，Perl，Java，PHP，以及Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上；缺点：不支持热备份；MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变；没有一种存储过程(StoredProcedure)语言，这是对习惯于企业级数据库的程序员的最大限制；MySQL的价格随平台和安装方式变化。Linux的MySQL如果由用户自己或系统管理员而不是第三方安装则是免费的，第三方案则必须付许可费。Unix或linux

自行安装免费、Unix或Linux第三方安装收费；Redis优点：支持多种数据类型（同简介中有写的五种数据类型）redis支持set,zset,list,hash,string这五种数据类型，操作非常方便，如果在做好友系统，查看自己的好友关系，如果采用其他的key-value系统，则必须把对应的好友拼接成字符串，然后在提取好友时，再把value进行解析，而redis则相对简单，直接支持list的存储(采用双向链表或者压缩链表的存储方式)。持久化存储作为一个内存数据库，最担心的，就是万一机器死机宕机，数据就会消失掉。redis使用RDB和AOF做数据的持久化存储。主从数据同时，生成rdb文件，并利用缓冲区添加新的数据更新操作做对应的同步。性能很好由于是全内存操作，所以读写性能很好，可以达到10w/s的频率。公司有项目使用redis，目前的访问频率是80w/s，通过适当的部署，线上运行一切ok的。缺点：由于是内存数据库，所以单台机器存储的数据量跟机器本身的内存大小有关。虽然redis本身有key过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。定时删除和定期删除为主动删除，Redis会定期主动淘汰一批已过去的key。惰性删除为被动删除，用到的时候才会去检验key是不是已过期，过期就删除过期的key惰性删除是redis服务器内置策略（过期的key对aof文件没有任何影响，删除过期的key时系统会向aof文件追加一条del；如果key过期了但是没有删除，此时进行持久化操作这个key不会进入aof文件，因为没有发生修改指令）如果进行完整重同步，由于需要生成rdb文件，并进行传输，会占用主机的CPU，并会消耗现网的带宽。不过redis2.8版本以后，已经有部分重同步的功能，但是还是有可能有完整重同步的。比如，新上线的从库。修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中，redis不能提供服务。Mongodb优点：弱一致性（最终一致），更能保证用户的访问速度举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的较精确值。这在某些情况下，例如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“较精确”的保证几乎没有任何意义，反而会产生很大的延迟。他们需要的是一个“大约”的数字以及更快的处理速度。但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。

使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。

文档结构的存储方式，能够更便捷的获取数据。对于一个层级式的数据结构来说，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难。内置GridFS，支持大容量的存储

GridFS是一个出色的分布式文件系统，可以支持海量的数据存储。

内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。内置Sharding提供基于Range的AutoSharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。Shards可以和复制结合，配合Replicasets能够实现Sharding+fail-over，不同的Shard之间可以负载均衡。查询是对客户端是透明的。客户端执行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务，适当的时候可以无痛的升级。MongoDB的Sharding设计能力较大可支持约20petabytes，足以支撑一般应用。这可以保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。不少知名大公司和网站也在生产环境中使用MongoDB，越来越多的创新型企业转而使用MongoDB作为和Django，RoR来搭配的技术方案性能优越在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。缺点：mongodb不支持事务操作

所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)mongodb占用空间过大关于其原因，在官方的FAQ中，提到有如下几个方面：空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那样的指数递增，直到2G为单个文件的较大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是较大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。MongoDB适合存储一些关系简单、数据量又很大的数据，比如我们的平台上虚拟机的监控信息，包括内存、IO、CPU、网络等数据，每隔几秒就采集一次数据，每周、每月，量很大，而且旧的监控数据也不会保留太长时间，就使用的mongodb来存储这些数据；另外mongodb的集群部署相对比较简单，易于扩展；比如主从复制，在mongo.conf配置几个参数就OK了；分片集群的配置也比较简单。还支持使用命令行来进行动态地添加和删除节点；数据存储方案选择目前在本项目中，一般用户数据存储使用MySQL实现，一些热点数据、排序数据、不经常修改的数据使用Redis作为存储方案，而自定义表单数据则存储在MongoDB中。数据备份机制备份目的数据备份的作用与意义随着计算机的普及和信息技术的进步，特别是计算机网络的飞速发展，信息安全的重要性日趋明显，但是，作为为信息安全的一个重要内容――数据备份的重要性却往往被人们所忽视。只要发生数据传输、数据存储和数据交换，就有可能产生数据故障。这时，如果没有采取数据备份和数据恢复手段与措施，就会导致数据的丢失。有时造成的损失是无法弥补与估量的。数据故障的形式是多种多样的。通常，数据故障可划分为系统故障、事务故障和介质故障三大类。从信息安全的角度出，实际上第三方或敌方的“信息攻击”，也会产生不同种类的数据故障。例如：计算机病毒型、特洛伊木马型、“黑客”入侵型、逻辑炸弹型等。这些故障将会造成的后果有：数据丢失、数据被修改、增加无用数据及系统瘫痪等。作为系统管理员，漏是要千方百计地维护系统和数据的完整性与准确性。通常采取的措施有：安装防火墙，防止“黑客”入侵；安装防病毒软件，采取存取控制措施；选用高可靠性的软件产品；增强计算机网络的安全性。但是，世界上没有万无一失的信息安全措施。信息世界“攻击和反攻击”也永无止境。对信息的攻击和防护好似矛与盾的关系，螺旋式地向前发展。在信息的收集、处理、存储、传输和分发中经常会存在一些新的问题，其中最值得我们关注的就是系统失效、数据丢失或遭到破坏。威胁数据的安全，造成系统失效的主要原因有以下几个方面：硬盘驱动器损坏；人为错误；黑客攻击；病毒；自然灾害；电源浪涌；磁干扰；因此，数据备份与数据恢复是保护数据的最后手段，也是防止主动型信息攻击的最后一道防线。备份实现方式MySQL数据备份与恢复使用mysqldump命令备份mysqldump作为mysql自带的数据库备份命令，mysqldump命令将数据库中的数据备份成一个文本文件。表的结构和表中的数据将存储在生成的文本文件中。mysqldump命令的工作原理很简单。它先查出需要备份的表的结构，再在文本文件中生成一个CREATE语句。然后，将表中的所有记录转换成一条INSERT语句。然后通过这些语句，就能够创建表并插入数据。备份一个数据库mysqldump基本语法：mysqldump-uusername-pdbnametable1table2...->BackupName.sql其中：dbname参数表示数据库的名称；table1和table2参数表示需要备份的表的名称，为空则整个数据库备份；BackupName.sql参数表设计备份文件的名称，文件名前面可以加上一个绝对路径通常将数据库被分成一个后缀名为sql的文件；数据还原还原使用mysqldump命令备份的数据库的语法如下：mysql-uroot-p[dbname]<backup.sqlRedis数据备份Redis所有数据都是保存在内存中，Redis数据备份可以定期的通过异步方式保存到磁盘上，该方式称为半持久化模式，如果每一次数据变化都写入aof文件里面，则称为全持久化模式。同时还可以基于Redis主从复制实现Redis备份与恢复。半持久化RDB模式半持久化RDB模式也是Redis备份默认方式，是通过快照（snapshotting）完成的，当符合在Redis.conf配置文件中设置的条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上，完成数据备份。Redis进行RDB快照的条件由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。在配置文件中已经预置了3个条件：save9001#900秒内有至少1个键被更改则进行快照；save30010#300秒内有至少10个键被更改则进行快照；save6010000#60秒内有至少10000个键被更改则进行快照。默认可以存在多个条件，条件之间是“或”的关系，只要满足其中一个条件，就会进行快照。如果想要禁用自动快照，只需要将所有的save参数删除即可。Redis默认会将快照文件存储在Redis数据目录，默认文件名为：dump.rdb文件，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。也可以在Redis命令行执行config

get

dir获取Redis数据保存路径。Redis实现快照的过程，Redis使用fork函数复制一份当前进程（父进程）的副本（子进程），父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件，当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。执行fork的时操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时，操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据库备份。RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。除了自动快照，还可以手动发送SAVE和BGSAVE命令让Redis执行快照，两个命令的区别在于，前者是由主进程进行快照操作，会阻塞住其他请求，后者会通过fork子进程进行快照操作。Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，根据数据量大小与结构和服务器性能不同，通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需花费20～30秒钟。通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。此时需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。全持久化AOF模式

如果数据很重要无法承受任何损失，可以考虑使用AOF方式进行持久化，默认Redis没有开启AOF(appendonlyfile)方式的全持久化模式。在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些，开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改该名称。Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少，可以在redis.conf中通过appendonly参数开启RedisAOF全持久化模式。Redis主从复制备份通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据。但是由于数据是存储在一台服务器上的，如果这台服务器的硬盘出现故障，也会导致数据丢失。为了避免单点故障，我们希望将数据库复制多个副本以部署在不同的服务器上，即使只有一台服务器出现故障其他服务器依然可以继续提供服务，这就要求当一台服务器上的数据库更新后，可以自动将更新的数据同步到其他服务器上，Redis提供了复制（replication）功能可以自动实现同步的过程。通过配置文件在Redis从数据库中配置文件中加入slaveof

master-ip

master-port即可，主数据库无需配置。Redis主从复制优点及应用场景，WEB应用程序可以基于主从同步实现读写分离以提高服务器的负载能力。在常见的场景中，读的频率一般比较大，当单机Redis无法应付大量的读请求时，可以通过复制功能建立多个从数据库，主数据库只进行写操作，而从数据库负责读操作，还可以基于LVS+keepalived+Redis对Redis实现均和高可用。从数据库持久化持久化通常相对比较耗时，为了提高性能，可以通过复制功能建立一个（或若干个）从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化。

当从数据库崩溃时重启后主数据库会自动将数据同步过来，所以无需担心数据丢失。而当主数据库崩溃时，需要在从数据库中使用SLAVEOFNOONE命令将从数据库提升成主数据库继续服务，并在原来的主数据库启动后使用SLAVE

OF命令将其设置成新的主数据库的从数据库，即可将数据同步回来。MongoDB备份与恢复备份mongodump-hdbhost-ddbname-odbdirectory参数说明：-h：MongDB所在服务器地址，例如：，当然也可以指定端口号：:27017-d：需要备份的数据库实例，例如：test-o：备份的数据存放位置，例如：/home/mongodump/，当然该目录需要提前建立，这个目录里面存放该数据库实例的备份数据。-c:需要恢复的集合-f:需要导出的字段(省略为所有字段)-u：用户名-d：用户密码mongoexport-hdbhost-ddbname-ccollectionname-fcollectionKey-odbdirectory恢复

mongorestore-hdbhost-ddbname--dirdbdirectory参数或名：-h：MongoDB所在服务器地址-d：需要恢复的数据库实例，例如：test，当然这个名称也可以和备份时候的不一样，比如test2--dir：备份数据所在位置，例如：/home/mongodump/itcast/--drop：恢复的时候，先删除当前数据，然后恢复备份的数据。安全管理方案通过多种方式的安全保障机制来保证xxx管理系统链路、数据、应用、信息、终端等安全。针对平台的感知层、通信层、数据层、应用层上各自特有的安全隐患实施相应的解决方案，实现分级分层防控，保护xxx管理系统整体建设体系，保障平台整体建设安全。平台安全考虑系统安全主要包括两个部分：系统安全和信息安全。系统安全主要通过病毒防护、访问控制、入侵检测、系统的备份与恢复等措施保证工程中的各种系统以及系统上各种软件的正常运行；保证系统运行过程中的各种信息在存取、处理和传输中的机密性、完整性和可用性，并确保信息的可控性。同时，由于用户机构工作的特殊性，任何信息安全方面的疏忽，都将导致灾难性事故的发生，其造成的管理和经济影响是巨大的，带来的损失是不可估量的。因此，建设信息安全整体防护体系，制定恰当的安全策略，提高安全保障能力，是本次系统建设的重要环节。为了更好的、更有效的、更方便的保护和管理系统资源、网络资源，整体规划网络安全系统，并达到以下目标：安全性：确保信息系统中的各类数据不被非法访问、窃取、散发等，确保敏感数据处于可控制的范围之内，仅有经过严格身份认证的用户、系统才允许其获得相关数据。可用性：确保信息系统高效、稳定、可靠地运行；完整性：确保信息系统数据完整、可靠、不被篡改。抗抵赖性：确保信息系统用户认证可靠，相关操作记录具有唯一性，用户身份不被假冒等。可管理性：确保信息系统的各类系统资源都处于管理和控制之下。此外，在信息系统安全建设中，要充分考虑实用性和可扩展性，并尽量减少对性能的影响。应用平台的系统安全要达到以上目标，不是单靠某一、两个安全产品来解决的，它需要系统的、立体的全方位的解决方案，从网络的设计结构角度、从物理层面、网络层面、系统层面、应用层面、数据安全层面以及安生制度体系的建设方面等多视角来设计，应该按照应用为主导，根据不同应用的特点和安全需求，综合衡量不同业务系统的重要性和所面临风险大小等因素，科学划分网络与安全域，并在此基础上进行安全建设和管理，提高信息安全体系的有效性。安全保障措施1）建立健全的规章制度建立各项规章制度，如计算机防毒制度、数据备份制度等，据统计90%以上的管理和安全问题来自终端，提高机构业务人员的安全意识非常重要，组织协调有关人员，加强培训与安全教育，强化安全意识和法制观念,提升职业道德,掌握安全技术,确保这些措施落实到位，责任到人，收到很大的效果。2）保证服务器的安全服务器是网络的核心，是数据库管理的心脏，它负责业务数据的处理和存储，网络的安全首先要保证服务器的安全。系统的服务器最好采用双机热备方案，采用矩阵列柜，实现RAID5的磁盘安全级别，这样只做到了一块磁盘或一台服务器出现故障时，能保证信息系统的正常运行。3）确保局域网的安全由于机构的网络系统内的计算机数量比较多，各终端计算机如何管理，如何防止非法外联，如何限制移动存储的使用、如何控制网络流量等等，对这些终端的管理，实行定期检查，通过制定统一的安全策略，限制了移动电脑和移动存储设备随意接入内网，从而大大提高内网的安全性。通过完善的权限分配管理，超级管理员可以分配已有管理权限给新建给管理用户，可做到菜单级权限分配，不同的管理员拥有不同的管理权限，各个管理员之间权限互不干涉。通过完善的日志审计功能，管理员的用户操作、策略操作、用户登录等日志都有完整的记录，防止管理员越权使用软件平台。4）数据备份的保障措施xxx管理记录着各项服务流程、人员、部门等信息，极其重要，如果数据丢失，对机构的损失不可估量。所以说如何做好数据的备份，是保障信息系统安全的一项重要措施。建议制定相关的备份制度，每日做好备份日志，通过磁带、DVD等方式进行数据备份，并且做到异地存储。5）应用软件权限设置通过相关制度明确规定了每个操作人员的权限范围，通过授权、与MAC地址绑定等方法限制用户的行为，同时还通过内网安全管理软件的设备软件资源的管理模块对一些软件进行限制性安装，网管随机地通过软件搜索网内的共享资源、系统进程等各项信息，有效地阻止了一些操作人员的猎奇心，使其只能提取与其业务有关的的数据，提高了数据的保密性，提升了网络的安全性。基础安全保障根据系统安全需求，实现对病毒防护、访问控制、入侵检测、审计跟踪等功能，保证各种系统以及在系统上各种应用软件的正常运行，系统安全体系架构主要包括以下几个方面：访问控制提供各层次的访问控制功能。从用户认证和授权、数据库对象的访问控制、用户操作权限控制、系统操作的记录和稽核、数据和系统的完整性、可靠性和可用性、基于业务规则的访问控制等方面，保证系统的安全性。防火墙利用防火墙实现安全访问控制和安全隔离。对外部访问行为进行多级过滤、监控、记录，并进行安全审计。防火墙的实时监控记录表可实时显示网络上传送数据包的记录，包括规则号、时间、使用者、来源主机、目的主机、通讯协议、服务项目、传输资料量及连线时间。病毒防护软件局域网服务器和接入的PC机全部安装相应的网络版防病毒软件，并启动实时病毒监控，定时查杀病毒，确保系统处于监控状况；同时，实现全网防病毒系统的统一管理、统一升级，定时查杀，远程检测，确实有效的构建防病毒体系，彻底的消灭网络内的已知病毒；还应建立病毒应急响应流程，由于新病毒穷出不尽，仅仅依靠防病毒软件进行防护远远是不够的，还需要有专业的服务人员，定期检测，应急响应，将系统面对病毒的威胁和破坏的可能性减到最小。备份安全保障xxx管理系统平台在系统安全方面做到了两地三中心，两地是指xx区、xx区，三中心是指生产中心、同城容灾中心、云上备份中心。结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的“两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。备端在线两地三中心整体灾难恢复解决方案，可以满足不同灾难场景下的业务连续性要求。本地机房的容灾主要是用于防范生产服务器发生的故障，异地灾备中心用于防范大规模区域性灾难。本地机房的容灾由于其与生产中心处于同一个机房，可通过局域网进行连接，因此数据复制和应用切换比较容易实现，可实现生产与灾备服务器之间数据的实时复制和应用的快速切换。异地灾备中心由于其与生产中心不在同一机房，灾备端与生产端连接的网络线路带宽和质量存在一定的限制，应用系统的切换也需要一定的时间，因此异地灾备中心可以实现在业务限定的时间内进行恢复和可容忍丢失范围内的数据恢复。1、备端在线两地三中心灾备方案网络设计本地容灾是指在本地机房建立容灾系统，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，本地双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点；异地灾备中心是指在异地建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。针对两地三中心灾备建设的需求，结合自主研发的软件的优势，系统设计了典型的建设方案。本地机房安装镜像系统，主备端同时在线，真正实现“双活”，是可见，可验证，可靠的容灾；异地机房安装实时备份，既能实现数据的实时复制，确保数据不丢失，又能任意时间点手动恢复，实现容错，而且无需主备硬件配置一致，还能降低成本。网络拓扑和部署如下：两地三中心数据备份容灾架构图2、备端在线容灾系统设计在生产服务器上部署A镜像系统代理软件，在容灾服务器上安装A镜像系统服务器端软件，设置A镜像代理的检测路径为主存储路径，设置A镜像服务器路径为备用存储路径。通过Web管理界面配置镜像对象、全量和增量策略等。1）当生产服务器处于正常工作状态时，把生产服务器的代理软件连接至服务器。当代理检测到主存储数据变化后，将捕获变化的数据实时的复制到备用存储上，实现了实时的复制。具体部署如下图：2）当生产服务器故障，或者存储故障导致生产系统无法正常提供业务支持时，本地容灾服务器可直接接替生产服务器工作保障业务系统的持续运行；当本地机房发生灾难时，异地机房的容灾服务器可直接接替生产服务器工作保障业务系统的持续运行。具体部署如下图：3）当生产系统恢复工作后，继续其生产服务器的复制工作，并且在这之前会通过回切工具保障主备系统数据一致，具体部署如下图：4）异地容错的容灾系统设计如果本地机房发生故障，将异地容灾服务器中备份的数据进行手动恢复，可以直接恢复到原生产服务器（也可恢复到新服务器）。备份存储系统保存了应用系统任意时刻的数据，恢复时可恢复到任意时间点，实现容错，具体部署如下图：通过以上四点保证了备用存储上的数据和主存储上的数据完全一致。避免了主存储的单点故障。

管理端可部署在备用服务器上或系统管理员主机上。与一般的cluster不同，系统不采用共享存储模式，首先避免了硬件方面的巨量投资；其次避免了由于共享存储硬件或者连接共享存储硬件链路的故障引起的业务系统中断，避免了单点故障。xxx管理系统采用备端在线的两地三中心容灾优势如下：1)备端在线的容灾优势：●所见即所得的容灾，备用系统直接处于在线运行的状态，是直接可见、可验证的。不像其他容灾系统，一定要恢复后才能知道备用系统的好坏；●应用级的复制技术，即镜像系统复制的数据是数据库事务，是属于应用层的，从而可以保证数据库数据的完整性；●实施无需停顿业务系统，适合7X24小时连续运行的业务系统；●不需要主备系统硬件保证一致性，极大的降低系统改造及投入的硬件成本，只需备份存储空间大一点就行；●对网络带宽消耗非常小，不需专用的光纤传输网络，采用实时增量复制技术大大减少了资源的开销，对业务系统性能影响很小；●一旦主系统发生故障，由于备用系统的数据库直接处于运行状态，无需数据恢复阶段，仅需恢复业务系统即可，所以整个备用系统替换主系统的过程非常快；●采用实时增量复制技术，将数据复制到备用系统上，当主系统发生故障时，备用系统丢失数量极小，由于数据量小使得备份窗口趋于零，对主系统的性能影响很小；●应用方式多样化，支持多对一、一对多等镜像方式，为后期提供扩展平台；●基于WEB的统一管理平台，负责对服务器、数据库等进行配置，设置镜像策略，并监控复制链运行情况，方便管理。WEB监控界面可监控全网的备份任务及运行状态。每条监控记录就是一条完整的复制链路，包含镜像代理、镜像服务器、运行状态。Web可监控全网所有镜像代理、镜像服务器的工作状态以及所有复制任务。复制任务监控信息包括：

编号：根据任务复制的顺序来排序的。类型：模块类型，有文件，SQLSERVER和ORACLE三种。服务器：镜像服务器所在服务器IP。目标数据库：镜像服务器端备份数据库的名称。执行内容：具体复制的内容，数据库监控的是SQL语句，文件监控的是复制的文件名。开始时间：任务开始执行的时间。结束时间：任务执行结束的时间。状态：任务执行完成后的状态，如果复制成功显示为成功，失败显示的是失败。2)实时备份服务器备份系统的客户端模块实时捕获数据变化，并进行实时增量传输，不间断的保护客户端数据，保障生产服务器的业务数据不丢失。并且可以恢复到任意时间点和任意版本，无时无刻保护业务系统的数据安全。增量处理示意图如下：3)任意时间点还原实时备份，保留所有的变化的数据块，可以根据用户的需求，恢复到任意的时间点的版本。增量和差异版本的实时复制、传输技术，以及全量加增量合成存储技术实现了数据完整性和任意时间点还原的功能。4)裸机还原通常情况下，裸机要想进行信息处理需要进行硬盘分区和格式化、安装操作系统、安装驱动程序、安装应用程序等繁琐的步骤，需要花费大量的时间才能构造一个可用的系统环境。服务器备份系统可以轻松地将备份好的系统恢复至裸机上，实现一步到位。可以快速的恢复业务系统的运行环境，极大的降低业务系统的最大恢复时间（RTO）指标。达到高性能的容灾。5)容灾与容错相结合采用CDP技术，系统能根据数据库事务日志的变化分析出数据库完整性点，在复制此数据到备用服务器的同时还将保存历史记录，保证系统可以以I/O数据块为单位恢复至任意时间点，并且每个数据版本都满足数据库级的一致性，即每个版本等都是正确可用的，而不需要尝试回退I/O。从而真正防止因数据库误操作对企事业单位带来的损失。6)异机还原支持异机还原，避免单机故障导致的数据无法还原、使用的风险。即使在不同硬件上，也可以恢复出故障的系统。克隆与部署操作系统，不受硬件限制。在物理计算机之间以及物理计算机与虚拟机之间进行迁移。7)对系统影响小安装过程无需停机，采用定时全量和实时增量的技术，对网络和系统资源占用极低，不会影响生产系统的运行。所有的操作在用户端完成，用户通过访问一个WEB浏览器来设定备份计划和策略，备份系统将变化的数据从生产服务器捕获到，并传输到备份服务里，从而减少了对生产服务器的负担。全量加增量合成存储备份技术，保证系统只需做一次全量备份即可，大大减轻系统负担。8)基于WEB的作业、管理、监控平台支持Web-Manage平台，即所有的作业操作都可以在Web平台上完成。支持远程WEB进行备份策略设置、作业监控、存储配置、空间管理等，无需进行现场维护。通过设置备份计划与存储管理策略，让系统自动运行，极大地减少系统维护和管理工作量。支持基于WEB的查询备份对象、图表的存储空间显示、备份策略管理、计划管理。支持基于WEB的备份作业监控，可显示从触发、排队、启动、传输、存储整个过程。xxx管理系统采用两地三中心系统安全措施，防范了各种危害磁盘阵列硬件数据的风险（不包括软件或者人工误删除数据操作），出于灾备（DisasterRecovery）的目的，建设多个数据中心。主数据中心承担用户的核心业务，其他的数据中心主要承担一些非关键业务并同时备份主中心的数据、配置、业务等。正常情况下，主中心和备中心各司其职，发生灾难时，主数据中心宕机、备份数据中心可以快速恢复数据和应用，从而减轻因灾难给用户带来的损失。部署安全保障根据系统的安全设计目标及安全解决方案要求，对相关安全产品部署如下：在内部局域网中的重要服务器采用负载均衡或集群的方式，防止服务器单点故障，保障应用的高可用性。在网络边界，包括Internet网出口处部署防火墙进行逻辑隔离，通过限制IP地址来防护恶意攻击，这是第一道关卡；对允许访问业务管理系统的IP权限进行了严格的控制，这是保障网络安全的第二道卡，通过合理有效地配置防火墙可以阻挡来自外部的大部分攻击和非法访问。在信息化建设过程中，安全的建设目标和建设重点不能只局限于物理网络层，必须要对系统的总体信息安全予以高度重视，建立一套完整的安全防护体系，以保证系统和信息的安全。运行安全保障信息安全运行管理系统是对信息全管理体系（ISMS）的实现提供技术支撑，协助在信息和信息系统整个生命周期中实现安全管理方面人、技术和流程的结合。在信息安全管理体系（ISMS）的PDCA循环中为其计划阶段提供风险评估和安全策略功能，为执行阶段提供安全对象风险管理以及流程管理功能，为检查阶段提供系统安全监控、事件审计、残余风险评估功能，为改进阶段提供安全事件管理功能。信息安全运行管理系统提供一下功能：安全策略管理：包括安全策略发布、存储、修订以及对安全策略的符合性检查等。安全事件管理：包括安全事件采集、过滤、汇集、关联分析、事件前转发以及安全事件统计分析等。安全预计管理：包括漏洞预警、病毒预警、事件预警以及预警分发等。安全对象风险管理：包括安全对象、威胁管理、漏洞管理、安全基线、安全风险管理等。流程管理：主要是对各种安全预警、安全事件、安全风险进行反应，工单是流程的一种承载方式，因此可以包括产生工单、工单流转以及讲工单处理经验进行积累等。知识管理：所有安全工作均以安全知识管理为基础，包括威胁库、病毒库、漏洞库、安全经验库等信息安全运行管理系统支持分布式部署，并能够实现分安全域分级别管理。安全策略管理安全策略管理功能实现机构安全策略的导入、存储、修订、查询以及安全策略的集中管理。同时支持安全策略的不同格式的数据导出、安全策略的数据统计、安全策略的定时发布、安全策略符合性检查等功能，机构内所有安全策略的全流程管理。安全策略的各项管理操作通过安全策略管理与流程管理模块之