У меня есть сервер журналов Linux, на котором несколько приложений записывают данные. Данные записываются пакетами и в множество разных файлов. Мне нужно сделать резервную копию этого беспорядка, желательно сохранить как можно больше согласованности между версиями файлов и избежать получения усеченных файлов. Общий объем данных на сервере составляет около 100Гб. Чего я действительно хотел бы (но не могу), так это выключения, резервного копирования системы в холодном состоянии, а затем ее повторного запуска.
Какие гарантии против одновременной модификации дают различные инструменты резервного копирования? Когда они «замораживают» версии файлов? В данный момент я смотрю на rsync, dump и tar, но я открыт для других (с открытым исходным кодом) альтернатив.
К сожалению, изменить приложение или заблокировать запись для резервных копий невозможно. Система не запускает LVM (пока), но я учел это для восстановления системы, а затем снимков.
Если вы используете syslog, вы можете настроить свой сервер журналов на репликацию журналов в реальном времени на другой сервер (например, rsyslog) для резервного копирования в реальном времени.
Затем сделайте резервную копию всех повернутых файлов, как уже предлагалось, для долгосрочного архивирования.
logrotate также может быть настроен для пользовательских приложений и может применять сценарии bash к ротационным журналам. Таким образом, вы можете вообще пропустить / var / log во внешних инструментах резервного копирования и скопировать журналы в архивный каталог, который более статичен.
разве вам не подходит ротация журналов? просто сделайте резервную копию файлов журнала, которые уже повернуты - разве это не решение?
и да - в противном случае лучшим выбором будет моментальный снимок на уровне LVM [помните, что когда моментальный снимок активен, производительность записи снижается].
Ни один из рассматриваемых вами инструментов не дает гарантий от одновременного изменения. Однако действительно ли вам нужен моментальный снимок? В таком случае используйте параметр моментального снимка LVM, указанный выше. Поскольку вы указали rsync в качестве опции, я предполагаю, что резервное копирование с диска на диск является вариантом.
Наименее безопасным является дамп, который копирует блоки диска по мере их чтения. Учитывая размер ваших данных, вероятно, будут существенные различия между информацией каталога и данными. Для резервного копирования с диска на диск в качестве альтернативы вы можете рассмотреть dd на разделы того же размера. Оба решения делают по сути одно и то же и имеют одни и те же проблемы.
Tar будет читать файлы один за другим и будет читать до конца каждого. Если файл был переименован или удален во время резервного копирования tar, tar создаст резервную копию файла, который он начал читать. Это разумное решение для файлов журнала.
Rsync ведет себя как tar, но только копирует изменения. По сути, он скопирует все изменения в каталоги. Со схемой ротации журналов на основе даты (logfile.гггммдд) вместо обычной схемы ротации версий (logfile.1 logfile.2gz ...). Он может эффективно создавать резервные копии ваших файлов журналов.