Всем доброго времени суток и здоровьица.
Сложилась неприятная ситуация - основной файл рабочей БД (mdf) погрыз шифровальщик. Полный бекап есть на 01.03.2020, а вот разностного - нету. Но есть актуальный файл журнала транзакций (ldf), его шифровальщик не тронул. я так понимаю в нем сохранены все транзакции. Можно ли его как то использовать с целью восстановления актуальности базы восстановленной из старого бекапа?

Все транзакции в ldf будут только в одном случае. Если модель восстановления для базы была указана "Полная" и бэкапы транзакций после полного бэкапа не делались. Тогда есть варианты.
Но это сомнительно. Вряд ли бы не обратил внимания на постоянно "бухнущий" ldf.

Вообще странно, что шифровальщик добрался до mdf.
Разве что после перезагрузки он успел вцепиться в него раньше сиквела. Ну или сервак стопорили.

(1) именно так и есть, резервное копирование проводилось только для БД (mdf) , ldf разбух до 90гб
(2) именно стопнули сервак. а потом еще и мастер mdf зашифровали, так что тот экземпляр сервака не понимается

так что за варианты? (1)

(3) Процедура нештатная, но встречал на просторах описание. Должно гуглиться.

Там кажись начиналось с поднятия бэкапа, подмены ldf а потом шаманство начиналось :)

Вот, например, вроде что-то в этом духе: https://solutioncenter.apexsql.com/recover-sql-server-database-using-only-a-transaction-log-file-ldf-and-old-backup-files/

А, по ссылке производитель рассказывает, как это можно с помощью их тулзы сделать.
Я вроде и другие гайды находил. В общем, пробуй. Если в самом деле ldf полный, то можно.

Вот тут чувак другую тулзу юзал: https://dba.stackexchange.com/questions/900/how-to-restore-database-using-old-full-backup-and-current-log-file
Но вроде я встречал технику, когда после подмены ldf, несмотря на suspected вроде делали бэкап транзакций из подцепленного ldf и потом его накатывали.

(4) (5) это понятно, сервер для восстановления поставил, бекап старый накатил, начала шаманить c подменой и тут и уперся

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

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


победю-не победю - отпишу)

Вот еще в копилку: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/tail-log-backups-sql-server?redirectedfrom=MSDN&view=sql-server-ver15
Это типа техника снятия бэкапа транзакций с базы, которой нехорошо.
Если получится снять бэкап транзакций из базы с подмененным ldf, то он уже накатывается стандартными средствами sql

Там в перекрестных ссылках еще вот это: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-the-transaction-log-when-the-database-is-damaged-sql-server?view=sql-server-ver15

Прикольная тема. подпишусь. Автору удачи!

(6) пошел по этому пути, сталкиваюсь с разными затыками, типа не подключается прога к ДБ но в целом вроде дошло до последнего шага (восстановления прямов дб)

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

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

другое дело что сейчас делаю на ноутбуке это со стареньким 4ядерным амд а10
надеюсь на новом серваке где буду разворачивать по факту бд пошустрее будет происходить
ну и вообще надеюсь что хоть это то пройдет нормально

(6) метод околорабочий. около потому что прога стоит 2к$,роем дальше

(14) Не благодари
http://forum.ru-board.com/topic.cgi?forum=35&topic=17582#1

+ (15) http://dl.downloadly.ir/Files/Software2/ApexSQL_Log_2018_Professional_Edition_v2018.04.1219_Downloadly.ir.rar

(15) (16)

от души душевно в душу!

(13) В настройках надо копаться. Может, он это все в одной транзакции заливает по дефолту или еще что.
Лично я бы первым делом пробовал вариант с подменой ldf и снятием tail-log backup
Так как если взлетит, то это максимальный по производительности вариант и максимально штатными средствами.

(0) А уже выяснили кто и откуда запустил шифровальщика?

(19) честно говоря нет. вероятнее всего брутнут rdp был, пока занимаюсь попытками восстановить БД (а их 3 штуки)

