.sql文件被加密恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.sql文件被加密恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

接到客户请求,有win系统文件被加密勒索,其中有一个mysql的.sql备份最为重要,咨询我们是否可以恢复.通过底层技术分析,确认该文件绝大部分数据可以恢复.
20210123225720


通过winhex分析,发现该文件主要对部分数据进行了加密
20210123231319

通过底层技术处理,可以实现绝大部分数据恢复
20210123231421

如果此类的Sql文件被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

ORA-600 3020错误引起ORA-600 2663

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-600 3020错误引起ORA-600 2663

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

数据库recover异常ORA-600 3020

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 5693717234723 generated at 01/19/2021 10:44:52 needed for
thread 1
ORA-00289: suggestion : +RECOVER/arch/1_294845_938895110.dbf
ORA-00280: change 5693717234723 for thread 1 is in sequence #294845


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+BACKUP/xifenfei/onlinelog/group_5.258.973180257
ORA-00279: change 5693717234723 generated at 01/15/2021 11:41:15 needed for
thread 2
ORA-00289: suggestion : +RECOVER/arch/2_336576_938895110.dbf
ORA-00280: change 5693717234723 for thread 2 is in sequence #336576


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DATA1/xifenfei/onlinelog/group_8.298.962885887
ORA-00600: internal error code, arguments: [3020], [128], [248606],
[537119518], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 128, block# 248606, file
offset is 2036580352 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 128: '+DATA1/xifenfei/datafile/undotbs1_02.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'


ORA-01112: media recovery not started

这个错误比较简单,一般是允许坏块继续恢复

SQL> recover database using backup controlfile allow 1 corruption;
ORA-00279: change 5693717234839 generated at 01/19/2021 10:44:52 needed for
thread 1
ORA-00289: suggestion : +RECOVER/arch/1_294845_938895110.dbf
ORA-00280: change 5693717234839 for thread 1 is in sequence #294845


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+BACKUP/xifenfei/onlinelog/group_5.258.973180257
ORA-00279: change 5693717234839 generated at 01/15/2021 11:41:15 needed for
thread 2
ORA-00289: suggestion : +RECOVER/arch/2_336576_938895110.dbf
ORA-00280: change 5693717234839 for thread 2 is in sequence #336576


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DATA1/xifenfei/onlinelog/group_8.298.962885887
ORA-00279: change 5693717637654 generated at 01/19/2021 10:47:25 needed for
thread 1
ORA-00289: suggestion : +RECOVER/arch/1_294846_938895110.dbf
ORA-00280: change 5693717637654 for thread 1 is in sequence #294846
ORA-00278: log file '+BACKUP/xifenfei/onlinelog/group_5.258.973180257' no longer
needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+RECOVER/xifenfei/onlinelog/group_3.258.973180321
ORA-00279: change 5693717705759 generated at 01/19/2021 10:48:07 needed for
thread 1
ORA-00289: suggestion : +RECOVER/arch/1_294847_938895110.dbf
ORA-00280: change 5693717705759 for thread 1 is in sequence #294847
ORA-00278: log file '+RECOVER/xifenfei/onlinelog/group_3.258.973180321' no
longer needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+BACKUP/xifenfei/onlinelog/group_7.265.973181365
Log applied.
Media recovery complete.

后续重建ctl,尝试recover库,报ORA-10877错误

SQL> startup mount pfile='/tmp/pfile'
ORACLE instance started.

Total System Global Area 1.0088E+10 bytes
Fixed Size		    2261928 bytes
Variable Size		 2181041240 bytes
Database Buffers	 7851737088 bytes
Redo Buffers		   53149696 bytes
Database mounted.
SQL> recover database;
ORA-10877: error signaled in parallel recovery slave


--对应的alert日志
Wed Jan 20 13:34:04 2021
ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 64 slaves
Wed Jan 20 13:34:06 2021
Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_pr00_50593.trc:
ORA-00313: open failed for members of log group 7 of thread 1
Media Recovery failed with error 313
Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_pr00_50593.trc:
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 7 of thread 1
ORA-10877 signalled during: ALTER DATABASE RECOVER  database  ...

resetlogs失败open数据库失败,ORA-600 2663

Wed Jan 20 13:42:34 2021
Setting recovery target incarnation to 2
Initializing SCN for created control file
Database SCN compatibility initialized to 3
Warning - High Database SCN: Current SCN value is 5693718057561, threshold SCN value is 0
If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.
Wed Jan 20 13:42:35 2021
Assigning activation ID 3801294256 (0xe29325b0)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: +RECOVER/xifenfei/onlinelog/group_1.260.973179783
  Current log# 1 seq# 1 mem# 1: +BACKUP/xifenfei/onlinelog/group_1.260.973179787
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jan 20 13:42:35 2021
SMON: enabling cache recovery
Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_52800.trc  (incident=189187):
ORA-00600: internal error code, arguments: [2663], [1325], [2886390384], [1325], [2886403118], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/incident/incdir_189187/xifenfei1_ora_52800_i189187.trc
Wed Jan 20 13:42:38 2021
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_52800.trc:
ORA-00600: internal error code, arguments: [2663], [1325], [2886390384], [1325], [2886403118], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_52800.trc:
ORA-00600: internal error code, arguments: [2663], [1325], [2886390384], [1325], [2886403118], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 52800): terminating the instance due to error 600

