这10大常见数据备份错误,招招致命

存储 数据管理
所有的IT人士在进入这个行业的第一天就明白定期备份对于企业数据来说是一件极为重要的事情。但在实施备份工作时,仍然有人还是不小心会犯一些致命错误。

 所有的IT人士在进入这个行业的第一天就明白定期备份对于企业数据来说是一件极为重要的事情。但在实施备份工作时,仍然有人还是不小心会犯一些致命错误。

1.没有频繁的进行系统状态备份

在Windows环境中,系统状态备份都是有一个有效期的。对于域控制器来说,这个有效期等于tombstone最大有效期(默认为60天)。在此之后,备份将清零。就算没有域控制器,有效期仍然是备份时需要考虑的问题。

在Windows网络环境中,每一台电脑都在活动目录AD中有一个相对应的账号。和用户账号一样,计算机账号也有与之关联的密码。两者之间的不同之处是,计算机帐户的密码是指定的,并且由Windows定期更换。如果你试图恢复一个古老的备份文件,那么这个备份文件中包含的计算机帐户密码将不能与当前该计算机在AD中存储的密码相匹配,这将导致该电脑无法进入域。虽然有变通的办法来解决此问题,但最简单的办法还是较频繁的进行服务器系统状态备份。

[[228880]]

2.没有充分对备份进行测试

我们都知道应该定期对备份进行测试,但是实际上我们都觉得测试应该是在出现错误或备份不完全时才做的。不要忘记,备份只是灾难解决方案的第一步,如果我们不能顺利恢复备份文件,那么一旦灾难发生我们就惨了。因此必须确保备份后的文件能够真正被恢复。

3.未使用有程序感知能力的备份程序

对于一些应用程序,初级的备份并不够的。一个典型的例子就是Microsoft Exchange,对其进行备份需要一个具有应用程序感知功能的备份工具。如果备份工具选择错误,会导致所备份的数据内容处于不一致的状态(通常无法被恢复)。因此,要清楚你的服务器上都安装有哪些应用程序,以及这些程序是否对备份工具有特殊要求。

4.将备份磁带转移的速度太快

业内有家公司里,他们每天早上八点会通过快递将之前一天的备份数据磁带运送到指定的离线存储地点。一天早上,系统在九点半时崩溃了,而备份的磁带此时正在送往离线存储点的路上,无法立即进行数据恢复。直到第二天凌晨4点,我们才确定了备份磁带所处的位置。当系统回复时,距离系统当机已经有差不多一整天了。

5.单点错误

永远要记住,备份就是系统的安全网。一旦一个服务器崩溃,你的备份文件就成为了最优先的(有时候也是唯一的)系统状态恢复机制。

正因为备份是如此重要,因此我们应该尽量避免单一性错误对于备份造成的破坏。如果可能的话,可以对你的备份文件进行再次备份。因为我们谁都不希望每天晚上因为没有备份系统而整夜祈祷系统不要崩溃。

6.没有计划好未来

有时候,为了环境整洁的需要,公司人员会打扫凌乱不堪的存储设备机房,并且扔掉了一些废旧的电脑设备。虽然这个工作看起来并没有什么不利影响,但是老设备之所以被放置在存储设备机房,就自然有它存在的道理。

即使技术不断的更新,我们仍需要保留一些必要的老设备和软件来读取古老的备份磁带。

7.没有考虑使用备份安全机制的后果

对于大多数企业来说,IT安全都是首要问题。但是有时候,安全机制也有它的副作用。实际工作中,由于所有人都不记得备份时的密码而导致备份数据无法被恢复的囧人案例在不停发生。由于采用了硬件级加密措施,导致在升级磁带机时出现了新磁带机无法支持之前的加密方式(这意味着老磁带上的备份数据将无法被恢复)的情况也一样会存在。

备份数据必须被加密,这是毋庸置疑的,但是衡量安全机制的后果也是同样重要的。如果你必须在系统出现重大错误后通过备份文件恢复系统,你会发现一个强大的安全措施会挡在你进行数据恢复的道路上。

8.只备份数据

有人说,只需要备份数据就可以了,而服务器系统以及服务器上的软件则不需要进行备份。虽然这么说看似有一定道理,实际上完全行不通。

如果企业服务器出现重大问题需要进行全面恢复,可以先重新安装操作系统,然后重新安装所有必要软件,再根据备份文件进行数据恢复。但是在进行灾难恢复时,时间往往是一个重要的因素。直接对整个系统进行恢复所耗费的时间,远远少于重新安装操作系统和软件后在恢复数据的时间。更重要的是,很难手动配置一个服务器,与之前的服务器配置参数完全一致。而对整个系统进行备份则可以完全不必考虑这些棘手的问题。

9.仅仅依靠磁盘到磁盘的备份方案

与传统的磁带备份相比,磁盘到磁盘的备份解决方案具备了很多额外的功能和优势。尽管如此,企业也不能把磁盘到磁盘的备份解决方案作为唯一的备份方案,因为备份服务器也会面临和其所备份的服务器一样的风险。一次飓风,一个闪电,火灾或者地震等就可以将所有备份数据消灭掉。因此,定期将磁盘上的备份数据定期备份到磁带上是很有必要的。

10.使用间隔太短的磁带轮换计划

曾有企业采用了周期为两周的磁带轮换计划。看上去这个计划还不错,不过后来发现两周的时间周期有点短了。一次,这个企业的Exchange服务器由于信息数据被破坏而出现崩溃。尝试恢复备份文件时发现,所备份的数据同样存在被破坏的情况。数据损坏的情况已经出现了一段时间并且愈演愈烈,最终导致Exchange服务器崩溃。我们备份的每一个磁带上所存储的都是被破坏的数据内容,从而导致服务器无法被顺利恢复。

这同样验证了之前所提到的,对备份系统进行校验是多么重要的一件事。另外这个案例也告诉我们,如果采用磁带轮换计划,一定要有足够长的轮换周期。

责任编辑:武晓燕 来源: 中科同向
相关推荐

2010-07-20 10:28:04

刀片服务器

2017-08-28 16:11:48

2017-10-09 14:09:15

数据中心运维

2023-08-28 00:46:05

计算机模型

2024-05-28 11:44:54

Redis数据结构数据库

2018-09-27 11:48:51

2017-06-14 08:15:58

2019-06-03 15:45:21

Windows 10VirtualBox安装

2018-09-27 21:53:51

综合布线网络

2009-01-18 09:30:00

DHCP部署设置

2019-11-21 15:43:04

5G智能手机技术

2023-03-09 09:38:01

数据科学

2019-08-13 09:40:55

数据结构算法JavasCript

2019-08-01 11:27:46

数据复制数据源中间层

2011-08-05 13:29:04

分页

2024-06-19 15:32:07

2012-06-06 10:13:14

虚拟化虚拟机

2024-10-09 16:45:47

2018-03-14 10:51:00

数据库容灾技术

2023-09-19 14:03:41

数据中心服务器
点赞
收藏

51CTO技术栈公众号