Препятствование тому, чтобы dateext logrotate перезаписал файлы

Я предположу, что это - единственный, неавтоматизированный диск, непосредственно подключенный к некоторому серверу. И нет никакого бюджета или практически никакого бюджета. Ваши опции:

Пройдите исходные данные и посмотрите, можно ли удалить или исключить части из набора резервных копий.

  • Pro: затраты и определения задания резервного копирования остаются, каковы они.
  • ДОВОД "ПРОТИВ": того, независимо от того, что удалено, не стало; то, независимо от того, что исключено, не становится сохраненным; если данные вырастут в "исключенных" областях, то они будут также тихо исключены, который не мог бы быть тем, что Вы хотите

Фигура, как разделить резервное копирование на два задания и выполнить эти два задания различными ночами на различных лентах.

  • Pro: все, чему нужно резервное копирование, сохранено.
  • CONS: стоимость (место ленты удваивается); наличие двух заданий означает, что кто-то должен поместить правильную ленту в диск в нужное время вдвое более часто; два задания означают, что необходимо быть осторожными, как вещи растут для обеспечения оба что A) никакое задание не растет непропорционально; и B) новые вещи на самом деле пойманы только одним из этих двух заданий

Купите более крупный ленточный накопитель (привет, LTO-4!)

  • Pro: откладывает решение разделения задания или удаления данных некоторое время.
  • ДОВОД "ПРОТИВ": стоимость ++; возможно не совместимый с реверсом с медиа у Вас уже есть история на том, что означает, что необходимо иметь в наличии старый диск и работающий на всякий случай.

Купите робот, который автоизменит ленты для Вас.

  • Pro: если Ваше программное обеспечение может обработать охватывающие ленту задания, Вы больше не должны волноваться о таких пешеходных проблемах, просто продолжать сгребать медиа в него; такое программное обеспечение может, вероятно, обработать Ваш существующий диск также, который предоставляет Вам потенциальный доступ к Вашей истории; это решение увеличится в намного лучше, чем какое-либо единственное решение для диска (т.е. решает проблему в течение следующих трех лет, не только следующих шести месяцев),
  • ДОВОД "ПРОТИВ": стоимость +++ (по крайней мере необходимо купить робот, который является дорогим; вероятно, необходимо будет купить автоматизированные лицензии слота на программное обеспечение, которые являются дорогими; Вам, возможно, придется полностью заменить Ваше программное обеспечение чем-то, что может обработать охватывающие ленту задания и роботы, который является дорогим и рискует Вами не наличие доступа к Вашей текущей истории),

Найдите некоторую backup-over-the-internet схему.

  • Pro: Ваши аппаратные средства, медиа, устройство хранения данных и проблемы хранения становятся чужой проблемой.
  • ДОВОД "ПРОТИВ": Ваше интернет-соединение должно смочь загрузить на разумной скорости передачи данных так, чтобы Ваше резервное копирование могло закончиться в течение соответствующего времени; Ваше интернет-соединение должно иметь предел передачи, который разрешит Вам выполнять эти резервные копирования; резервные копии будут медленными; восстановления очень, вероятно, будут столь же медленными; стоимость (так как поставщик услуг, несомненно, делает это к современному резервному средству, что означает Вас, оплачивают все это плюс прибыль для резервного поставщика услуг),

Резервные копии - что-то, о чем многие люди записали эссе.

Необходимо знать то, что окно восстановления - оно располагается от, "Я хочу восстановить файл, который я удалил десять минут назад (или шесть месяцев назад) ТЕПЕРЬ!" к "а, если я должен ожидать неделя ленты, которая будет поставлена от удаленного, это прохладно".

Необходимо знать, являются ли они резервными копиями для аварийного восстановления (т.е. сожженное дотла здание!) или контролирующий (доказательство состояния в определенную дату) или восстановление уровня пользователя (кто-то удалил учетную запись X вместо Y), или восстановление уровня файла (некоторый секретарь случайно вставил запись Facebook по финансовым документам компании). Ответы на эти вопросы будут управлять, как сделаны резервные копии.

Если существуют правила к резервным копиям, они обычно:

  • скопируйте все
  • сохраните его навсегда
  • сохраните это удаленным

Бюджеты ограничат, сколько из каждого можно на самом деле сделать, но люди, возглавляющие компанию, должны знать то, что и не сохраняется и каковы последствия тех фактов. Резервные копии важны для способности компании выжить технический (и иногда персонал) отказы. Они должны быть утверждены кем-то, делегировал эту ответственность от C-уровня.

Вы не можете победить. Когда Вы попросите роботы, медиа и программное обеспечение, они скажут, что "мы не должны создавать резервную копию X." Однако в чрезвычайной ситуации, они будут вопить на Вас, "почему Вы не создали резервную копию X?"

В моих клиентах каждые шесть месяцев я готовлю документ, который детализирует точно, что сохраняется, и я отмечаю каждый важный набор объектов (что я знаю о, heh), которые не сохраняются, и я посылаю его по электронной почте клиенту и затем провожу 30 минут с ними для рассмотрения его. Тем путем они знают то, что сохраняется, что я думаю, не сохраняется, резервное время выполнения и требования к данным, политики хранения данных, удаленные детали, обзор основных проблем (и надо надеяться решения) с прошлых шести месяцев, плюс ничто больше, что я думаю, важно. Я спрашиваю их, если они знают о чем-либо еще, чему нужно резервное копирование. Если какие-либо изменения требуются, я делаю их, снова посылаю документ и регистрирую те электронные письма далеко как доказательство, я отправил им документы. Реалистично, если что-то важное не будет сохранено, то моя задница все еще будет в петле, но в большинстве случаев это будет иметь компанию.

Резервные копии являются огромной, дорогой, сложной кучей проблем.

Удачи.

2
задан 6 May 2011 в 12:09
2 ответа

Вы могли использовать prerotate/endscript, чтобы удостовериться, что нет никакого файла с именем, которое Вы собираетесь использовать, но если Вы обеспокоены вращениями, происходящими в какое-либо нечетное время, это могло бы быть хитро. Худший случай - Вы, имеют два, вращается того же файла, работающего одновременно (2-й, запустился, прежде 1-й завершенный), и если оба решают, что нет никакого конфликта имен, затем каждый перезапишет другого.

Более легкий подход мог изменять повернутое имя файла для включения более точной даты, например, включая наносекунды в метке времени. Это должно сделать его очень вряд ли для имен к конфликту. Если Вы хотите быть уверенными, что нет никакого использования конфликта имен mktemp, но затем Вы получите "ужасные" имена. Логика такой смены имени должна перейти к prerotate|postrotate/endscript разделу конфигурации logrotate.

0
ответ дан 3 December 2019 в 10:18

dateext поддерживает спецификатор формата % s - время эпохи Unix в секундах.

Если вы установите формат даты как .% Y- % m-% d.% s , это будет выглядеть так:

logfilename.2012-12-11.13572638495

Это меняется каждую секунду, поэтому шансы двух одинаковых файлов очень малы.

4
ответ дан 3 December 2019 в 10:18

Теги

Похожие вопросы