这个错误比较明显,由于scn的异常导致,通过调整scn,数据库正常open成功,然后使用hcheck检查数据库字典一致(运气不错),没有太大问题,后续建议客户进行逻辑迁移
20210121234330


Alpha865qqz.id 加密数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Alpha865qqz.id 加密数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

接到一网友新的加密勒索文件恢复请求,加密文件类似:
20210118193605


对应的!!! HOW TO BACK YOUR FILES !!!.TXT文件说明

                   YOUR FILES ARE ENCRYPTED !!!

TO DECRYPT, FOLLOW THE INSTRUCTIONS:

To recover data you need decrypt tool.

To get the decrypt tool you should:

1.In the letter include your personal ID! Send me this ID in your first email to me!
2.We can give you free test for decrypt few files (NOT VALUE) and assign the price for decryption all files!
3.After we send you instruction how to pay for decrypt tool and after payment you will receive a decryption tool! 
4.We can decrypt few files in quality the evidence that we have the decoder.


 DO NOT TRY TO DO SOMETHING WITH YOUR FILES BY YOURSELF YOU WILL BRAKE YOUR DATA !!! ONLY WE ARE CAN HELP YOU!CONTACT US:

China.Helper@aol.com

                   ATTENTION !!! THIS IS YOUR PERSONAL ID WICH YOU HAVE TO SEND IN FIRST LETTER:

Your personal ID: 5CF-DFF-C78

Attention!
 * Do not rename encrypted files.
 * Do not try to decrypt your data using third party software, it may cause permanent data loss.
 * Decryption of your files with the help of third parties may cause increased price (they add their fee to our)
 or you can become a victim of a scam.

通过winhex分析文件损坏情况,确认绝大部分数据是ok的
20210118194058


基于这样的情况,从通过我们专业工具进行最大限度恢复实现绝大部分数据恢复
20210118194644
如果此类的Sql Server/Oracle等数据库被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

incaseformat 病毒删除文件恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:incaseformat 病毒删除文件恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

一夜之间大量朋友反馈:电脑中除C盘之外的其他磁盘文件都被删除,且磁盘中可能被创建“incaseformat”文本文档
20210113160941
20210113161009


使用360扫描病毒如下
t01859d4dc0ddb2ba76

确认问题原因是电脑中病毒后,病毒文件通过DeleteFileA和RemoveDirectory代码实现了删除文件和目录的行为。此病毒启动后将自身复制到C:\WINDOWS\tsay.exe并创建启动项退出,等待重启运行,下次开机启动后约20s就开始删除行。发现文件不见了但空间占用还正常的,不要重启,先备份数据库。如果不小心已经重启而且无法恢复数据.请不要对该分区进行任何写操作,数据理论上绝大部分可以恢复.如果无法恢复,或者恢复出来的文件大量坏块,无法正常使用,可以联系我们进行最大限度恢复.

xfs文件系统mysql删库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:xfs文件系统mysql删库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户在centos 8操作系统上运行的mysql库,本来想删除一个测试表,结果反选了表,导致除该表之外表均被删除,大概有几百张表被删除.客户误操作之后,又使用一个月之前备份导致了十几张表然后终止,关闭机器,保护现场,请求我们给予支持.通过分析,发现该数据库放在/分区下面,第一时间和客户协商,对该分区进行镜像,防止由于系统运行引起的进一步覆盖.对于这类故障大概恢复思路:
1. 通过对xfs文件系统反删除操作,恢复可以恢复的被删除的mysql相关表文件
20210111185625


2. 对于该恢复出来的文件(包含ibd,myd),使用专业mysql工具进行恢复
20210111203401

3.对于异常的表,比如ibd部分损坏,缺少frm等,通过人工修复和单个对象扫描进行恢复
1)使用恢复方法:[MySQL异常恢复]mysql ibd文件恢复
2)使用4的方法进行恢复
4.对于xfs文件系统没有恢复出来的文件的表,尝试底层扫描尽可能恢复数据
恢复参考:MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)
如果您遇到MySQL恢复问题无法自行解决,请联系我们提供专业服务,最大程度减小您的损失:
Phone:17813235971    Q Q:107644445    E-Mail:dba@xifenfei.com
我们数据库恢复原则:最大限度恢复数据,最大限度减少业务影响时间,最大程度让客户满意

