恢复数据硬盘/备件盘分别如下：
恢复数据硬盘：ExcelStor/Model:J8080S/SN:Q4B7LCH/Firmware Rev:P210ABEA/SATAII/Site code:111110
备件硬盘：

易拓（ExcelStor）硬盘数据恢复工程：
易拓硬盘/Made in China，好一个中国制造，没有工具进行固件操作分析，值得庆幸的是易拓硬盘日立技术中国产，我们采用日立在线编程模式，成功访问到了固件表，但是固件模块地址与信息有些区别，在日立硬盘中，家族的区别固件性还是很大的，幸运的是这个硬盘在发来的时候带着一个相同的备件盘，日立硬盘ROM信息不对也会发生这样的故障，我们现在能够查看NV-RAM,那么先从NV-RAM入手吧；

左侧为在线编程模式下获取到的数据恢复硬盘NV-RAM信息，右侧为备件盘信息：

通过对比发现mu-code信息是不一致的,SRVM Cyl Base信息每一块硬盘都不尽相同，那么下一步考虑从固件中获取有用信息来验证问题了。
通过能够获得的固件，我们进行查证，发现NV-RAM信息是正确，随后我们通过固件表模块，成功完成了更多信息的获取，最后确定了哪个固件存在问题，最终硬盘得到了修复，成功完成了数据的恢复读取。
过程插曲，模块表信息不完善，有些模块无法读取，缺陷表模块信息多次结果反复无常，种种的问题发生可能是没日立与易拓硬盘还是存在区别的问题吧。

错误解决：
uc_notelist缺少app2字段，app2对应于"应用2",在创建应用的时候ucenter需要修改uc_notelist添加对应的字段。
连接到mysql,show columns from uc_notelist; 发现果然没有app2字段，说明ucenter并没有成功创建该字段,

下载checkappid.php到uc_server目录网站并运行，出现如下错误：
Error:ALTER command denied to user 'xxxx'@'localhost' for table 'uc_notelist'
Errno:1142
SQL::ALTER TABLE uc_notelist ADD COLUMN app1 tinyint NOT NULL

说明xxxx用户没有ALTER权限。
到mysql中，
mysql> SELECT alter_priv FROM user WHERE  User = 'xxxx';
发现alter_priv = 'N',果然没有权限。
修改权限：
mysql> UPDATE user SET alter_priv='Y' WHERE User = 'xxxx';
mysql> flush privileges;

重新运行checkappid.php出现：
PHP Warning: unlink(c:\wwwroot\checkappid.php): Permission denied in c:\wwwroot\checkappid.php on line 31
说明checkappid.php修改appid已经成功，我们手工删除checkappid.php即可。

mysql> show columns from uc_notelist;
各个应用的appx都已创建好。

UCenter Checkappid下载

          为了恢复Hitachi HDP725016GLA380数据，还是从前边的故障点开始更加细致的分析思考，以怎样能够更加安全的恢复数据为重点，当前硬盘无法识别，首先考虑如何让硬盘识别，还要保证数据能够安然存在，哈哈，有问题解决问题，有事情解决事情。
一：电路板故障分析：
从朋友那里快递发来了此款硬盘的电路板，开始了第一步的征程：
1：直接更换电路板后，故障状态、内部声音还如以前相同；
2：将原电路板ROM备份后刷写到备件电路板，故障表现依然相同；
结论：通过更换电路板测试，电路板没有问题，开始进行第二种故障点的尝试。
二：固件依然无法入手，如下图：
1:通常情况下短路电路板是可以准备就绪的，但是这个硬盘无效；
2:模块读取肯定是不可能了，不过采用另外的手段是可以完成的，这里也让我们看到了希望。

三：磁头问题？！
经查找都没有这款硬盘，只有两个朋友那里有此款硬盘，容量为250G、500G的，没有160G的，看来更换磁头是不好实现了，没有磁头备件呀！我们在无尘室内使用专业三维成像设备进行了磁头查看，发现磁头有些磁粉玷污，通过以往IBM(Hitachi)磁头检测经验来讲，现在情况不至于磁头无法使用，为了保证磁头能够安全有效的使用，我们使用专业磁头清洗设备，对磁头进行了清洗，将磁头装配回硬盘后，进行测试，故障还是与原先情况一致，通过这些实际数据，我们认定磁头为完好的。

