Управление наборами резервных копий SQL

Я бы сказал, что ликвидирую разрыв между новичком и промежуточным пользователем в SQL Server. Я учился через поиск в Google, но не могу найти ничего достойного, связанного с этим вопросом.

У меня есть БД, которая претерпела множество изменений, и каждое изменение добавляло полный набор резервных копий и некоторый размер в мой файл резервной копии. Я считаю это обузой, поскольку я почти уверен, что мне не нужны старые наборы резервных копий, но я хотел бы сохранить их на всякий случай.

Может ли кто-нибудь указать мне на хороший учебник или лучшие практики по хранению резервных копий SQL или просто дать хороший совет?


person John the Ripper    schedule 08.09.2011    source источник


Ответы (2)


На время, когда ваше приложение будет использоваться и иметь реальные данные в базе данных, вам необходимо делать «настоящие» резервные копии, как dougajmcdonald уже объяснил в его ответ.

Однако, пока ваш проект все еще находится на стадии разработки, вы делаете резервные копии в основном потому, что хотите отслеживать такие вещи, как изменения определения таблиц, верно?

Если да, как насчет сохранения ваших изменений в виде сценариев T-SQL в системе управления версиями вместе с вашим фактическим кодом, который обращается к базе данных?

Существуют инструменты, которые генерируют CREATE TABLE скрипты и тому подобное для существующей базы данных.
Вот несколько ссылок на связанные вопросы SO:

(выполните поиск по запросу "sql server source control", если хотите найти больше)

Существуют также проекты с открытым исходным кодом, такие как FluentMigrator, которые помогают отслеживать изменения базы данных в исходном коде (.net в в этом случае, но есть аналогичные инструменты для других языков).
Вот руководство от первого автора Fluent Migrator, в котором объясняется, что такое Fluent Migrator, зачем он вам может понадобиться и как он работает.

person Christian Specht    schedule 08.09.2011

Обычно вы делаете резервную копию каждую (час / день / неделю) в зависимости от необходимости и перезаписываете каждую предыдущую резервную копию.

Затем вы заархивируете эти отдельные файлы, возможно, на магнитную ленту, вне офиса, на другой сервер и т. Д., И выберите, сколько вы хотите сохранить, исходя из деловых / юридических потребностей.

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

person dougajmcdonald    schedule 08.09.2011
comment
Это все еще применимо, если я все еще в разработке и у меня нет реальных данных? Например, я протестирую свое приложение, введя ложные данные, а затем буду восстанавливать несколько раз каждую неделю. - person John the Ripper; 08.09.2011
comment
Если вы в разработке, я бы все равно использовал аналогичный метод, но не так часто. Я бы хотел убедиться, что изменения в БД написаны сценариями, чтобы их можно было отменить / откатить в любом случае, эти сценарии также могут управляться источником - person dougajmcdonald; 08.09.2011