Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Gfer
Member

Откуда:
Сообщений: 30
Доброго всем дня.

Есть база Test с моделью восстановления Full.

Необходимо делать полное резервное копирование 2 раза в месяц.
Инкрементное резервное копирование по рабочим дням.
Резервное копирование transaction log каждый час.

Подскажите, пожалуйста, как это правильно организовать.

Стоит ли делать инкрементное резервное копирование в файл с дозаписью или каждый раз в новый файл.
Тоже же самый вопрос к резервному копированию transaction log.

Как правильно в данной ситуации делать резервное копирование transaction log?

Достаточно ли этих условий для восстановления данных за период в две недели на любой момент времени?

Мой сервер:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
25 янв 10, 18:06    [8242740]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Denis Reznik
Member

Откуда: Киев
Сообщений: 156
Насколько я знаю, инкрементального резрвного копирования данных в SQL Server нет. Есть Differention Backup, но каждый такой бекап, содержит полностью данные предыдущего. Инкрементальным является только бэкап лога. Для восстановления данных на любой момент времени, вам нужен только Полный Бэкап и Бэкап Лога (бэкап лога обязательно). Но чтобы последовательно не накатывать в случае падения базы десятки резервных копий лога, рекомендуется делать дифференциальный бэкап.

Думаю вам бы подошла такая схема:
Full Backup - раз в 2 недели
Differential Backup - раз в 1-3 дня
Log Backup - каждый час
25 янв 10, 22:40    [8243661]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Denis Reznik
Для восстановления данных на любой момент времени, вам нужен только Полный Бэкап и Бэкап Лога (бэкап лога обязательно).
Вообще-то так:
Нужен последний полный бэкап, последний дифференциальный бэкап (если есть, то нужен обязательно) и все бэкапы транзакционного лога с момента последнего полного, либо диыыеренциального бэкапа в зависимости от того, который был последним.
25 янв 10, 23:35    [8243805]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Denis Reznik
Насколько я знаю, инкрементального резрвного копирования данных в SQL Server нет. Есть Differention Backup, но каждый такой бекап, содержит полностью данные предыдущего.


Тут надо уточнить:)
Каждый дифф. бэкап содержит все изменения после последнего полного бэкапа. Т.е. если Вашими словами сказать "содержит полностью данные предыдущего дифф. бэкапа".
26 янв 10, 01:42    [8244048]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
Denis Reznik,

Как вариант, можно просто сваливать бэкапы лога в тот же файл, что и полный бэкап - если не боитесь его повреждения. В теории при ошибке бэкапа файл просто усекается до исходной длины. На практике ни разу не сталкивался с повреждением файла при резервном копировании.
26 янв 10, 08:59    [8244375]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Нектотам
Guest
DeColo®es
Нужен последний полный бэкап, последний дифференциальный бэкап (если есть, то нужен обязательно) и все бэкапы транзакционного лога с момента последнего полного, либо диыыеренциального бэкапа в зависимости от того, который был последним.

Вообще-то это не так. Возможны 2 ситуации:
1. Достаточно наличие любого полного бэкапа (желательно последнего для экономии времени) и все бэкапы логов транзакций от момента полного бэкапа до момента восстановления.
2. Достаточно наличие любого полного бэкапа, любого дифф. бэкапа сделанного после данного полного, но до следующего полного и все бэкапы логов транзакций от момента взятого дифф. бэкапа до момента восстановления.
Понятно, что цепочка бэкапов журналов транзакций должна быть непрерывной (не должно быть, например, смены модели на простую и обратно в течение цепочки). Если бы необходимо было использовать последний полный бэкап, тогда log shipping был бы невозможен.
26 янв 10, 09:17    [8244436]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
petsa
Member

Откуда:
Сообщений: 1708
Sinix
Denis Reznik,
Как вариант, можно просто сваливать бэкапы лога в тот же файл, что и полный бэкап - если не боитесь его повреждения. В теории при ошибке бэкапа файл просто усекается до исходной длины. На практике ни разу не сталкивался с повреждением файла при резервном копировании.

Это плохой вариант, как раз по причине опасности повреждения файла бекапа. Да и если файл не поврежден, через какое-то время он становится большим и не мобильным + проблема с удалением старых бэкапов из этого файла. Рекомендую делать: любой бэкап - отдельный файл с датой и временем в имени, да еще и растащить их по папкам FullBackup, DiffBackup, BackupLog. Порядка будет больше, проблем с удалением старых бэкапов никаких, а когда возникнет задача восстановления - все разложено по полкам.
26 янв 10, 09:18    [8244439]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Gfer
Member

