又一起mysql rm删除数据库目录事故

有mysql用户直接使用rm命令删除了所在数据库目录文件夹(删除途中发现删除错误,直接强制终止使得部分删除,部分文件得以保留),如果数据库没有crash,这个问题不大,可以直接通过句柄进行恢复出来对应的ibd文件,然后进行一些特殊处理,数据理论上不会有丢失,参见:mysql 数据库目录被删除恢复.对于这次的情况,只能通过文件系统级别进行恢复,不过该数据库表比较多,大概删除了几千个文件,而且文件系统是ext4,导致大量文件目录被置空,而且该库还运行了一段时间
20200507231749


看来文件恢复删除这条路,基本上很难走得通,可以通过底层碎片技术恢复,通过底层扫描,找到不少碎片
20200510173725

由于涉及的库表多,一个个处理太费时间,通过批量脚本直接解析扫描出来的碎片,并且对其进行入库处理
DBLOGIN=”-uroot ”
DICT_DBNAME=test
RECOVER_DBNAME=xifenfei
WORK_PATH=”/nfs_share/mysql-xff”
cd $WORK_PATH
>/tmp/recover_table_list.$RECOVER_DBNAME
>/tmp/recover_table_parser.$RECOVER_DBNAME
>/tmp/recover_table_unload.$RECOVER_DBNAME
rm -rf /tmp/recover_table_unload_$RECOVER_DBNAME.tmp
echo “tee /tmp/recover_table_unload_$RECOVER_DBNAME.tmp” >/tmp/recover_table_unload.$RECOVER_DBNAME
echo “SET @enable_trigger = 0;”>>/tmp/recover_table_unload.$RECOVER_DBNAME
echo “SET FOREIGN_KEY_CHECKS=0;” >>/tmp/recover_table_unload.$RECOVER_DBNAME
for TABLE_NAME_ID in `mysql $DBLOGIN $DICT_DBNAME -NBe “SELECT SYS_TABLES.NAME FROM SYS_TABLES LEFT JOIN SYS_INDEXES ON SYS_TABLES.ID = SYS_INDEXES.TABLE_ID WHERE SYS_INDEXES.NAME IN (‘PRIMARY’, ‘GENERAL_CLUSTERED_INDEX’) AND SYS_TABLES.NAME LIKE ‘${RECOVER_DBNAME}/%’”`
do
PKEY=`mysql $DBLOGIN $DICT_DBNAME -NBe “SELECT SYS_INDEXES.ID FROM SYS_TABLES LEFT JOIN SYS_INDEXES ON SYS_TABLES.ID = SYS_INDEXES.TABLE_ID WHERE SYS_INDEXES.NAME IN (‘PRIMARY’, ‘GENERAL_CLUSTERED_INDEX’) AND SYS_TABLES.NAME=’$TABLE_NAME_ID’”`
echo $TABLE_NAME_ID’,’$PKEY >>/tmp/recover_table_list.$RECOVER_DBNAME
TABLE_NAME=$(echo `echo $TABLE_NAME_ID`|awk -F”/” ‘{print $2}’ )
#echo $TABLE_NAME
PAGE=”pages-ibdata1/FIL_PAGE_INDEX/`printf ‘%016u’ ${PKEY}`.page”
echo “./c_parser -5f $PAGE -b pages-ibdata1/FIL_PAGE_TYPE_BLOB -t dictionary/$TABLE_NAME.sql > dumps/default/$TABLE_NAME 2> dumps/default/$TABLE_NAME.sql” >>/tmp/recover_table_parser.$RECOVER_DBNAME
echo “source dumps/default/$TABLE_NAME.sql” >>/tmp/recover_table_unload.$RECOVER_DBNAME
echo “select ‘$TABLE_NAME.sql……done’;”>>/tmp/recover_table_unload.$RECOVER_DBNAME
done
echo /tmp/recover_table_parser.$RECOVER_DBNAME
echo /tmp/recover_table_unload.$RECOVER_DBNAME
恢复之后数据整体入库,查询部分没有覆盖表,效果尚可,最大限度抢救了数据
20200511225518

发表在 MySQL恢复 | 标签为 , , | 评论关闭

.SATANA加密数据文件恢复

有朋友win环境中运行oracle数据库文件被加密,扩展名为:.SATANA
20200510201035


对应的how_to_back_files.html文件内容如下:
20200510200738

通过分析此类文件,可以实现数据绝大部分恢复
20200510200738

