Вход | Регистрация
 
Информационные технологии :: Администрирование

Вопрос по MS SQL базе: как восстановить если поврежден mdf файл?

Вопрос по MS SQL базе: как восстановить если поврежден mdf файл?
Я
   sirsyslik
 
19.03.20 - 15:57
Всем доброго времени суток и здоровьица.
Сложилась неприятная ситуация - основной файл рабочей БД (mdf) погрыз шифровальщик. Полный бекап есть на 01.03.2020, а вот разностного - нету. Но есть актуальный файл журнала транзакций (ldf), его шифровальщик не тронул. я так понимаю в нем сохранены все транзакции. Можно ли его как то использовать с целью восстановления актуальности базы восстановленной из старого бекапа?
   fisher
 
1 - 19.03.20 - 16:18
Все транзакции в ldf будут только в одном случае. Если модель восстановления для базы была указана "Полная" и бэкапы транзакций после полного бэкапа не делались. Тогда есть варианты.
Но это сомнительно. Вряд ли бы не обратил внимания на постоянно "бухнущий" ldf.
   fisher
 
2 - 19.03.20 - 16:24
Вообще странно, что шифровальщик добрался до mdf.
Разве что после перезагрузки он успел вцепиться в него раньше сиквела. Ну или сервак стопорили.
   sirsyslik
 
3 - 19.03.20 - 17:01
(1) именно так и есть, резервное копирование проводилось только для БД (mdf) , ldf разбух до 90гб
(2) именно стопнули сервак. а потом еще и мастер mdf зашифровали, так что тот экземпляр сервака не понимается

так что за варианты? (1)
   fisher
 
4 - 19.03.20 - 17:05
(3) Процедура нештатная, но встречал на просторах описание. Должно гуглиться.
   fisher
 
5 - 19.03.20 - 17:09
Там кажись начиналось с поднятия бэкапа, подмены ldf а потом шаманство начиналось :)
   fisher
 
6 - 19.03.20 - 17:10
   fisher
 
7 - 19.03.20 - 17:12
А, по ссылке производитель рассказывает, как это можно с помощью их тулзы сделать.
Я вроде и другие гайды находил. В общем, пробуй. Если в самом деле ldf полный, то можно.
   fisher
 
8 - 19.03.20 - 17:17
Вот тут чувак другую тулзу юзал: https://dba.stackexchange.com/questions/900/how-to-restore-database-using-old-full-backup-and-current-log-file
Но вроде я встречал технику, когда после подмены ldf, несмотря на suspected вроде делали бэкап транзакций из подцепленного ldf и потом его накатывали.
   sirsyslik
 
9 - 19.03.20 - 17:35
(4) (5) это понятно, сервер для восстановления поставил, бекап старый накатил, начала шаманить c подменой и тут и уперся

(6) а вот за это спасибо (8) и за это

буду бороться


победю-не победю - отпишу)
   fisher
 
10 - 19.03.20 - 17:58
Вот еще в копилку: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/tail-log-backups-sql-server?redirectedfrom=MSDN&view=sql-server-ver15
Это типа техника снятия бэкапа транзакций с базы, которой нехорошо.
Если получится снять бэкап транзакций из базы с подмененным ldf, то он уже накатывается стандартными средствами sql
   fisher
 
11 - 19.03.20 - 18:01
   Kuzmich123
 
12 - 19.03.20 - 18:10
Прикольная тема. подпишусь. Автору удачи!
   sirsyslik
 
13 - 19.03.20 - 22:47
(6) пошел по этому пути, сталкиваюсь с разными затыками, типа не подключается прога к ДБ но в целом вроде дошло до последнего шага (восстановления прямов дб)

он жрет почти весь проц и не трогает диск а это как то смущает

тестирую на маленькой базе сначала
если ставлю временные  рамки до суток - производит достаточно быстро
поставил 5 суток и он начал оооочень медленно это делать
а требуется 16 суток на огромной и значительно более нагруженной базе восстановить

другое дело что сейчас делаю на ноутбуке это со стареньким 4ядерным амд а10
надеюсь на новом серваке где буду разворачивать по факту бд пошустрее будет происходить
ну и вообще надеюсь что хоть это то пройдет нормально
   sirsyslik
 
14 - 20.03.20 - 10:14
(6) метод околорабочий. около потому что прога стоит 2к$,роем дальше
   arsik
 