Откуда:
Сообщений: 30
На счет инкрементного копирования ошибся, имел ввиду дифференциальное копирование.

Если я правильно понял, то я делаю

Full Backup и Log Backup актульного состояния - раз в 2 недели
Differential Backup - раз в 1-3 дня в отдельный файл не дописивая, т.к. каждый последующий Backup содержит предыдущий. Каждый день отправляю этот файл в архив.
Остается вопрос, как лучше делать Log Backup:

Делать каждый день в новом файле Differential Backup, в него дозаписывать Log Backup и сохранять этот файл в архиве
или
Делать каждый день в новом файле Differential Backup, каждый день создавать новый файл для Log Backup и дозаписывать в него каждый час, а потом сохранять файл Log Backup в архиве и сохранять в архиве последний Differential Backup.

В первом случае у меня много копий Differential Backup и восстановление на любое время происходит так:
Full Backup - последний Differential Backup за нужный день - последние Log Backup за этот день

Во втором случае у меня последний Differential Backup и много файлов Log Backup за каждый день и восстановление на любое время, кроме последнего дня, происходит так:
Full Backup - цепочка Log Backup до нужного момента.
На последний день:
Full Backup - Differential Backup за этот день - последние Log Backup за этот день

Первый вариант:
+ быстрое восстановление на любой момент времени
- архив занимает много места

Второй вариант:
+ занимает меньше места, т.к. нет дублирующей информации Differential Backup
Здесь вопрос: восстановление занимает на много больше времени, чем в первом варианте?

Поправте, пожалуйста, если я ошибся в выводах.
26 янв 10, 09:36    [8244520]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
petsa

Рекомендую делать: любой бэкап - отдельный файл с датой и временем в имени, да еще и растащить их по папкам FullBackup, DiffBackup, BackupLog. Порядка будет больше, проблем с удалением старых бэкапов никаких, а когда возникнет задача восстановления - все разложено по полкам.


У меня проще - каждую неделю создаётся новая папка (имя = дата), в ней - один bak-файл на каждую базу, в файле - полный бэкап + логи. Бэкап - на локальный винт + зеркалирование на шару. Для полной гарантии WITH CHECKSUM.

Результат - легко найти, легко восстановить. Diff-ы имхо несколько избыточны для мелких баз.
26 янв 10, 10:12    [8244735]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
Gfer,

1) замучаетесь с восстановлением
2) Не забывайте, что _перед_ полным бэкапом стоит сделать log backup - чтобы не было граблей с накатом до момента между бэкапом лога и последующим полным бэкапом.
26 янв 10, 10:16    [8244749]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Нектотам
Guest
Sinix
2) Не забывайте, что _перед_ полным бэкапом стоит сделать log backup - чтобы не было граблей с накатом до момента между бэкапом лога и последующим полным бэкапом.

Это занафига? Что мешает восстановить рез. копию журналов транзакций (на базу в состоянии norecovery с LSN по состоянию, например, на на первый LSN восстанавливаемой копии) в том случае если меджу копиями журнала транзакций делалась полная рез. копия
26 янв 10, 10:31    [8244859]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Glory
Member

Откуда:
Сообщений: 104751
Sinix

2) Не забывайте, что _перед_ полным бэкапом стоит сделать log backup - чтобы не было граблей с накатом до момента между бэкапом лога и последующим полным бэкапом.

Полный бэкап не прерывает цепочку бэкапов лога
26 янв 10, 10:40    [8244930]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Нектотам
Guest
Gfer,

