Восстановление БД SQL #810600

Добрый день! Вопрос срочный, просьба по существу. Надо восстановить сиквел базу на определенный момент времени. Модель восстановления "Полная", но с дури перед процедурой создал еще резервную копию, на всякий пожарный. Теперь доступный момент времени дата последнего бэкапа (((( Вопрос: есть шансы откатиться на день ??? Спасибо!

Всмысле резервная копия не дополняется, а затирается?

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

и че ? До того как были бэкапы базы и логов настроены ?

системные администраторы делятся на три типа: тех, кто не делает бэкапы; тех, кто уже делает бэкапы и тех, кто делает и проверяет, что бэкапы рабочие. Я думаю что шансов нет, на сколько понято из твоего объяснения ты перезаписал бэкап и теперь у тебя бэкап с косяками от которых ты бы хотел откатится!?

Есть полный бэкап недельной давности

Так LDF файл - 22 гига, до текущего момента считал, что журнал транзакций есть и можно восстановить на любую дату, получается фиг там?

При указании нужной даты и времени, че там у тебя ?

скуль то хоть какой версии ?

SQL Server 2012 .. Есть полные бекапы созданные вручную: Надо откатиться в интервале 18.12.(~20:00) - 19.12 (~08:00) Дает восстановить "Последняя созданная резервная копия (19 декабря 2017 г. 17:23:17)" или (12 декабря 2017 г. 11:19:18)

с такой точностью бэкап транзакций нужен вроде. Есть?

Нет ((

А бэкап транзакций как то получить из LDF файла можно ?

Не знаю, но очень сомневаюсь - либо через лютые танцы с бубном

Мда ужжж ... Может есть еще варианты ?

их нет. Полный бэкап это и бэкап журнала транзакций и не раз в день а раз в час. ну зато на будущее наука)))

Ты журнал транзакций обрезал ? Если нет, можешь восстановить на любую дату и время

Смотреть тут: Бэкап лога транзакций + 30 сообщение.

+ делайте все на копии

делайте копии

делайте копии всего

и всегда

а это не ты?

Да, похоже мой вариант, только у меня нет бэкапа логов транзакций (*.trn) (( Для меня все таки открытым вопрос остался, если выполнил полный бэкап, то журнал транзакций же не обрезаешь? Ёпрст, как можно восстановить на любую дату ?? Ну и действительно наука, я считал что можно восстановить базу по двум файлам MDF и LDF файлам на любое время ... причем LDF не сжимался при полном бэкапе, это меня и вело в заблуждение. Ну и насчет делать копии всегда и всего, как раз если бы не сделал полную копию перед всеми процедурами, то смог бы восстановиться на прошлый день в 22:00 ((

При выполнении полного бэкапа журнал транзакций не чистится. Скорее всего можно восстановить: 1. Сделать бэкап лога. 2. Восстановить бэкап недельной давности без отката незавершенных транзакций. 3. Восстановить поверх бэкап лога, при этом установить нужный момент времени. Сначала делать в копию, а не затирать имеющуюся базу.

Делаю: 1. Восстановил базу [BUH_RESTORE] из копии sql_buh_2017-12-19.bak 2. Сделал резервную копию журнала транзакций sql_buh.trn (что то он совсем маленький получился) 3. Восстановил базу [BUH_RESTORE] из копии sql_buh_2017-12-12.bak без отката незавершенных транзакций. 4. Пытаюсь восстановить "Журнал транзакций", выбираю файл sql_buh.trn, выбираю "На момент времени: 19.12.2017 00:00:00" Ошибка: "Журнал в этом резервном наборе данных начинается с номера LSN 3236000028355300001, который еще не может применяться к базе данных. Может быть восстановлена более ранняя резервная копия журналов, включающая номер LSN"

При любом бэкапе базы данных данных журнал транзакций в него не включается. Сделай бэкап журнала с рабочей базы. Вот это ещё прочитай В общем виде порядок восстановления следующий: Полный бэкап Разностный 1 Разностный 2 Разностный ... Бэкап журнала транзакций.

Неточность. В разностный входит всё от последнего полного. Т.е. восстанавливать только один из разностных надо, последний.

? разностная резервная копия Резервная копия данных, основанная на последней полной или частичной резервной копии базы данных или набора файлов данных или файловых групп (базовой копии для разностного копирования), которая содержит только данные, измененные по сравнению с базовой копией для разностного копирования.

Обратимся к первоисточникам: A backup containing only changes made to the database since the preceding data backup on which the differential backup is based. DIFFERENTIAL Used only with BACKUP DATABASE, specifies that the database or file backup should consist only of the portions of the database or file changed since the last full backup. A differential backup usually takes up less space than a full backup. Use this option so that all individual log backups performed since the last full backup do not have to be applied. Вот оно: *changed since the last full backup*

Ну и на русском тоже расписывают: Разностная резервная копия, создаваемая вскоре после своей основы, занимает значительно меньше места, чем базовая копия для разностного копирования. Это позволяет сэкономить место в хранилище и уменьшить время копирования. Однако с течением времени по мере изменения базы данных различие между базой данных и базовой копией для разностного копирования увеличивается. Чем больше промежуток времени между созданием основы для разностной копии и разностной резервной копией, тем больше места, скорее всего, будет занимать разностная резервная копия. Это означает, что в конце концов разностная резервная копия приблизится по размеру к своей базовой копии для разностного копирования. Разностная резервная копия большого размера теряет все свои преимущества: быстроту работы и малый объем. Поскольку разностные резервные копии увеличиваются в размере, восстановление разностной резервной копии может значительно увеличить время, которое необходимо для восстановления базы данных. Поэтому рекомендуется через некоторое время выполнить создание новой полной резервной копии, чтобы получить новую базовую копию для разностного копирования. Например, можно выполнять полное резервное копирование всей базы данных один раз в неделю, а затем в течение недели регулярно создавать разностные резервные копии. Прежде чем начать восстановление из разностной резервной копии, необходимо восстановить основу. Затем восстанавливается только самая последняя разностная копия, чтобы привести базу данных ко времени создания разностной резервной копии. Обычно восстанавливается последняя полная резервная копия, а затем последняя разностная резервная копия, которая на ней основана.

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

Сорри, не проснумшийся был. С восстановлением архивов логов напутал.