Вопрос или проблема
Итак, есть директория, которая активно изменяется. Я хочу получить резервную копию, но как tar, так и zip вылетают, когда файл удаляется или изменяется во время их чтения.
Существует ли какой-либо архиватор в мире Linux, который в таком случае просто пропустит затронутый файл и продолжит с остальными?
У вас проблема с согласованностью. tar и другие ошибки / жалобы на это всего лишь для того, чтобы вы знали, что создаете поврежденную резервную копию!
Единственный способ правильно решить эту проблему — захватить согласованное состояние директории. Какова польза от резервной копии, если половина файлов в ней наполовину перезаписана чем-то другим?
Но для этого вам нужно остановить все, что в данный момент изменяет файлы. (Примечание: обычно программы в таких ситуациях не открывают существующие файлы и не перезаписывают их содержимое, а создают новый файл с временным именем, а затем rename2 переименовывает этот файл в имя существующего файла, что атомарно заменяет целый файл. Вы могли бы тогда безопасно создать резервную копию всех файлов в директории, если бы игнорировали файлы с временными именами.)
Так что: исправьте программное обеспечение, которое в данный момент перезаписывает ваши файлы, иначе вы не сможете получить согласованную резервную копию.
Предполагая, что вы хотите резервную копию с минимальными повреждениями, вам действительно следует делать ваши снимки на уровне файловой системы (вы затем можете создать архив из этого снимка директории). Таким образом, по крайней мере, вы будете иметь поврежденные только те файлы, которые в данный момент записывались во время создания снимка (что быстро), а не все файлы, которые изменяются, пока вы создаете архив (что занимает больше времени).
Для этого вам нужна файловая система, которая поддерживает снимки — на Linux в данный момент (реалистично) это ZFS или BTRFS. Но это довольно хорошие варианты для вашей нагрузки, так что это не является препятствием.
Вы можете затем просто использовать инструменты файловой системы, чтобы сделать снимок директории именно в тот самый момент, когда создается снимок. Что вы затем сделаете со снимком, — ваш выбор; скорее всего, вы захотите сделать инкрементальную резервную копию и перенести ее на другую машину.
Я бы предложил что-то вроде:
#!/bin/sh
directory=foobar
## ТОЛЬКО ОДИН РАЗ: ПОДГОТОВКА
# Вы хотите, чтобы ваша интересующая директория была "подтомом" btrfs.
# Это просто: переместите оригинальную директорию в сторону,
# создайте подтом, переместите старое содержимое обратно
mv -- "${directory}" "${directory}_old"
btrfs subvolume create -- "${directory}"
mv -- "${directory}_old/*" "${directory}"
rmdir -- "${directory}_old"
# вы можете настроить удаленный репозиторий restic
# (убедитесь, что ваш ssh_config позволяет вход без взаимодействия)
remote_repo=sftp://[email protected]:/mnt/backups
# положите пароль для шифрования резервной копии в этот файл:
RESTIC_PASSWORD_FILE="/etc/restic-password"
chmod 600 "${RESTIC_PASSWORD_FILE}"
restic -r "${remote_repo}" init
## СОЗДАНИЕ РЕЗЕРВНОЙ КОПИИ
## создайте снимок только для чтения (занимает почти ноль пространства, быстро)
snapshot="${directory}-snapshot"
btrfs subvolume snapshot -r "${directory}" "${snapshot}"
## резервное копирование с использованием restic, и только если это сработало, удалите снимок
( \
restic backup -r "${remote_repo}" -- "${snapshot}" \
|| -- mv "${snapshot}" "backup-failed-$(date +%s)" \
) \
&& btrfs subvolume delete "${snapshot}" \
.
Ответ или решение
Решение проблемы резервного копирования изменяющегося каталога в Linux
Когда речь заходит о резервном копировании активно изменяющегося каталога в Linux, одной из главных задач является создание согласованного состояния для резервной копии. Как показывают ваши попытки с использованием команд tar и zip, стандартные архиваторы могут аварийно завершать работу, если файлы внутри каталога изменяются в процессе архивации. Это приводит к риску получения некорректного или неполного резервного копирования, что, безусловно, недопустимо.
Основные проблемы
- Проблема согласованности: Важно обеспечить, чтобы богатый резервный копию содержал только целые и полностью записанные файлы.
- Состояние файлов: При попытке архивации могут произойти изменения файлов, что может привести к получению "половинчатых" данных.
Возможные решения
1. Использование файловых систем с поддержкой снимков (snapshots)
Первым и наиболее эффективным способом является использование файловых систем, которые поддерживают создание снимков, таких как ZFS или BTRFS. Снимок позволяет зафиксировать состояние файловой системы в определенный момент времени, что значительно повышает вероятность получения корректной резервной копии.
Пошаговое руководство
- Подготовка подкаталога: Убедитесь, что целевой каталог является "подтомом" (subvolume) BTRFS. Это можно сделать следующим образом:
#!/bin/sh
directory=foobar
# Переместите оригинальный каталог
mv -- "${directory}" "${directory}_old"
btrfs subvolume create -- "${directory}"
mv -- "${directory}_old/*" "${directory}"
rmdir -- "${directory}_old"- Создание удаленного репозитория для резервного копирования: Если вы хотите сохранять резервные копии на удаленном сервере, вы можете использовать
restic– надежное средство для резервного копирования, которое поддерживает различные backend-репозитории.
remote_repo=sftp://<имя_пользователя>@<сервер>:/mnt/backups
RESTIC_PASSWORD_FILE="/etc/restic-password"
chmod 600 "${RESTIC_PASSWORD_FILE}"
restic -r "${remote_repo}" init- Создание снимка и резервное копирование:
# Создание только для чтения снимка каталога
snapshot="${directory}-snapshot"
btrfs subvolume snapshot -r "${directory}" "${snapshot}"
# Резервное копирование с использованием restic
( \
restic backup -r "${remote_repo}" -- "${snapshot}" \
|| mv "${snapshot}" "backup-failed-$(date +%s)" \
) \
&& btrfs subvolume delete "${snapshot}"- Удаление снимка: После успешного резервного копирования рекомендуется удалить временный снимок, чтобы освободить место.
2. Анализ и оптимизация программного обеспечения
Если изменения в данных происходят очень часто, вам стоит проанализировать программное обеспечение, которое использует эти данные. Иногда возможно изменить способ, которым данные записываются, чтобы избегать перезаписи существующих файлов. Например, использование временных имен для файлов, которые затем переименовываются (например, с помощью rename2), поможет минимизировать проблемы с согласованностью при резервном копировании.
Заключение
Хотя резервное копирование активно изменяющегося каталога в Linux может представлять собой значительную задачу, использование файловых систем с поддержкой снимков, таких как BTRFS или ZFS, в сочетании с инструментами резервного копирования, такими как restic, предлагает надежный способ создания согласованных резервных копий. Это гарантирует, что ваши данные остаются целыми и доступны в случае аварийной ситуации.
Оптимизация SEO
- Ключевые слова: резервное копирование в Linux, изменяющиеся каталоги, BTRFS, ZFS, инструменты резервного копирования, согласованность данных, создание снимков.
- Метаданные: Поддержка файловых систем, инструменты резервного копирования, управление данными, файлы и снимки в Linux.
Это решение не только повысит стабильность вашего резервного копирования, но и освоит лучшие практики управления данными на Linux-системах.