Основные критерии того, как организовать резервное копирование:
1. Объём БД
2. Средний объём записи в журналы транзакций в сутки
3. Для принятия решения о необходимости дифф. бэкапов - соотношение количества изменяемых в сутки страниц к среднему объёму записи в ЖТ в сутки
4. Допустимое время потери информации (если такого нет, то велкам в мирроринг)
5. Допустимое время простоя (если такого нет, то велкам в кластеринг)
6. Назначение бэкапов (например, только как рез. копии или для развёртывания тестовых баз)
7. Необходимое время хранения резервных копий (возможно, до того как они переносятся в "совсем архив")
8. Объём носителя для резервных копий и его скорость.
9. Наличие/отсутствие выделенного времени низкой активности для создания копий.
10. Для больших БД (ТБ и более) есть много нюансов, зачастую начиная с невозможности создания полного бэкапа БД.
Есть еще много других параметров, но, пожалуй, это основные. Учтите, что по-большому счету резервное копирование - последний рубеж обороны целостности системы. Т.е. если в надёжной системе восстановление рез. копии для восстановления функционирования системы - это провал, потому что это значит, что поломался отказоустойчивый кластер и отказали системы лог шиппинга/мирроринга.
По поводу дифф. бэкапов. Моё личное мнение, что для большинства негигантских OLTP систем дифф. бэкап - излишество. Время его создания и нагрузка на основную БД в это время обычно сопоставимы с полным бэкапом. Размер (для OLTP в которых инфа в основном добавляется, но не удаляется) линейно сопоставим с размером рез. копий журнала транзакций от момента полного бэкапа. При восстановлении смысл дифф. бэкапа - возможность пропустить несколько бэкпов журналов транзакций при восстановлении БД, но если время восстановления настолько критично, то дешевле держать "тёплые" резервные сервера или кластер. Хотя в некоторых случаях дифф. бэкап может быть нужен, если на носителе рез. копий не очень много места
Пример с расчетом: пусть есть БД 100 ГБ, каждый день генерится логов 2 ГБ, БД работает 5 дней в неделю, ночью малоактивна, каждый день БД увеличивается примерно на 0.5 ГБ. Для бэкапа используется носитель объёмом 2 ГБ, данные храним 2-3 месяца. Рассмотрим модели:
1. Полный - раз в 4 недели в выходные, дифф - раз в неделю в выходные (кроме выходных с полным бэкапом) и бэкап лога раз в час.
2. Полный - раз в 4 недели в выходные и бэкап лога раз в час.
3. Полный - раз в неделю в выходные и бэкап лога раз в час.

Оценим некоторые параметры систем:
Время повышенной загрузки БД. Скорости создания и восстановления БД обычно "достаточно постоянны", чтобы можно было их оценивать. На типичной (несуперской) системе, если нет нагрузки на БД, это могут быть такие:
- скорость бэкапа полного (и дифф) - 70 МБ/сек (от размера БД)
- скорость бэкапа лога транзакций - 40 МБ/сек
- скорость восстановления полного и дифф - 30 МБ/сек (от размера копии!)
- скорость восстановления лога транзакций - 3 МБ/мек
Исходя из этого видно, что оценки за четыре недели будут следующими
1. Полный и дифф бэкапы занимают по 25 минут раз в неделю - итого 100 минут за 4 недели. Суммарное время записи логов транзакций (при пятидневке) за 4 недели 5 дней * 2 ГБ * 4 недели = 40ГБ - около 20 минут.
2. Время создания полного бэкапа - 25 мин, логов - 20 мин.
3. Время создания полных бэкапов - 100 мин, логов - 20 мин.
Видно, что дифф. бэкапы не дают выигрыша.
Время восстановления в худшем случае
Худший случай - восстановление за час до полного бэкапа.
Нам понадобится оценка размера дифф. бэкапа. В худшем случае это примерно объём всех логов транзакций (т.е. +10 ГБ в неделю), в лучшем - прирост БД (+2.5 ГБ в неделю). Для определённости возьмём примерно +8 ГБ в неделю.
1. Восстановили полный бэкап (примерно час), дифф. бэкап за 3-ю неделю (25 ГБ) - примерно 20 минут, логи за неделю - 10 ГБ (примерно час) - Итого примерно 2:20
2. Полный лог - 1 час, логи 4 недель - 4 часа. Итого - 5 часов.
3. Полный лог - 1 час, логи за неделю - 1 час. Итого 2 часа.
Объём бэкапов за 4 недели
1. 100 ГБ + 8 ГБ + 16 ГБ + 24 ГБ + 40 ГБ = 188 ГБ
2. 100 ГБ + 40 ГБ = 140 ГБ
3. 400 ГБ + 40 ГБ = 440 ГБ

В принципе, из этих выкладок очевидно, что дифф бэкапы экономят либо 2,5 часа при восстановлении (в сравнении моделей 1 и 2) или 150 ГБ места для бэкапов в месяц (в сравнении моделей 1 и 3). Если в системе ужас-как-критичны 2,5 часа на восстановление, то проще держать рядом "тёпленький" сервер. А если денег не хватает на 150 ГБ дисков в месяц, то вряд ли так критично время восстановления. Лично я в большинстве подобных случаев выбрал бы вариант 3, причём для простоты все рез. копии валились бы в отдельные файлы (как это по умолчанию и делается в Maintenance Plan)
26 янв 10, 11:07    [8245112]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
Glory,