对恢复案例:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年事件有感

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:对恢复案例:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年事件有感

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

从业生涯中恢复过各种删库的场景(有恶意,有无意),有rm数据库,rm数据文件,drop 数据库,dd asm磁盘头,drop table,truncate table,delete table等等.
两年前的一次给链家恢复EBS数据库案例,数据库服务器被人恶意rm 删除了/u01,/u02,rman备份目录等文件(还有ebs服务器相关程序也被删除,由另外一家公司对其进行处理),导致oracle集群异常,无可用备份恢复,通过对asm磁盘组直接恢复,实现数据0丢失.最近有了法院的终审判决:
北京市海淀区人民法院认为,被告人韩冰违反国家规定,对计算机信息系统中存储的数据和应用程序进行删除,造成计算机信息系统不能正常运行,后果特别严重,其行为已构成破坏计算机信息系统罪,依法应予惩处.海淀法院判决:被告人韩冰犯破坏计算机信息系统罪,判处有期徒刑七年。
由衷的感慨一个40岁的老dba,为了一时的赌气冲动的做出了错误的事情,需要使用自己的7年青春去弥补,实在不值得.
1000


具体的关于判决的描述,参考:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年
我们做dba的,把握了企业的数据命脉,是很多企业最核心的资产,切莫因为一些工作/生活中的赌气去破坏数据库,引起系统无法正常使用,甚至导致数据丢失,给企业带来损失的同时,也让自己失去自由.
对于我们维护的数据库:切莫冲动!!!切莫冲动!!!切莫冲动!!!

Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

今天有一个客户数据库恢复请求,通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本分析发现resetlog信息异常
20210106182747


导致数据库恢复报ORA-01190 ORA-01110错

alter database open
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4404.trc:
ORA-01190: 控制文件或数据文件 1 来自最后一个 RESETLOGS 之前
ORA-01110: 数据文件 1: 'C:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF'
ORA-1190 signalled during: alter database open...

通过Oracle Recovery Tools工具进行修复resetlog 信息
20210106183450


再次尝试open数据库报ORA-1248错

SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01248: ?? 44 ????????????
ORA-01110: ???? 44: 'E:\ORADATA\ORCL\XIFENFEI.DBF'

Wed Jan 06 14:44:44 2021
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
ORA-1248 signalled during: alter database open resetlogs...

再次通过Oracle Recovery Tools进行修复SCN,数据库open成功

T:\xff>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期三 1月 6 14:47:36 2021

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup mount 
ORACLE 例程已经启动。

Total System Global Area 6.9214E+10 bytes
Fixed Size                  2182712 bytes
Variable Size            3.5165E+10 bytes
Database Buffers         3.3823E+10 bytes
Redo Buffers              224296960 bytes
数据库装载完毕。
SQL>
SQL>
SQL> alter database open;

数据库已更改。

Oracle Recovery Tools 12月份更新

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle Recovery Tools 12月份更新

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

根据以前恢复的场景,对Oracle Recovery Tools进行了一些bug修复和更新
1. 在win 2012版本中出现不能选择文件列表事宜进行了修复
20210105185723


2. 增加了对数据块大小为2048的支持(和数据块大小自动识别功能)
20210105185531

3. 增加了配置文件直接恢复功能,可以通过配置文件直接恢复,实现自定义方式恢复,让恢复更加灵活
20210105185546

下载地址:OraRecovery.zip
使用说明请参考:Oracle Recovery Tools

-bash: /bin/rm: Argument list too long

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:-bash: /bin/rm: Argument list too long

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

linux批量删除大量文件,当使用rm -rf *报-bash: /bin/rm: Argument list too long错误可以使用find+xargs搞定

[grid@xifenfei audit]$ rm -rf +ASM2_ora_1*_2017*.aud
-bash: /bin/rm: Argument list too long
[grid@xifenfei audit]$ ls|wc -l
111650450
[grid@xifenfei audit]$ find ./ -name "*.aud" |xargs rm -r
[grid@xifenfei audit]$ ls
[grid@xifenfei audit]$

ORA-27303: failure occurred at: skgpwinit6

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-27303: failure occurred at: skgpwinit6

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在客户联系我们,数据库在运行过程中突然报ORA-27140 ORA-27300 ORA-27301 ORA-27302 ORA-27303: failure occurred at: skgpwinit6错误
20201231173708


通过Startup Instance Failed with ORA-27140 ORA-27300 ORA-27301 ORA-27302 and ORA-27303on skgpwinit6 (Doc ID 1274030.1)分析,确认可能是由于$ORACLE_HOME/bin/oracle文件权限异常导致,通过分析确认是有系统被chmod修改了权限导致数据库异常.把oracle全下修改为chmod 6751 oracle后,数据库启动正常