15 - 20.03.20 - 10:19
   arsik
 
16 - 20.03.20 - 10:21
   sirsyslik
 
17 - 20.03.20 - 10:26
(15) (16)

от души душевно в душу!
   fisher
 
18 - 20.03.20 - 10:27
(13) В настройках надо копаться. Может, он это все в одной транзакции заливает по дефолту или еще что.
Лично я бы первым делом пробовал вариант с подменой ldf и снятием tail-log backup
Так как если взлетит, то это максимальный по производительности вариант и максимально штатными средствами.
   Yrii-ay
 
19 - 20.03.20 - 10:31
(0) А уже выяснили кто и откуда запустил шифровальщика?
   sirsyslik
 
20 - 20.03.20 - 10:36
(19) честно говоря нет. вероятнее всего брутнут rdp был, пока занимаюсь попытками восстановить БД (а их 3 штуки)
   fisher
 
21 - 20.03.20 - 10:36
Вот тут среди мусора есть правильный протокол восстановления: https://www.sql.ru/forum/1237642-2/nestandartnaya-situaciya-mdf-i-ldf
В итоге у чувака получилось снять бэкап транзакций с ldf, но на этапе накатки выяснилось что ldf таки содержал не все транзакции с момента полного бэкапа и адью.
   fisher
 
22 - 20.03.20 - 10:47
Вот целевой коммент:
"Надо создать такую же базу, или же именно что, восстановить из полного
Затем alter database set offline, подменить лог.
Alter database set online (напишет, что открыть не может и тд)
Теперь backup log with no_truncate"
   fisher
 
23 - 20.03.20 - 10:48
И после этого штатно накатить полученный бэкап транзакций на базу поднятую из полного бэкапа.
   sirsyslik
 
24 - 20.03.20 - 10:58
(22) на вышеуказанном ресурсе общаюсь как раз с высказывающимся в в приведенной вами ветке, есть уже скриптик, пробую) выглядит более рационально чем сторонней софтиной
   Yrii-ay
 
25 - 20.03.20 - 11:02
(0) Ну сильно не переживайте если не получится, может есть антидот шифровальщика
   sirsyslik
 
26 - 20.03.20 - 11:06
(25) 1000$)
   Yrii-ay
 
27 - 20.03.20 - 11:09
(26) Нее) Я про антивирусные компании! Знакомые так расшифровали. Просто купили лицензию Dr.Web и они расшифровали
   Yrii-ay
 
28 - 20.03.20 - 11:22
(0) Просто считаю программист не виноват в том, что сеть плохо настроена, rdp торчит наружу и защита от брутфорса не организована
   sirsyslik
 
29 - 20.03.20 - 11:36
(27) интересненько, весьма, спасибо за наводку
(28) так я и не программист, просто друг руководства, эникей, даже не админ

а вообще можете посоветовать какие то средства программно-аппаратные для резервного копирования
   fisher
 
30 - 20.03.20 - 11:56
(29) Встроенных в MSSQL возможностей - за глаза. Мышкой все накликивается в планах обслуживания.
 
 Рекламное место пустует
   sirsyslik
 
31 - 20.03.20 - 13:39
(30) то что в планах накликивается я в курсе)
интересует самоподключающийся HDD что ли
   fisher
 
32 - 20.03.20 - 13:47
(31) Зачем? Просто сервер бэкапов не должен сверкать голой задницей.
   Изучаю1С8
 
33 - 20.03.20 - 13:49
(27) "Нее) Я про антивирусные компании! Знакомые так расшифровали. Просто купили лицензию Dr.Web и они расшифровали "

вашим знакомым просто очень сильно повезло
   fisher
 
34 - 20.03.20 - 13:53
(33) Тоже так подумал. Для этого нужно, чтобы шифровальщик был "на лоха" и не использовал внешнее хранение ключей, а просто генерил их "по месту" простым алгоритмом. Но, может, сейчас у шифровальщиков так принято...
   Изучаю1С8
 
35 - 20.03.20 - 13:56
(34) Да, и еще надо учесть что автора ломанули и руками все сделали, и было бы глупо предполагать что они использовали какой то простой алгоритм шифрования, который уже кому то известен.
   Yrii-ay
 
36 - 20.03.20 - 14:25
(35) Ну вообще хороший троян со стойким криптоалгоритмом стоит больших денег да и доступен не всем! Поэтому большинство троянов уже давно расшифрованные
   Yrii-ay
 
