Я предположу, что это - единственный, неавтоматизированный диск, непосредственно подключенный к некоторому серверу. И нет никакого бюджета или практически никакого бюджета. Ваши опции:
Пройдите исходные данные и посмотрите, можно ли удалить или исключить части из набора резервных копий.
Фигура, как разделить резервное копирование на два задания и выполнить эти два задания различными ночами на различных лентах.
Купите более крупный ленточный накопитель (привет, LTO-4!)
Купите робот, который автоизменит ленты для Вас.
Найдите некоторую backup-over-the-internet схему.
Резервные копии - что-то, о чем многие люди записали эссе.
Необходимо знать то, что окно восстановления - оно располагается от, "Я хочу восстановить файл, который я удалил десять минут назад (или шесть месяцев назад) ТЕПЕРЬ!" к "а, если я должен ожидать неделя ленты, которая будет поставлена от удаленного, это прохладно".
Необходимо знать, являются ли они резервными копиями для аварийного восстановления (т.е. сожженное дотла здание!) или контролирующий (доказательство состояния в определенную дату) или восстановление уровня пользователя (кто-то удалил учетную запись X вместо Y), или восстановление уровня файла (некоторый секретарь случайно вставил запись Facebook по финансовым документам компании). Ответы на эти вопросы будут управлять, как сделаны резервные копии.
Если существуют правила к резервным копиям, они обычно:
Бюджеты ограничат, сколько из каждого можно на самом деле сделать, но люди, возглавляющие компанию, должны знать то, что и не сохраняется и каковы последствия тех фактов. Резервные копии важны для способности компании выжить технический (и иногда персонал) отказы. Они должны быть утверждены кем-то, делегировал эту ответственность от C-уровня.
Вы не можете победить. Когда Вы попросите роботы, медиа и программное обеспечение, они скажут, что "мы не должны создавать резервную копию X." Однако в чрезвычайной ситуации, они будут вопить на Вас, "почему Вы не создали резервную копию X?"
В моих клиентах каждые шесть месяцев я готовлю документ, который детализирует точно, что сохраняется, и я отмечаю каждый важный набор объектов (что я знаю о, heh), которые не сохраняются, и я посылаю его по электронной почте клиенту и затем провожу 30 минут с ними для рассмотрения его. Тем путем они знают то, что сохраняется, что я думаю, не сохраняется, резервное время выполнения и требования к данным, политики хранения данных, удаленные детали, обзор основных проблем (и надо надеяться решения) с прошлых шести месяцев, плюс ничто больше, что я думаю, важно. Я спрашиваю их, если они знают о чем-либо еще, чему нужно резервное копирование. Если какие-либо изменения требуются, я делаю их, снова посылаю документ и регистрирую те электронные письма далеко как доказательство, я отправил им документы. Реалистично, если что-то важное не будет сохранено, то моя задница все еще будет в петле, но в большинстве случаев это будет иметь компанию.
Резервные копии являются огромной, дорогой, сложной кучей проблем.
Удачи.
Вы могли использовать prerotate/endscript, чтобы удостовериться, что нет никакого файла с именем, которое Вы собираетесь использовать, но если Вы обеспокоены вращениями, происходящими в какое-либо нечетное время, это могло бы быть хитро. Худший случай - Вы, имеют два, вращается того же файла, работающего одновременно (2-й, запустился, прежде 1-й завершенный), и если оба решают, что нет никакого конфликта имен, затем каждый перезапишет другого.
Более легкий подход мог изменять повернутое имя файла для включения более точной даты, например, включая наносекунды в метке времени. Это должно сделать его очень вряд ли для имен к конфликту. Если Вы хотите быть уверенными, что нет никакого использования конфликта имен mktemp, но затем Вы получите "ужасные" имена. Логика такой смены имени должна перейти к prerotate|postrotate/endscript разделу конфигурации logrotate.
dateext
поддерживает спецификатор формата % s
- время эпохи Unix в секундах.
Если вы установите формат даты как .% Y- % m-% d.% s
, это будет выглядеть так:
logfilename.2012-12-11.13572638495
Это меняется каждую секунду, поэтому шансы двух одинаковых файлов очень малы.