如果你遇到类似加密病毒并加密的数据库(oracle,mysql,sql server),可以联系我们在不给黑客交款的情况下实现较好恢复效果(恢复不成功不收取任何费用)
Tel/微信:17813235971    Q Q:107644445 QQ咨询惜分飞    E-Mail:dba@xifenfei.com提供专业的解密恢复服务.
防护建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。查看范围包括:
a)是否有新增账户
b) Guest是否被启用
c) Windows系统日志是否存在异常
d)杀毒软件是否存在异常拦截情况
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。

发表在 勒索恢复 | 标签为 , , , , | 评论关闭

.KEYnnnn勒索病毒恢复

又一种新的加密勒索病毒出现,其后缀名为KEYnnnn,HOW_TO_RECOVERY_FILES.txt的勒索信息

ALL YOUR FILES ARE ENCRYPTED!

Send 1 test image or text file 
giveyoukey@tutanota.com or giveyoukey@cock.li. 
In the letter include YOUR ID or 1 infected file!
We will give you the decrypted file and assign the price for decryption all files!
Doesn't try to restore by yourself, You can damage your files!


2AB74B35FA0ACE323834AF2CC410DCC4114982A0B0A986F4E5A0CF2B580C2BF4
846E5EBBCE1E7CFD3C3F09ACA85EE5865BE6F439A5B28786A75E987DFC95FDCF
6BACDB93C11264CBA9B4EDA2D6B0561866026EC96830DD439E56B667BC33B944
68CB9E1693F5416D5B3A5AED97E44747C0E753E825C87F59E2CA61222E6EA95B
BB8C27C0DC324FE29634929C4084825716F403F4A46C3877D803B2F2FBDFA95B
EE3CAFC8394C2521017ECD44BD0B06DA5B031A5F4D3317815C261413E0A2992C
1A3699EC332C6EF207863E50B278D843150D6850F9324EC28270376589B24C4D
D288B53E0ADB4734A93D4DE1374931731B92B88B4C61F17BFB1CAE5D1F410DF9
98BE3312E3DF7A75A01C6E23403EAEA2DAA1A1641872DD5C1292DF2747153921
9548BA1D2C21FA1ACFCB72B2176661B2D7AE7AB1B5D82DC2EB6522D7FBBF3109
438B18309F98DB0F348614AC10739C091B592C3312DB0AE8353C0C6CEFFBC734
C6D4E36A20938E4E0CDCE4C03F524E4BCFA4EBC3C44B0D7F4DFBD7C3FDFC1B67
44D7D6B29787010D9D83DB66EB42DEBD3B3776C99B95F339B66C0593AD3B9567
F4BB3ECDF67B4F2AC63BD5FF7EB297620F1AB3F8734343237AE6A9C13AB95D26
B5DC353D06DDC6DDD22D689F0874F41DAC6B9EA43BFDC8A9A30619AC85A7B17A
22A831268C4CF31834CC6A4311F27004F61A3B125BEA591CC4E2F7DD5ADC33FF
1E228BE256732EBE7FBE83DC734598A2CA7C2A97A9B8E7D149A2DC97733C516E
A9B433DE3EA2DF888940D800A4C206DF09BF4EEC572853E461A2EE8206853924
4C4B83262CFADF333BE383F4D6383358202BA712A038BD1D58F3611572DBA2E8
3B077DCE084F5720AE5A951879AC9ACE9F5FA3524B531D894787B352105BECBD
1937B64489EDDFF8115AEED04D9C115908D86EAD00015FFA7A198A2C8DE2ECA0
82472826E2E0B62EE955047BB097EBC0FF56F120F10EC4C43B28DAC9572FDEC3
843DF9F2E878E49DA6DEE9A6732C39F598BB42DD375BD1FA43D80FEB5F9BAB9A
D78422388F6049F80C62AAF7398FF577A243B3325C5B86A36E2DCE7722D04AC9
AA219EAB06EBEBCD7AF744BA8505C392858547ECF92D2FB72313A7603DD4CB9A
4CB24432763D9300A4

类似的加密文件为:
20200505160828


通过分析,该类病毒是部分加密,可以通过数据库层面处理,恢复大量数据.
20200505181622

对于该类型加密,我们可以对sql server、mysql、oracle恢复出来绝大多数数据,通过不向黑客交赎金的方式,实现绝绝大部分业务数据恢复.

发表在 勒索恢复 | 标签为 , , , , , | 评论关闭