一台服务器换成两台服务器好处

一台服务器换成两台服务器好处如下：

1、主服务器和备份服务器服务器备份是指针对于服务器所产生的数据信息进行相应的存储备份过程，从而保障数据的安全运行，从狭义上来看信息的价值在于其潜在用途，并会随着时间的推移而改变。数据管理和保护可攫取信息的最大价值，并规避因未按照监管法规保留信息而导致的风险。企业应对当前和将来的信息使用方式进行评估，实施满足其全部需求的流程和技术。备份方式有增量备份，完全备份，差异备份。

2、负载均衡。简单说就是主服务器访问达到饱和状态时，会把一部分访问量分散到另一台或多台服务器上进行分流。网站负载均衡(LoadBalance)建立在现有网络结构之上，它提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

一、导语毫无疑问，数据安全是所有网络安全的核心，我们除了做好应有的安全防护措施，还应该从数据备份层面进一步加强数据安全。

数据备份有四种模式：本地备份、异地备份、数据热备和容灾备份。下面我们将分别讲述这些模式的特点和部署方法，让您轻松解决数据备份难题。

二、本地备份在服务器定时备份数据，是最基本，也是最必要的备份模式，任何稍微重要的数据都应该做本地备份。

本地备份推荐使用“好备份系统”，它是一款永久免费的数据备份软件。可以设置每天、每周、每月自动将网站和SQL数据库打包备份，并设置打包密码，支持完全备份和差异备份，支持分卷压缩、自动删除过期备份文件、在线还原备份等功能。基本上是国内最好用的本地备份软件。

三、异地备份异地备份是将本地数据，传输到远程服务器存档，防范本地服务器故障导致数据丢失，进一步提升数据安全。

建议先使用“好备份系统”做本地打包备份，再使用“护卫神·异地备份系统”将这些打包文件传输到远程服务器，提升传输效率。

护卫神·异地备份系统采取最简单方便的FTP模式传输数据，任何FTP空间都可以用来存储数据。支持实时监控模式，本地备份一完成，马上传输到远程服务器，减少间隙时间，降低风险。

四、数据热备数据热备是将源服务器的数据实时传输到远程服务器，始终保持两台服务器的数据一致。当源服务器出现故障时，可以使用远程服务器的数据，确保数据没有任何丢失。

1、文件热备文件热备可以使用“护卫神·异地备份系统”的实时监控模式解决，一旦发现文件有变更，立即将这个文件传输到远程服务器。

2、数据库热备大部分数据库都自带同步功能，只需要配置好分发和订阅，就可以实现数据库同步。具体实现方法可以购买“护卫神·数据同步服务”，由我司技术工程师为您解决。

五、容灾备份做好了本地备份、远程备份和数据热备，是不是就可以彻底放心了呢？

答案是否定的。

虽然以上三种备份解决了服务器故障导致的数据丢失，但是针对黑客篡改数据、管理员误删数据等情况还是没有解决。即使热备模式，黑客在篡改数据时，也是连同远程服务器一起篡改，无法在不损失数据的情况下恢复数据。因此还需要部署容灾备份解决此类问题。

容灾备份是在每一次数据变化时记录日志，只要找到对应的时间点，就可以将该时间点前的数据完全恢复。当我们误删数据或是黑客篡改了数据时，马上对数据库进行容灾恢复，数据就原封不动的还原了。

遗憾的是容灾备份只适合SQL数据库，只需要设置数据库为完整模式，就可以使用容灾备份来保护数据了。

总的来说，备份无小事，大家根据自己的需要，选择适合自己的备份方案。

