Я разрабатываю свою первую схему резервного копирования. Я новичок в управлении резервным копированием данных, и есть некоторые концепции, которые я не совсем понимаю. Вот что у меня есть и какое оборудование я буду использовать.
Я буду создавать резервные копии только трех серверов, общий объем данных составляет около 200 ГБ. Я буду делать еженедельные полные резервные копии по субботам, а затем выполнять дифференциальные резервные копии с понедельника по пятницу вечером. Также в конце месяца будет создана полная резервная копия, которая будет храниться за пределами предприятия для целей аварийного восстановления.
Используемое оборудование: -8-слотовый ленточный накопитель для резервного копирования -LTO2 ленты -Backup Exec 12.5 с Exchange и агентами SQL
Я буду использовать два набора лент, первый для недели 1, а другой для недели 2, которые будут чередоваться каждые две недели.
Итак, мой вопрос в том, сколько лент я должен использовать в каждом наборе? Обязательно ли использовать восемь, поскольку резервный диск вмещает до восьми лент? Скинет, если меньше вставлю?
Во-вторых, поскольку размер резервных копий diff каждую ночь в будние дни, вероятно, будет не больше 5 ГБ или около того, нужно ли мне вставлять пять лент LTO2 (которые вмещают до 400 ГБ) в пул носителей, по одной на каждую ночь? Или одного достаточно, поскольку теоретически он может хранить различия за несколько недель?
Чего я не понимаю, так это того, выбирает ли BE новую ленту для каждого дня, или она просто будет продолжать добавлять к той же ленте, пока она не заполнится, а затем переходить к следующей.
Возможно, проще задать вопрос: если бы у вас было оборудование и серверы для резервного копирования, перечисленные выше, каков был бы ваш дизайн резервного копирования?
Большое спасибо....
Я очень рекомендую книгу У. Кертиса Престона "Резервное копирование и восстановление" (книга О'Рейли).
http://oreilly.com/catalog/9780596102463/
Спрашивать, как сделать запасной вариант, все равно что спрашивать 10 бабушек, как приготовить лучший суп с куриной лапшой. Вы получите 10 разных ответов, но все они согласятся с основными ингредиентами.
На мой взгляд, Backup & Recovery довольно хорошо рассказывает о сильных и слабых сторонах различных вариантов, которые вы можете (или не можете) выбрать для реализации.
Итак, с этого я начну в первую очередь.
Прошло много времени с тех пор, как я это настраивал, а я дома, так что иду по памяти.
В нашем случае у нас есть привод LTO-3, полная резервная копия умещается на двух лентах, а все различия за неделю умещаются на одной. Итак, каждую неделю у нас есть набор лент, состоящий из двух лент для полной версии и третьей ленты для следующих 5 различий. Мы храним эти наборы в течение 5 недель, у нас есть один набор на месте и 4 на месте.
Мы настроили пул носителей для полных резервных копий со временем перезаписи, установленным на 5 недель, чтобы ленты нельзя было повторно использовать до этого, и установили для него запрет на добавление, чтобы в следующий раз, когда вы используете ленту, она запускалась с начало.
Для различий пул носителей был установлен на 1 неделю, потому что после этого мы не особо заботились о том, что было в различиях, и, если бы нам было нужно, мы могли взять "неправильную" ленту различий. На практике, как я уже сказал, мы всегда держим комплект лент на неделю вместе. Но когда мы впервые получили LTO-3, ленты стоили 50 долларов, и мы думали, что сэкономим деньги, имея только пару лент различий и повторно используя их.
(Я сказал «был» для пула носителей различий, потому что мы фактически перестали делать различия на ленте, и теперь мы используем аналогичную схему диск-диск-лента: полное резервное копирование на диск, а затем копирование на ленту, тогда различия только на диск.)
Чтобы ответить на ваш конкретный вопрос, когда вы настраиваете резервное копирование, вы указываете ему, из какого пула носителей получить ленту, и он захватит первый, который можно использовать - на который разрешена запись.
Вы сказали LTO-2 и 200GB, так что на пару ваших лент должно поместиться полное, в худшем случае - 3. Таким образом, у вас может быть сразу 6 лент для фуллов и 2 для дифференциалов в загрузчике, затем каждую неделю вы должны вытаскивать один комплект фуллов и вставлять другой. Если ваши резервные копии помещаются на 2 ленты, у вас может быть 3 полных комплекта, и вам придется менять местами только каждые 2 недели.
Backup Exec можно настроить на использование разных слотов для полного и добавочного резервного копирования.
Самая большая слабость, которую я вижу в вашем плане, - это два набора резервных копий лент. Три набора считаются абсолютным минимумом. Обычно я использую не менее пяти подходов.
Вы также можете рассмотреть возможность ежемесячной полной резервной копии, которую вы храните в течение года.
Не знаю, как работает Backup Exec, но в целом могу ответить.
Все инструменты, которые я использовал, могут ограничивать свои наборы резервных копий до минимально необходимого количества лент. Я имею в виду, что если вы загружаете 8 пустых лент в своего робота, но записываете только на первые три, то только эти три ленты являются частью резервного набора. Остальные пять - нет, поэтому их можно использовать для чего-то еще.
Кроме того, эти инструменты можно настроить для добавления к существующей ленте, если есть свободное место. Итак, если ваш ежедневный объем составляет 5 ГБ, и ваша система настроена таким образом, она добавит инкремент на следующий день к первой ленте. Если ваши инкременты действительно такие маленькие, вы в конечном итоге будете использовать две ленты и просто вращаться между ними. Конечно, это означает, что вы также можете беспокоиться о сроках службы носителя - ленты изнашиваются, как и все остальное.
Во-вторых: вы должны быть осторожны с разницей между «дифференциальным» и «инкрементным» резервным копированием. «Дифференциальная» резервная копия - это все различия между «сейчас» и контрольной точкой, обычно последней полной резервной копией. Таким образом, если ваша дельта составляет около 5 ГБ в день, то в первый день это будет 5 ГБ, во второй - потенциально 10 ГБ и т.д. инкрементальный сам по себе. Итак, ваша первая дельта будет 5 ГБ, вторая 5 ГБ и т. Д. И т. Д.
Преимущество первого варианта заключается в том, что восстановление потенциально происходит намного быстрее - вы откатываете полную резервную копию, а затем сразу после точки восстановления выполняется разностная. Обратной стороной является то, что вам потенциально может потребоваться гораздо больше носителей в зависимости от ваших дельт.
Преимущество последнего заключается в том, что вам требуется меньше носителей, а резервное копирование потенциально выполняется быстрее, поскольку вы копируете меньше данных. Обратной стороной является то, что для восстановления на определенный момент времени вам нужно восстанавливать полностью, а затем постепенно, по порядку.
Что касается ротации - если все, что вам нужно, это две недели на месте, то ваш шаблон, вероятно, в порядке. Однако мы всегда используем более полное вращение.
Некоторые клиенты также хотят, чтобы время от времени выполнялись специальные резервные копии, которые удаляются навсегда или до тех пор, пока не будут отозваны. Обычно я делаю по две копии, так как носитель может испортиться.
Наконец, одно мудрое замечание: это не резервная копия, пока вы ее не протестируете. Выделите время в своем цикле, чтобы регулярно проверять восстановление различных частей ваших резервных копий. Это не только подтвердит ваши резервные копии, но и будет означать, что вы знаете, что делать, когда восстановление действительно произойдет.
Если вы больше ничего не читаете, прочтите "Backups suck" М.Янке здесь: http://www.standalone-sysadmin.com/blog/2009/02/backups-suck/
Я согласен с тем, что вам потребуется более двух наборов резервных копий. Я считаю, что 4 - это разумное число (так что у вас есть записи примерно на месяц, к которым можно вернуться, если что-то пойдет не так). Когда вы настраиваете резервное копирование в Backup Exec, у вас есть выбор: добавить или перезаписать данные. У вас также есть выбор, что делать, если вы сказали «добавить», но лента заполнена. Кроме того, вы можете управлять настройками защиты от перезаписи в пуле носителей, чтобы предотвратить случайную перезапись только что использованной ленты. Один совет: я склонен обнаруживать, что ленты не всегда меняют, когда они должны (потому что кто-то болен, или в отпуске, или в отпуске), поэтому, если возможно, я стараюсь иметь два набора кассет в привод. Те, что на этой неделе, и те, что на СЛЕДУЮЩЕЙ неделе. Так что у вас будет целая неделя, чтобы вытащить текущие резервные копии, пока все не испортилось. Также стоит посмотреть, уместятся ли 6 ночей дифференциалов на одной ленте. Если они этого не сделают, но 6 ночей инкремента вы могли бы рассмотреть возможность увеличения. Это увеличивает время, необходимое для полного восстановления (особенно ближе к концу недели), но оно того стоит, если уменьшит количество необходимых лент.
Помимо ленты, я настоятельно рекомендую перенести диск на диск, скопированный на другой сервер или устройство типа SAN.
Ленты отлично подходят для архивных целей, но ничто не сравнится с наличием локальной копии на диске для быстрого и беспроблемного восстановления.
Если у вас есть WAN, рассмотрите возможность отправки резервных копий дисков за пределы объекта по сети. В зависимости от того, сколько вы платите за пропускную способность, это может быть экономичным способом получить несколько копий ваших наиболее важных данных в разных местах.
У каждого из нас разные системы и разные потребности, поэтому мы все можем давать разные рекомендации. Делайте то, что предлагает KPWINC, и почитайте. Затем, когда вы его реализуете, убедитесь, что вы делаете это таким образом, чтобы его можно было легко изменить, если вы позже решите, что другая система будет лучше.
Сказав это, вот моя рекомендация:
Вы выполняете резервное копирование только небольшого количества данных, поэтому, если это целесообразно, выполняйте полное резервное копирование каждый день. Резервное копирование время от времени завершается ошибкой по многим причинам. Наличие полной резервной копии на каждой ленте не только упрощает восстановление, но и увеличивает шансы аварийного восстановления.