最后的总结：经过详细分析判断后，我们采用SATA信号寄存单元，成功完成了修复，硬盘盘片存在一些问题，但是不影响数据的恢复，硬盘正常的识别了，数据得到了完整恢复。

在上述步骤中，如果都未出现问题，可尝试以下解决办法：

将/data/data_config.php 文件删除,系统将自动新建这个缓存文件,问题解决了,通信正常!

网友修改物理路径解决方法：
在UC里面设置好“应用的物理路径”就可以了，具体如下：
进入Ucenter后台->应用管理->UCH的编辑->填写应用的物理路径为”../home" (不带双引号，具体要根据自己空间中各应用的相对地址来写)

我的解决方法：
1：登陆PHPMyAdmin管理，找到如下图数据表：

2：修改APPID字段值，删除前ID是2，所以在重建后修改成相应的字段ID,如下图所示：

修改完毕后登陆UCenter应用查看，通讯正常了；

希望以上的各个方法对出现UCenter应用中通讯失败的朋友起到借鉴的作用。

一看是9003错误,就想到可能是由于日志文件的原因,再看数据库文件可能损坏,于是想到dbcc checkdb指令.

方法如下:
--1．我们使用默认方式建立一个供恢复使用的数据库(如pos)。可以在SQL Server Enterprise Manager里面建立。
--2．停掉数据库服务器。
--3．将刚才生成的数据库的日志文件pos_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件pos_data.mdf。
--4．启动数据库服务器。此时会看到数据库pos的状态为“置疑”。这时候不能对此数据库进行任何操作。
--5．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
exec sp_configure 'allow updates',1
go
reconfigure with override
go
--6．设置pos为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('pos')
--此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

--7．下面执行真正的恢复操作，重建数据库日志文件

go

dbcc rebuild_log('pos','D:\Program Files\Microsoft SQL Server\MSSQL\Data\pos_log.ldf')

go
--执行过程中，如果遇到下列提示信息：
--服务器: 消息 5030，级别 16，状态 1，行 1
--未能排它地锁定数据库以执行该操作。
--DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
--说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了pos库的系统表，那么退出SQL Server Enterprise Manager就可以了。
--正确执行完成的提示应该类似于：
--警告: 数据库 'pos' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
--DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
--此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

--8．验证数据库一致性（可省略）

go
dbcc checkdb('pos')
--一般执行结果如下：
--CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'pos' 中）。
--DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

--9．设置数据库为正常状态
go
exec sp_dboption 'pos','dbo use only','false'
go
--如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
--10．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
exec sp_configure 'allow updates',0
go
reconfigure with override
go

        带着备用服务器备件到了机房，进行了可能损坏的硬件进行更换，重新测试稳定了，考虑到服务器在运送中的颠簸，硬盘可能也受到极大的伤害，怕无法稳定工作，也将带去的两块SAS备件硬盘使用上了，SAS新品的传输速度改观好多，拷贝数据那是相当的快，在机房将网站调试好，急匆匆跑到了南京哥们那里，哥们热情款待，也许世间就是这样，总是说去哥们那里，可是迟迟没有去，这次服务器问题，让我有幸与只能在网络与电话中的哥们见面了，言语无法表达此时的心情，心中感激朋友对我事业上的的支持与帮助，5年前的朋友也同坐一堂，虽然没有太多的语言，没有太多的喧嚣，人生最大的财富莫过此，古话曰：朋友千千万，知己一个也难寻，说明是多么的不容易，拥有这么大的财富，才是最为值得珍惜的。

Seagate/希捷15K7  SAS硬盘介绍：

主要優勢