从备份策略来讲，现在的备份可分为三种：完全备份，差异备份，增量备份，累积备份，现在来讲讲这几种备份之间的区别： 完全备份：指的是拷贝给定计算机或文件系统的所有文件，而不管它是否改变。 差异备份：只备份在上一次完全备份后有变化的部分数据。 增量备份：备份上一次备份后增加、改动的部分数据，增量备份可以分为：累积增量备份和非累积增量备份。 累加备份：采用数据库的管理方式，记录累积每个时间点的变化，并把变化后的值备份到相应的数组中，这种备份方式可恢复到指点的时间点。 一般在使用过程中，这三种策略常结合使用，常用的方法有：完全备份、完全备份加增量备份、完全备份加差异备份、完全备份加累加备份。 完全备份会产生大量数据移动，选择每天完全备份的客户经常直接把磁带介质连接到每台计算机上（避免通过网络传输数据）。这样，由于人的干预（放置磁带或填充自动装载设备），磁带驱动器很少成为自动系统的一部分。其结果是较差的经济效益和较高的人力花费。 完全备份加增量备份源自完全备份，不过减少了数据移动，其思想是较少使用完全备份。比如说在周六晚上进行完全备份（此时对网络和系统的使用最小）。在其它6 天（周日到周五）则进行增量备份。增量备份会问这样的问题：自昨天以来，哪些文件发生了变化？这些发生变化的文件将存储在当天的增量备份磁带上。 使用周日到周五的增量备份能保证只移动那些在最近24 小时内改变了的文件，而不是所有文件。由于只有较少的数据移动和存储，增量备份减少了对磁带介质的需求。对客户来讲则可以在一个自动系统中应用更加集中的磁带库，以便允许多个客户机共享昂贵的资源。然而，当恢复数据时，困难产生了。 在完全+增量方法下，完整的恢复过程首先需要恢复上周六晚的完全备份。然后再覆盖自完全备份以来每天的增量备份。该过程最坏的情况是要设置7 个磁带集（每天一个）。如果文件每天都改的话，需要恢复7 次才能得到最新状态。 由于完全+增量方法中恢复很困难，后来有了完全+差异方法。差异成为备份过程考虑的问题。增量备份考虑：自昨天以来哪些文件改变了？而差异方法考虑：自完全备份以来哪些文件发生了变化？对于完全备份后立即的备份过程（本例中周六），因为完全备份就在昨天，所以这两个问题的答案是相同的。但到了周一，答案不一样了。增量方法会问：昨天以来哪些文件改变了？并备份24 小时内改变了的文件。差异方法问：完全备份以来哪些文件改变了？然后备份48 小时内改变了的文件。到了周二，差异备份方法备份72 小时内改变了的文件。 在Tivoli 存储管理器之前，客户被迫在完全备份、完全+增量备份和完全+差异备份间权衡。许多客户在管理时都会混合和匹配这三种方法，试图得到期望的可重获性水平。 Tivoli 存储管理器引入了一个新范例叫累加备份方法。累加方法提出增量问题：自昨天以来哪些文件改变了？并把结果放到存储管理器数据库中。这样当首次用累加方法备份文件系统或计算机时，由于Tivoli 存储管理器以前未曾备份，所有的文件都将移动。当备份拷贝发送到Tivoli 存储管理器服务器时，每个文件单独存放在数据库中。文件名信息、所有者和安全信息、创建和修改时间，以及拷贝自身都放置在Tivoli 存储管理器服务器连续存储分层结构中（参见图8）。如果客户策略要求拷贝到磁带上，Tivoli 存储管理器数据库将记录磁带的条形码、起始块地址和文件长度。 在初始的备份后，将只考虑增量问题（不再进行完全拷贝）。每天将只移动上次备份操作后改变了的文件。并且，文件发送到Tivoli 存储管理器服务器后被单独存放在数据库中。当需要拷贝到磁带时，Tivoli 存储管理器服务器查询数据库，确定从前的拷贝在哪一个磁带上。一旦确定，将对该磁带进行再设置并把新拷贝附加在磁带末尾。这种对备份拷贝的收集都来自于同一台计算机或文件系统，于是形成了所谓的排列组。每天，改变的文件累加到排列组中（见图）。 现在让我们来看恢复操作。恢复操作的目标是让文件系统或计算机回到期望的某一时间点。常见的情况是客户期望的时间点就是最近某时刻。在累加备份方法下，完成一个完全的恢复操作只需告诉Tivoli 存储管理器服务器期望的时间点。利用时间点信息，Tivoli 存储管理器服务器查询数据库中文件集合，看它们是否在期望的时间点上。这些文件存在于同一个排列组上，通常也位于一个（或少数几个）磁带上。设置了正确的磁带后，数据库指定每个文件的长度和起始块位置。大多数现代的磁带驱动器都具有快速扫描功能，能迅速定位到期望的备份拷贝并执行恢复操作，这样只移动了期望的文件。您可以把该过程看作完全系统操作中一个完整的恢复过程。该过程就象在期望的时间点做了完全备份一样。 累加备份采用增量，提供了备份效率；采用排列组，提高了介质管理效率；准确地只移动期望的文件，提高了恢复效率。该方法最大的功效还在于：累加方法并不需要在一个完全备份后才能开始恢复过程，也就是说并不需要周期性地建立完全备份拷贝。而对完全+增量或完全+差异方法，无论是否改变，每周都要移动和存储大量数据。有了累加备份方法，就不需要这样做了。于是客户节省了大量的网络带宽（LAN、WAN或SAN）、磁带介质和时间。 不同的软件有不同的备份特点，客户可根据自己的数据特点，选择适合自己的软件或备份策略。 在rman 增量备份中，有差异增量和累积增量的概念 1、概念 差异增量：是备份上级及同级备份以来所有变化的数据块，差异增量是默认增量备份方式 累积增量：是备份上级备份以来所有变化的块…… Oracle 增量备份与恢复 在rman 增量备份中，有差异增量和累积增量的概念 1、概念 差异增量：是备份上级及同级备份以来所有变化的数据块，差异增量是默认增量备份方式 累积增量：是备份上级备份以来所有变化的块 因为累积增量是备份上级备份以来所有变化的数据块，所以累积增量需要更多的备份时间，同时需要较小的恢复时间；而差异增量正好相反，它可以备份同级备份以来变化的数据块。所以会减少备份时间，但需要更多的恢复时间在oracle 9 中增量备份需要通过扫描整个数据库的数据块才能知道哪些数据块发生了变化，这是一个代价很大，时间很长的过程，而且由于增量备份形成多个不同的备份集，使恢复变得更加不可靠，所以增量备份在版本9 中仍然不被推荐使用;在10g 中，增量备份作了很大的改进，不需要再扫描所有数据块就能得知哪些数据块发生变化，从而大大提升备份效率。但这些却以牺牲磁盘i/o 为代价，所以在oltp 事务系统中还得衡量是否愿意以i/o 为代价来保证安全及高可用性。10g 还支持增量合并，增量备份可支持7 级增量。 2、备份策略及恢复 以rman 多级增量备份来作为备份策略例子: 增量备份都需要一个0 级备份来作为基础，0 级备份与全备份的区别在于0 级可以用来增量恢复，而全备份则不可以。 备份策略： eg:我们对一星期做如下备份策略 ，那么差异增量只需要使用星期天的0 级，星期三的一级，星期四、五的二级就可以恢复，累积增量则需要星期天的0 级，星期五的二级即可进行恢复。以上是一个星期的备份策略,如果做长期的备份策略则只需要把备份的时间延长即可得到新的备份策略，具体需要看自己备份及恢复能够接受的程度而顶，见最后的备份策略典型案例。 星期天 0 级 0 级 星期一 2 级 2 级 星期二 2 级 2 级 星期三 1 级 1 级 星期四 2 级 2 级 星期五 2 级 2 级 星期六 2 级 2 级 星期天 0 级 0 级 备份命令如下： 零级备份 backup incremental level 0 database; 一级差异增量 backup incremental level 1 database; 一级累计增量 backup incremental level 1 cumulative database; 备份策略典型案例： 每半年做一个数据库的全备份（包括所有的数据和只读表空间） 每一个月做一次零级备份（不包含只读表空间） 每个星期做一次一级备份 每天做一次二级备份 任何数据库的更改需要重新同步CATALOG目录并重新备份（如添加数据文件）或重新备份（如修改表空间为只读） 建议备份一段时间归档日志和定期备份归档到到磁带上 全库备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup full tag ‘dbfull’ format ‘/u01/oradata/backup/full%u_%s_%p’ database include current controlfile; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 零级备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup incremental level 0 tag ‘db0’ format ‘/u01/oradata/backup/db0%u_%s_%p’ database skip readonly; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 一级备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup incremental level 1 tag ‘db1’ format ‘/u01/oradata/backup/db1%u_%s_%p’ database skip readonly; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 如果按照以上备份策略，则每天的所需要备份的数据量只有一天的改变量。而做恢复时最多要恢复当月的一个零级备份+三个一级备份+6 个二级备份+当天的归档文件。