Ок, допустим у нас полный бэкап раз в 12 часов, бэкап лога - каждый час.
Если нам надо восстановиться на 10:30 - поднимаем полуночный, накатываем 11 бэкапов лога.
На 11:30 - поднимаем полуденный full и откатываем назад, используя полуденный лог. Слегка неинтуитивно, не находите?
26 янв 10, 11:12    [8245157]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Glory
Member

Откуда:
Сообщений: 104751
Sinix
Glory,

Ок, допустим у нас полный бэкап раз в 12 часов, бэкап лога - каждый час.
Если нам надо восстановиться на 10:30 - поднимаем полуночный, накатываем 11 бэкапов лога.
На 11:30 - поднимаем полуденный full и откатываем назад, используя полуденный лог. Слегка неинтуитивно, не находите?

Я что-то не понял " откатываем назад, используя полуденный лог" - это вы про команду RESTORE LOG ?
26 янв 10, 11:18    [8245213]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Spartakich
Member

Откуда: Riga
Сообщений: 380
Sinix,

На 11:30 поднимаем полуночный, накатываем 11 + 1 (with STOPAT) бэкапов лога
26 янв 10, 11:24    [8245255]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
Glory,

Тьху блин! В памяти отложилось:
http://msdn.microsoft.com/en-us/library/ms189596.aspx
To apply a transaction log backup, the following requirements must be met:
The immediately previous full database backup or differential database backup must be restored first.


Если как пример использовать
8:00	Back up database to create a full database backup.
12:00	Back up transaction log.
16:00	Back up transaction log.
18:00	Back up database to create a full database backup.
20:00	Back up transaction log.
21:45	Failure occurs.

Выходит, я гоню и восстановиться на состояние 19:00 можно, только востановив FULL на 8:00 и последовательно накатив 3 бэкапа лога.

Мои извинения.
26 янв 10, 11:39    [8245369]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Spartakich
Member

Откуда: Riga
Сообщений: 380
Sinix,

на 19:00:
восстанавливаешь полный бекап на 18:00 (no recovery) и потом лог на 20:00 с опцией (STOPAT 19:00)
26 янв 10, 12:19    [8245710]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Sinix
Member

Откуда:
Сообщений: 170
Spartakich,
Блин!
На 17:00 конечно же.
26 янв 10, 12:53    [8245994]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
Gfer
Member

Откуда:
Сообщений: 30
Нектотам,

Спасибо за очень подробное рассмотрение вопроса. Все доступно и понятно. Буду тестировать предложенные варианты в своих условиях.
26 янв 10, 16:34    [8248321]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
nikopol
Member

Откуда:
Сообщений: 335
Хочу уточнить:
При наличии полного бекапа для востановления нам требуются все бекапы транзакт лога сделанные ПОСЛЕ полного бекапа.
Т.е. все бекапы транзакт лога сделанные ДО полного бекапа базы нам абсолютно не нужны? Их можно смело удалять?
Если фулл бекап делается 1 раз в день(ночью, с базой никто не работает), то все бекапы лога за предыдущий день удаляем, т.к. толку от них никакого теперь?
Я брошу все и войду в твое положение
9 мар 10, 09:35    [8447148]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
nikopol
Если фулл бекап делается 1 раз в день(ночью, с базой никто не работает), то все бекапы лога за предыдущий день удаляем, т.к. толку от них никакого теперь?
Я брошу все и войду в твое положение
Если вам не потребуется восстановление до момента времени выполнения последнего полного бэкапа, то да - можно удалить, при уверенности, что последний полный и последующие лога целы.
9 мар 10, 09:38    [8447175]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
nikopol
Member

Откуда:
Сообщений: 335
tpg
Если вам не потребуется восстановление до момента времени выполнения последнего полного бэкапа, то да - можно удалить, при уверенности, что последний полный и последующие лога целы.

Ага, ясно.
И такой еще вопросик :) Можно ли одновременно делать фулл бекап и бекап лога(т.е. сделать то можно, но не помешает ли это потом)? или лучше чтобы время не совпадало?
9 мар 10, 10:13    [8447412]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
nikopol
Можно ли одновременно делать фулл бекап и бекап лога(т.е. сделать то можно, но не помешает ли это потом)?...
... а главное - зачем?
9 мар 10, 10:21    [8447483]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по резевному копированию БД с моделью восстановления Full  [new]
nikopol
Member

Откуда:
Сообщений: 335
tpg,
:) просто когда-то настраивались джобы и не особо смотрели на даты и время выполнения, поэтому получилось, что раз в сутки совпадает старт джоба на полный бекап и бекап лога.
стоит ли разнести их во времени?
9 мар 10, 10:32    [8447571]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить