У нас есть автоматизированный скрипт для резервного копирования 200 ГБ файлов данных на локальный диск. сценарий завершает работу базы данных, выполняет тарсинг и сжатие всего каталога локально на диске, а затем запускает базу данных
tar -czvf data.tgz / some / папка
Этот процесс занимает два часа, что слишком долго. Мы хотим сократить время простоя.
Примите во внимание следующее: - Основная цель - получить идентичную копию файлов в кратчайшие сроки, пока база данных не работает. Позже мы можем сжимать, передавать или выполнять любые другие операции с файлами.
Я думал использовать rsync для синхронизации файлов каждую неделю с целевой резервной копией, а rsync будет обновлять только изменения, что займет меньше времени.
Будет ли это работать, или есть лучший подход?
Снимки файловой системы - правильный способ сделать что-то подобное.
Вы можете попробовать инструмент rsync для резервного копирования:
rsync -av host::src /dest
Для полной проверки документации по указанной ниже ссылке: https://linux.die.net/man/1/rsync
Дирвиш это то, что вы ищете. Любые идентичные файлы жестко связываются, поэтому у вас есть полное дерево каталогов для копирования, плюс используется rsync, чтобы вы экономили полосу пропускания для частично измененных файлов.
Что касается ответа 84014, убедитесь, что вы очищаете таблицы и (читаете) блокируете их, прежде чем делать снимок. Это обеспечивает более согласованный снимок без прерывания транзакций. Также регулярно создавайте резервные копии журналов транзакций в удаленном месте, чтобы иметь возможность восстановления на определенный момент времени, когда это необходимо. По возможности лучше делать это на реплицированном ведомом устройстве.
Rsync - это imho для баз данных, который не подходит.
Если СУБД поддерживает репликацию, рассмотрите возможность установки экземпляра репликации в отдельном хранилище и, возможно, на удаленном сайте. Возможно, вы сможете быстро превратить другой в основной.
Но это не бэкапы, бэкапы офлайн. Определите, как выполнять резервное копирование без остановки базы данных. Либо СУБД записывает резервную копию, либо вы приказываете ей приостановить запись, либо иным образом переходите в безопасную точку и сами получаете копию файлов.
Самый быстрый способ получить копию - сделать снимок тома данных. Необычные массивы хранения могут делать снимки LUN, а затем передавать их другому хосту резервного копирования. Или сделайте снимок уровня LVM, чтобы сделать это на уровне хоста. В любом случае резервная копия не будет полной, пока она не будет скопирована на другой внешний носитель.
Идеальная стратегия резервного копирования сильно зависит от конкретной базы данных, которую вы используете. В любом случае, вот несколько общих советов по сокращению времени простоя:
если ваша файловая система или менеджер томов поддерживает снимки, вы можете использовать их, чтобы значительно сократить ожидаемое время простоя. Рабочий процесс будет примерно таким:
если вы можете позволить себе потерять самую последнюю транзакцию в своей резервной копии, вы можете изменить приведенную выше последовательность, чтобы избежать остановки / запуска базы данных, эффективно давая вам без простоев процесс резервного копирования;
Если вы не можете полагаться на снимки, вы должны максимально сократить время копирования. Я настоятельно рекомендую вам попробовать tar --lzop -cvf, который будет использовать очень быстрый компрессор lzo. База данных должен быть остановлен на все время резервного копирования;
если этого недостаточно, попробуйте скопировать только изменено заблокировать ваши файлы данных. Пытаться bdsync или blocksync чтобы увидеть, будет ли последующее резервное копирование быстрее первого. Обратите внимание, что обе утилиты работают с отдельными файлами, поэтому вы должны использовать их в сценарии для копирования нескольких файлов. База данных должен быть остановлен на все время резервного копирования;
rsync обычно не рекомендуется для копирования очень больших файлов; однако вы можете попробовать что-то вроде rsync -a --inplace или, с другой стороны, rsync -a -W. Очевидно, вам нужно запустить какой-нибудь тест по времени, чтобы узнать, что rsync вызов лучше подходит для ваших конкретных нужд. Опять же, это нужно делать с базой данных остановлен на все время резервного копирования;
если эти подходы не работают или неприменимы к вашему случаю, вам придется настроить процесс резервного копирования, специфичный для базы данных (то есть: полагаться на репликацию или доставку журналов на вторичный хост).