37 - 20.03.20 - 14:27
(35) И с чего решили что ломанули руками?
   sirsyslik
 
38 - 20.03.20 - 14:28
рапортую: из 3х баз(ЗУП(маленькая), БП(побольше), УТ(большая)) первая восстановилась по маслу, вторая на этапе восстановления выдала это

Сообщение 4305, уровень 16, состояние 1, строка 2
Журнал в этом резервном наборе данных начинается с номера LSN 2095000002781600001, который еще не может применяться к базе данных. Может быть восстановлена более ранняя резервная копия журналов, включающая номер LSN 2014000004067400001.

Сообщение 3013, уровень 16, состояние 1, строка 2
RESTORE LOG прервано с ошибкой.

буду пробовать третью и надеяться что пойдет по первому сценарию
   Yrii-ay
 
39 - 20.03.20 - 14:58
(38) Так ldf-файл же один?
   sirsyslik
 
40 - 20.03.20 - 15:11
(39) один на каждую базу, если вы об этом
   fisher
 
41 - 20.03.20 - 15:24
(38) Значит либо во второй базе была простая модель восстановления (ldf "самоочищался"), либо утерян промежуточный бэкап логов.
   fisher
 
42 - 20.03.20 - 15:27
На второй базе с помощью утилит типа той же ApexSQL можно попробовать накатить хотя бы те транзакции что остались в логе, но там во-первых может быть слишком мало а во вторых база скорее всего придет в неконсистентное состояния из-за отсутствия части промежуточных данных и придется прогонять ТИИ и еще потом руками выгребать. Стоит ли овчинка выделки - вопрос.
   arsik
 
43 - 20.03.20 - 15:31
(41) А если установить ограничение на размер ldf не тоже самое будет?
   fisher
 
44 - 20.03.20 - 15:50
(43) Если установить ограничение на размер ldf будет тоже самое что и при установке ограничения на mdf.
   ptiz
 
45 - 20.03.20 - 16:01
(38) по методу из (22) получилось?
   sirsyslik
 
46 - 20.03.20 - 16:24
(41) ldf весит 17гб хотя база относительно небольшая...
(42) тоже об этом подумал, что можно. последние 2 недели ничего не резервировало лог точно, то что от туда доливается по идее не должно никуда деться
   sirsyslik
 
47 - 20.03.20 - 16:26
(45) да, вот так

-- Переводим ее в оффлайн и подменяем файл ЖТ на сохраненный исходный
alter database Test001 set offline;
exec xp_cmdshell 'copy /b /y C:\Windows\TEMP\Test001_log.ldfcopy C:\Windows\TEMP\Test001_log.ldf';
go

-- Попытка перевести БД в онлайн, котороя закончится неудачей
alter database Test001 set online;
go

-- Делаем tail-бекап ЖТ, БД будет переведена в состояние restoring
backup log Test001 to disk = 'C:\Windows\TEMP\Test001_Log.trn' with init, norecovery, no_truncate;
go

-- Восстанавливаем БД
restore database Test001 from disk = 'C:\Windows\TEMP\Test001_full.bak' with replace, norecovery;
restore log Test001 from disk = 'C:\Windows\TEMP\Test001_Log.trn' with recovery;
go
   fisher
 
48 - 20.03.20 - 16:48
(46) > ldf весит 17гб хотя база относительно небольшая...
Это не говорит ровным счетом ни о чем. Вырасти он мог во время реструктуризации или каких-то других массовых операций, а обратно он добровольно уже никогда не ужимается.
Реально внутри этих 17гб может быть 99% пустого места.
   sirsyslik
 
49 - 20.03.20 - 17:01
(48) понятно, приму к сведению

3я база (УТ) (которая самая большая и нужная) избежала проблемы второй. с журналами там все ок.
там другая проблема

Сообщение 3182, уровень 16, состояние 2, строка 1
Невозможно восстановить резервный набор данных, так как база данных была повреждена в момент создания резервной копии. Можно попытаться выполнить восстановление с помощью WITH CONTINUE_AFTER_ERROR.
Сообщение 3013, уровень 16, состояние 1, строка 1
RESTORE LOG прервано с ошибкой

видимо придется пробовать с with continue after error или опять же альтернативный софт


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.