硬盘驱动器故障暴露出备份脆弱性

简介:

硬盘驱动器更换看起来简单,其实正好相反,IT部门必须深入到服务器的核心才能真正提供解决方案。

数据中心有一台服务器闪烁着琥珀色的灯光,这个警告意味着硬盘驱动器有潜在的问题。通常,当一个灯在这里和那里开始闪烁时,人们呼吁更换驱动器,希望热插拔驱动器,并采取一种快乐的方式。但一次经历却大不相同。

在那一天,有两个驱动器在忙碌的时候开始闪烁。并已列入工作人员的待办事项列表好几天了,当另一个IT员工Bob询问是否需要注意这种状况,所以将这个任务交给Bob处理,他要求在第二天交付新硬盘。

几天后,Bob表示硬盘驱动器已经更换,一个已经重建,另一个要花费一段时间恢复。

不祥的预兆

然而不久,一名员工报告说无法访问公司的共享驱动器。技术人员开始研究它,当技术人员与另一个用户接触时,表示也遇到了同样的问题。工作人员开始意识到,所有的迹象都表明这些明显的新问题与最近更换的硬盘驱动器有关。

工作人员远程访问发生问题的服务器,这台服务器托管了五个虚拟服务器。在这一点是公司的心脏和灵魂,也就是企业的主要数据库,被托管在不同的物理服务器上。

当工作人员在远程登录时,看到一个警告,虚拟磁盘不再存在,意识到Bob已交换的两个硬盘驱动器被同时从同一个阵列拔出。服务器在RAID5+0中的原始设置比较早,并没有得到破坏。

更深层次的问题

在初始的拒绝和希望服务器可以正确启动后,工作人员转向备份,据说是设置为通过iSCSI提供NAS。工作人员已经检查了随着时间推移的日志,直到工作成功完成。但是无法验证这一点,因为一些虚拟服务器还包括这家公司的备份软件。

最终,工作人员意识到备份已经消失了。似乎服务器已经复制并存储在与原始虚拟服务器相同的主机上,在这种情况下显然没有什么好处。

工作人员对此感到恐慌,他们希望可以做些什么,以便恢复和运行,至少让用户可以登录(因为域控制器被擦除),并能够访问几个月前迁移到NAS的公司数据。

Bob在报告问题后很快与同事从头开始重建域控制器,Office365控件,打印服务器和许多其他功能。终于能够及时地解决了问题。在接下来的几个星期,工作人员开始恢复在服务器丢失缺少的信息,并最终从虚拟磁盘损坏时创建的大量数据中挖掘出来。

现在是人们重新审视核心IT流程和提醒关键要点的好时机:

·始终检查备份的物理位置,以验证其是否存在,而不是单独的备份日志。

·了解企业的RAID阵列以及公司或客户的具体情况,并在进行更改时小心谨慎。

·执行任务,如在数据灾难发生后,硬盘驱动器交换等。

·再次检查备份。

·IT工作更加仔细小心,以防万一。

·不要将所有鸡蛋(或虚拟服务器)放在一个篮子中。

·为了更好的实施,请再次检查这些备份。

本文转自d1net(转载)

目录
相关文章
|
3月前
|
存储 数据库 数据安全/隐私保护
服务器数据备份是保障数据安全、防止数据丢失和灾难恢复的重要措施
服务器数据备份是保障数据安全、防止数据丢失和灾难恢复的重要措施
71 1
|
6月前
|
存储 数据管理 数据处理
网络的备份系统
【6月更文挑战第21天】网络的备份系统
93 2
|
7月前
|
存储 关系型数据库 MySQL
备份和恢复:确保数据安全
备份和恢复:确保数据安全
105 1
|
监控 安全 数据安全/隐私保护
服务器数据恢复—如何预防服务器故障?发生故障后如何恢复服务器数据?
服务器常见故障: 硬件故障:磁盘、板卡、电源故障等。 软件故障:操作系统崩溃、程序运行错误等。 入侵破坏:加密、删除服务数据等。 不可控力:浸水、火烧、倒塌等。 误操作:格式化、删除、覆盖等。
|
SQL 运维 测试技术
记一次由于操作失误致使数据库瘫痪的故障分析与解决方案
在这篇文章中,我将分享一次由于操作不当导致数据库瘫痪的经验。通过回顾故障发生的时间、系统简介、时间线、问题分析和经验总结等方面的内容。讨论操作时间不当、操作流程不当、缺乏执行计划和限流机制等问题,并提出一些建议,如确认数据库更新时间、优化更新操作、使用限流工具、设置超时时间和重试机制、调整数据库参数以及定期维护和优化数据库。通过分享这次经验,我希望能帮助他人避免类似的错误,并提高数据库操作的准确性和稳定性。
110 0
|
监控 容灾 安全
系统总出故障怎么办?
系统总出故障怎么办?
109 0
|
缓存 运维 监控
IT硬件故障的主要原因和预防的最佳实践
企业组织面临的超过 45% 的网络中断完全是由于硬件故障造成的,因此 24x7 全天候监控硬件至关重要
373 0
IT硬件故障的主要原因和预防的最佳实践
|
运维 数据库
故障定位方法-磁盘故障定位手段
常见的磁盘故障是磁盘空间不足、磁盘出现坏块、磁盘未挂载等。 磁盘故障有的会导致文件系统损坏,比如磁盘未挂载,集群管理自动定期做磁盘检测时会识别故障并将实例停止,查看集群状态时对应实例状态异常;有的不会导致文件系统损坏,比如磁盘空间不足,集群管理无法检测到,服务进程访问到故障磁盘会异常退出,比如:数据库无法启动、checksum校验不对、页面读写失败、页面校验错误等。 对于会导致文件系统损坏的故障,查看集群状态会显示对应实例状态持续为Unknown,定位方法如下: 查看cm_agent日志,日志保存在mpp/omm/cm/cm_agent,日志中会有类似“data path disc wri
392 0