Вот тут среди мусора есть правильный протокол восстановления: https://www.sql.ru/forum/1237642-2/nestandartnaya-situaciya-mdf-i-ldf
В итоге у чувака получилось снять бэкап транзакций с ldf, но на этапе накатки выяснилось что ldf таки содержал не все транзакции с момента полного бэкапа и адью.

Вот целевой коммент:
"Надо создать такую же базу, или же именно что, восстановить из полного
Затем alter database set offline, подменить лог.
Alter database set online (напишет, что открыть не может и тд)
Теперь backup log with no_truncate"

И после этого штатно накатить полученный бэкап транзакций на базу поднятую из полного бэкапа.

(22) на вышеуказанном ресурсе общаюсь как раз с высказывающимся в в приведенной вами ветке, есть уже скриптик, пробую) выглядит более рационально чем сторонней софтиной

(0) Ну сильно не переживайте если не получится, может есть антидот шифровальщика

(25) 1000$)

(26) Нее) Я про антивирусные компании! Знакомые так расшифровали. Просто купили лицензию Dr.Web и они расшифровали

(0) Просто считаю программист не виноват в том, что сеть плохо настроена, rdp торчит наружу и защита от брутфорса не организована

(27) интересненько, весьма, спасибо за наводку
(28) так я и не программист, просто друг руководства, эникей, даже не админ

а вообще можете посоветовать какие то средства программно-аппаратные для резервного копирования

(29) Встроенных в MSSQL возможностей - за глаза. Мышкой все накликивается в планах обслуживания.

(30) то что в планах накликивается я в курсе)
интересует самоподключающийся HDD что ли

(31) Зачем? Просто сервер бэкапов не должен сверкать голой задницей.

(27) "Нее) Я про антивирусные компании! Знакомые так расшифровали. Просто купили лицензию Dr.Web и они расшифровали "

вашим знакомым просто очень сильно повезло

(33) Тоже так подумал. Для этого нужно, чтобы шифровальщик был "на лоха" и не использовал внешнее хранение ключей, а просто генерил их "по месту" простым алгоритмом. Но, может, сейчас у шифровальщиков так принято...

(34) Да, и еще надо учесть что автора ломанули и руками все сделали, и было бы глупо предполагать что они использовали какой то простой алгоритм шифрования, который уже кому то известен.

(35) Ну вообще хороший троян со стойким криптоалгоритмом стоит больших денег да и доступен не всем! Поэтому большинство троянов уже давно расшифрованные

(35) И с чего решили что ломанули руками?

рапортую: из 3х баз(ЗУП(маленькая), БП(побольше), УТ(большая)) первая восстановилась по маслу, вторая на этапе восстановления выдала это

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

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

буду пробовать третью и надеяться что пойдет по первому сценарию

(38) Так ldf-файл же один?

(39) один на каждую базу, если вы об этом

(38) Значит либо во второй базе была простая модель восстановления (ldf "самоочищался"), либо утерян промежуточный бэкап логов.

На второй базе с помощью утилит типа той же ApexSQL можно попробовать накатить хотя бы те транзакции что остались в логе, но там во-первых может быть слишком мало а во вторых база скорее всего придет в неконсистентное состояния из-за отсутствия части промежуточных данных и придется прогонять ТИИ и еще потом руками выгребать. Стоит ли овчинка выделки - вопрос.

(41) А если установить ограничение на размер ldf не тоже самое будет?

(43) Если установить ограничение на размер ldf будет тоже самое что и при установке ограничения на mdf.

(38) по методу из (22) получилось?

(41) ldf весит 17гб хотя база относительно небольшая...
(42) тоже об этом подумал, что можно. последние 2 недели ничего не резервировало лог точно, то что от туда доливается по идее не должно никуда деться

(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

(46) > ldf весит 17гб хотя база относительно небольшая...
Это не говорит ровным счетом ни о чем. Вырасти он мог во время реструктуризации или каких-то других массовых операций, а обратно он добровольно уже никогда не ужимается.
Реально внутри этих 17гб может быть 99% пустого места.

(48) понятно, приму к сведению

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

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

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