不知道你是什么服务器 如果是2003的话

在开始 运行中输入 ntbackup

或者在开始-程序-附件-系统工具-备份 中运行备份程序

备份有几种类型 分别是

1常规(正常)备份:这种备份方式将备份所有选定的文件,并将其标记为已备份状态常规备份时,用户仅需要备份文件的最近副本就可以用于恢复所有的文件

2增量备份:这种备份方式只备份那些被标识为:"未备份"的文件,通常用于新建立的文件或上次增量备份后被修改的文件,也可能是被修改过但只做过差异备份、副本备份和每日备份的文件。增量备份完成后会将文件标记为已备份；即备份标记将被清除。如果用户将常规备份与增量备份结合起来使用，则需要最后一次常规备份集合和所有的增量备份集合来恢复数据。增量备份每次只会备份过去没有备份过的内容，所以备份速度很快，但恢复时则比较麻烦。

如果以每周为一个备份单元，可以在周一做一次常规备份，然后每天做一次增量备份。周一常规备份会备份所有文件，而周二至周五如果当天产生了新的文件或者修改了现有文件，增量备份会备份这些新增的文件和修改过的文件。如果从上一次备份到现在没有产生变化，那么增量备份将不会备份任何数据。

3差异备份：与增量备份一样，这种备份方式将备份那些标记为“未备份”的文件。但差异备份不将文件标记为已备份。而是保持备份标记的原由状态，如果用户结合使用常规备份和差异备份，那么在数据恢复时需要最后一次常规备份集合和最后一次差异备份集合来恢复数据。

