У нас нет администратора базы данных, и мне приходится делать резервные копии. У нас есть только одна база данных размером 3 ГБ (остальные менее 100 МБ). База данных размером 3 ГБ требует большого количества операций записи и содержит очень важные данные. Я настроил ежедневное резервное копирование всех баз данных, но думаю, что этого может быть недостаточно.
Хорошо, вам действительно нужно перейти к документации и прочитать ее - станьте маленьким dba. Ожидать, что люди здесь скопируют / вставят ЧРЕЗВЫЧАЙНО подробную информацию из BOOKS ONLINE - документации SQL Server - это плохое поведение. Тем не менее, вы тоже не на том сайте - это абсолютно НЕ проблема программирования. Существует дочерний сайт (serverfault.com) по вопросам работы сервера, которому принадлежат резервные копии.
Для начала:
Журнал транзакций записывает все изменения, внесенные в базу данных. Это означает, что вы делаете полную резервную копию, а затем журнал tx может использоваться для отката ее до ПОСЛЕДНЕЙ ТРАНЗАКЦИИ, КОПИЙНОЙ В ЖУРНАЛЕ. Означает, что если вы сделаете резервную копию журнала tx через 16 часов, сервер выйдет из строя, на новом сервере вы восстановите ежедневную резервную копию, затем обработаете журнал транзакций и вернетесь к последней совершенной транзакции через 16 часов;) Если вы спросите я - бизнес, которым не занимаются, заслуживает того ущерба, который они получают от этого.
Журнал транзакций - это ОГРОМНОЕ преимущество, которое у вас есть в чем-то вроде SQL Server по сравнению с классическим резервным копированием на уровне файлов.
На все остальные вопросы ответить не могу. Шутки в сторону. Это не решения на уровне DBA, это бизнес-решения. Я знаю компании, которые делают резервные копии журналов транзакций каждые 5 минут, отправляя их на отдельный сервер (проверьте: Доставка файлов журнала). Причина: потеря данных была бы катастрофой. Представьте, что Amazon теряет все продажи на полдня. Я знаю, что другие предприятия делают ежедневное, а иногда и еженедельное резервное копирование (небольшой магазин, сайт во внутренней сети). Я знаю других, которые не полагаются на резервные копии в случае аварийных ситуаций, но используют репликацию и / или зеркалирование, с ежедневным полным резервным копированием и ежечасным резервным копированием журналов, так что если сервер умирает, у них не будет простоев. Все это «одно и то же» с технической точки зрения - каждая рекомендация зависит от бизнес-кейса, о котором вы ничего не говорите.
В качестве нормального сценария я бы предложил регулярное полное резервное копирование (еженедельно, в нерабочее время, например, воскресенье), ежедневное дифференциальное резервное копирование (намного меньше, чем полное), а затем резервное копирование журнала каждые x часов (1, 6, 12 - в зависимости от вашего бизнес-кейс).
Остальные дали вам базовый обзор. Я собираюсь дать вам несколько общих ответов на ваши вопросы, но учтите, что фактические ответы будут зависеть от потребностей вашего бизнеса.
Резервные копии журнала транзакций создают резервную копию журнала транзакций. В этот журнал записываются все транзакции, выполняемые в базе данных. Когда база данных находится в режиме простого восстановления, этот журнал очищается после каждой контрольной точки в базе данных. Когда база данных находится в полном режиме, эти журналы продолжают заполняться транзакциями до тех пор, пока не будет выполнено резервное копирование или усечение вручную. Создавая резервную копию журналов транзакций, вы можете использовать их в сочетании с «обычными» резервными копиями базы данных для отката до недавно выполненных транзакций при восстановлении базы данных.
На этот вопрос нет однозначного ответа, но в целом я стараюсь делать еженедельное полное резервное копирование в сочетании с ежедневным дифференциальным резервным копированием.
Резервные копии журналов будут выполняться с помощью созданного вами плана обслуживания SQL. Вы выполняете эти резервные копии, чтобы очистить журнал транзакций и записывать транзакции на случай, если вам потребуется их восстановить. Обратите внимание, что если вы не собираетесь использовать резервное копирование журнала транзакций, вам следует изменить свою базу данных в режим простого восстановления, чтобы избежать проблем, которые будут полны журналов или полных дисков, поскольку транзакции не будут автоматически очищаться из журнала в режиме полного восстановления .
Вы можете выполнять резервное копирование журналов с любой частотой, необходимой для вашего приложения. Например, если недопустимо когда-либо терять более 5 минут транзакций, вы должны выполнять резервное копирование журнала каждые пять минут в сочетании с обычным полным и дифференциальным резервным копированием базы данных.
Это полностью зависит от ваших потребностей. Мой стандарт - это еженедельное полное и ежедневное дифференциальное резервное копирование каждые 15–30 минут для баз данных с полным восстановлением или по другому расписанию, если требуется. Еще одно решение, которое вам нужно будет принять, - как долго хранить резервные копии для целей восстановления. Основные компромиссы, очевидно, заключаются в сложности управления и необходимом дисковом пространстве.
Я не эксперт, но я понимаю, что с помощью резервных копий журнала транзакций вы можете откатить происходящие транзакции. В этом нет необходимости, если вы не хотите отменять то, что произошло.
Вопрос "достаточно ли ежедневного полного резервного копирования?" зависит от ситуации. Если это каждые 24 часа, и вы теряете базу данных за 1 час до резервного копирования, значит, вы теряете 23 часа данных.
Дифференциальная резервная копия создает резервную копию всех изменений с момента последней полной резервной копии, инкрементная резервная копия создает резервную копию всех изменений с момента последней полной или дифференциальной / инкрементной / полной резервной копии. В зависимости от ваших настроек, один из них может быть вам полезен.
Вы можете сделать что-то вроде добавления дифференциальной резервной копии в середине вашей полной резервной копии или использовать инкрементные резервные копии в течение дня ...