|
|
Информационные технологии
:: Администрирование
|
|
|
| ||
| 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 | |||
| fisher 4 - 19.03.20 - 17:05 | (3) Процедура нештатная, но встречал на просторах описание. Должно гуглиться. | ||
| fisher 5 - 19.03.20 - 17:09 | Там кажись начиналось с поднятия бэкапа, подмены ldf а потом шаманство начиналось :) | ||
| fisher 6 - 19.03.20 - 17:10 | Вот, например, вроде что-то в этом духе: https://solutioncenter.apexsql.com/recover-sql-server-database-using-only-a-transaction-log-file-ldf-and-old-backup-files/ | ||
| 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 | |||
| 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 | |||
| 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 | |||
| 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 | |||
| sirsyslik 46 - 20.03.20 - 16:24 | |||
| 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 или опять же альтернативный софт |
|
|
Список тем форума
|
Рекламное место пустует
Рекламное место пустует
TurboConf — расширение возможностей Конфигуратора 1С
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.