如果以每周为一个备份单元，可以在周一做一次常规备份，然后每天做一次差异备份。周一常规备份会备份所有文件，而周二至周五差异备份会备份从周一常规备份湖这些新增的文件和修改过的文件，也就是如果周三至周五每天都有数据变化，那么每天的差异备份都包含前一天的差异备份内容。

说简单点,增量备份就是只备份没有备份过的东西而差异备份会包含前一次差异备份的内容

还有副本备份和每日备份用的不多。我就不一一介绍了。

如果你有需要的话，我再来说。

打了累死了。呵呵 希望能对你有用。

　关于数据库的备份恢复原理 大家多少都比较熟悉了 但是 你目前做的数据库备份有多可靠你可以安心睡觉了吗如果答案是肯定的 那就不用多花时间看下文了 如果觉得还不够安心 总担心数据库哪一天坏了修不好 那么请接着看

　 我有RAID 还需要做数据库备份吗需要 有了RAID 万一部份磁盘损坏 可以修复数据库 有的情况下数据库甚至可以继续使用 但是 如果哪一天 你的同事不小心删除了一条重要的记录 怎么办RAID是无能为力的 你需要合适的备份策略 把那条被误删的数据恢复出来 所以有了RAID 仍需要做备份集群 磁盘镜像同理

　 如果你只做全备份 那么受限于全备份的大小和备份时间 不可能常做 而且只有全备份 不能将数据库恢复至某个时间点 所以 我们需要全备份+日志备份 比如每天一个全备份 每隔 小时或若干分钟一个日志备份 说到差异备份 因为微软的差异备份记录的是上一次全备份以来发生的变化 所以 如果数据库的改动很频繁的话 没过多久 差异备份就会和全备份的大小接近 因此这种情况下就不合适了 因此 全备份+日志备份的方案适合绝大多数的用户

　 如果你仅在数据库本地做备份 万一磁盘损坏 或者整个服务器硬件损坏 备份也就没了 就没法恢复数据库 因此 你需要把备份文件传送至另一个物理硬件上 大多数用户不用磁带机 因此不考虑 一般 我们需要另一台廉价的服务器或者PC来存放数据库的备份 来防止硬件损坏造成的备份丢失

　 你可以在数据库服务器本地做完备份 然后使用某些方式将备份文件传送至备机 你是在备份完成后就马上穿送的吗其实可以考虑将传送备份的脚本用T SQL语句来写

　 备份文件传送至备机后 就可以高枕无忧了吗不 作为DBA的你还需要检查备机上的备份文件是否能将数据库恢复至最新 如果采用日志备份 会不会因为丢失某一个日志备份文件而导致数据库不能恢复至最新如何检查日志备份文件之间存在断档

　 为了将数据库尽可能的恢复到最新 你可能会每隔 分钟(甚至 分钟)执行一次日志备份 那么万一数据库坏了 在恢复的时候 手动恢复成百上千个日志文件 是不是不太现实

　 如果你所在公司有很多的数据库服务器(就像我所在的公司) 而且磁盘空间有限 那么你不得不经常登录服务器来删除旧的备份文件 如果哪天忘了 或者五一十一长假 磁盘空间用完了 就麻烦了

　 数据库在备份的时候 并不会检查数据页面的完整性 如果数据页坏了 备份作业仍会执行 而且不会报错 等到你发现数据页有错误的时候 你也很可能已经因为磁盘空间不足 而删除了早期的备份 而此时剩下的那些备份可能都是包含损坏的数据页 如果损坏的数据页是某个表的表头的话 那这个表你就再也没办法恢复了

　 所以你需要定期执行DBCC检查 来尽早发现数据库页面的完整性 在未作完DBCC检查之前 你不能删除旧的备份 以防止新的备份存在问题 所以 删除备份文件的工作变的有些麻烦

　 你可能知道SQL Server提供了数据库维护计划 没错 使用它可以定期做备份 执行DBCC检查 但这一切仅限于本机操作 为了使数据库可靠 你还是需要自己把本地备份传送至备机