• 第三代垂直記錄技術讓容量最大化。
• 持續資料傳輸速率效能比上一代增加 16%，最高可達空前的 171 MB/秒。
• 業界最可靠的 3.5 吋硬碟機，其 MTBF 長達 160 萬小時。
• Seagate 獨家的 PowerTrim™ 技術可使閒置時的單位 GB 用電量 (瓦) 比上一代節省 21%。
• 進階讀/寫技術，不可復原之錯誤率只有 1x10E16 ，而 AFR 僅 0.55%
• 有 4 Gb/秒 FC 或 6 Gb/秒 SAS 介面可供選擇

最佳應用

 

所有主流的企業應用環境，例如：

• 電子郵件
• 商業處理
• 交易處理
• 決策支援
• 儲存區域網路
• 網路連接儲存設備
• 網際網路和電子商務

三星HM16HJI硬盘数据恢复视频下载

Samsung HM16HJI硬盘：

        2：如发现转载后使用其他网址出处，原创作者有权禁止其网站转载，也希望转载网站对作者尊重。

        3：对于将博客日志改写，博主不为此作出任何解释与声明，转载着将自行承担引发的一些列问题及责任。

        关于《希捷7200.12(ST31000528AS/ST3500418AS)固件问题重新上演》只是在工作中遇到的维修数量之多与个人对此系列硬盘故障的一个总结，不含有任何商业行为，当众多网站在互联网转载此文后，各地也褒贬不一的出现了7200.12的故障硬盘客户，有些表现与文中描述相符，虽然这些代表不了什么，却是事实的鲜明写照，有些朋友，很有意思的说让出具统计数字，那么在7200.11代出现故障的时候有统计数字吗？我不是统计公司，也不是希捷公司，我统计来统计去有什么意义呢？！发表个人观点的博客日志记录工作中遇到的事情并加以证实，只是为了更加了解各品牌各系列硬盘的故障以及解决方案，仅此而已。

        我博客中也有当时7200.11代的日志，那个时候没有几个人关注，可是在一段时间后，结论已经揭晓，事实必定是事实，早发现早解决，这也是非常好的。另外，昨日接到希捷新加坡来电，我已经提供硬盘信息，希捷工程师将要找到硬盘进行分析，官方如果出具结果，让使用希捷硬盘的用户放心何乐而不为呢！

          以上图片来自于其中一个客户的硬盘损坏，驱动器忙，Bios识别型号查看LBA=0，在使用希捷指令修复过程前后用手机的拍照，在接手的7200.12代硬盘中，以上表现尤为突出；
案例一（硬盘呲挞声音不断，nzg8899反映）

案例二（硬盘BIOS可以识别硬盘型号，LBA=0）
          使用途中突然出错， bios可以检测到 ，系统只有用工具可以检测到型号 ，拿去修说是LBA为0；
原帖地址：http://bbs.intohard.com/thread-59229-1-1.html

案例三（刚买半个月的希捷1TB硬盘现在就成这样了，怒了。）
极速社区tv8原文如下：
          当时兴冲冲的把所有硬盘的中的文件拷贝到这个900多个G的大分区中，没有发现什么问题。
          然后把第一个30G的分区装系统，结果自从装好系统以后就老出问题，会蓝屏死机，当时以为不兼容，因为我的主板是875p的，只支持sata1代，后来就试了硬盘跳线，设成只支持sata1，后来还换了一根好点的带夹子的sata线，都不行，都会死机，死了机以后重启就找不到硬盘了，折腾了我好几天，也找不到原因，当时看到系统日志中有什么磁盘控制器错误，但是不知道为什么，后来只能拿其他硬盘装系统，今天用了hdtune测试了一下才知道，原来30G那个分区中有坏道，健康状况是衰退。
          上次看到另一个朋友也是这样的错误，心想他可能是RPWT呢，结果我自已的也是，真气人，
          明天准备把900多G的东西全倒回去，再把硬盘装瞒电影，然后再格式化一下，拿去瑞菌换去。

更多7200.12代信息与硬盘图片正在收集整理，敬请关注。。。。

转载此文信息请注明来自：中国硬盘基地 http://www.intohard.com 或 八喜网络日志 http://www.8xif.com