Что является самым быстрым способом регулярного резервного копирования больших файлов данных на еженедельной основе

Вы можете проверить утилиту с именем rsync для резервного копирования.

rsync -av host:: src / dest

Для полной документации проверьте ниже ссылку: https://linux.die.net/man/1/rsync

Снимки файловой системы - это правильный способ сделать что-то подобное.

Что касается ответа 84014, убедитесь, что вы очищаете таблицы и (читаете) блокируете их, прежде чем делать снимок. Это обеспечивает более согласованный снимок с неразбитыми транзакциями. Также регулярно делайте резервные копии журналов транзакций в удаленном месте, чтобы вы могли получить восстановление на определенный момент времени, когда это потребуется. Лучше всего делать это на реплицированном рабе, когда это возможно.

Rsync является imho для баз данных, а не путь.

Dirvish - это то, что вы ищете. Любые идентичные файлы становятся жестко связанными, поэтому у вас есть полное дерево каталогов для копирования, плюс он использует rsync, поэтому вы экономите пропускную способность для частично измененных файлов.

Идеальная стратегия резервного копирования сильно зависит от конкретной базы данных, которую вы используете. В любом случае, вот несколько общих советов по сокращению времени простоя:

• если ваша файловая система или менеджер томов поддерживает моментальные снимки, вы можете использовать их, чтобы значительно сократить ожидаемое время простоя. Рабочий процесс будет примерно таким:

  1. остановить вашу базу данных;
  2. создать снимок;
  3. перезапустить базу данных;
  4. запустите процесс резервного копирования для вашего снимка, а не для оперативных данных.

• если вы можете позволить себе потерять самую последнюю транзакцию в своей резервной копии, вы можете изменить вышеуказанную последовательность действий, чтобы избежать остановки / запуска базы данных, эффективно предоставляя вам процесс резервного копирования без простоев;

• Если вы не можете полагаться на снимки, вы должны максимально сократить время копирования. Я настоятельно рекомендую вам попробовать tar --lzop -cvf, который будет использовать очень быстрый компрессор lzo. База данных должна быть остановлена ​​на все время резервного копирования;

• если этого недостаточно, вы должны попытаться скопировать только измененный блок из ваших файлов данных. Пытаться bdsync или же blocksync чтобы увидеть, если последующие резервные копии быстрее, чем первая. Обратите внимание, что обе утилиты работают с отдельными файлами, поэтому вы должны создавать сценарии вокруг них для копирования нескольких файлов. База данных должна быть остановлена ​​на все время резервного копирования;

• rsync обычно не рекомендуется для копирования очень больших файлов; Тем не менее, вы можете попробовать что-то как rsync -a --inplace или, с другой стороны, rsync -a -W, Вы явно должны были запустить какой-то временной тест, чтобы узнать, что rsync вызов лучше подходит для ваших конкретных потребностей. Опять же, это должно быть сделано с остановкой базы данных на весь период резервного копирования;

• Если эти подходы не работают или не применимы к вашему случаю, вам пришлось настроить процесс резервного копирования для конкретной базы данных (т. е. полагаться на репликацию или доставку журналов на вторичный хост).

Если СУБД поддерживает репликацию, рассмотрите возможность установки экземпляра репликации в отдельном хранилище и, возможно, на удаленном сайте. Возможно, вы сможете быстро превратить другой в основной.

Но это не резервные копии, резервные копии находятся в автономном режиме. Определите, как выполнять резервное копирование, не отключая базу данных. Либо СУБД записывает резервную копию, либо вы приказываете ей приостановить запись, либо иным образом добираетесь до безопасной точки и сами получаете копию файлов.

Быстрый способ получить копию - это снимок тома данных. Необычные массивы хранения могут сделать снимок LUN, а затем представить его на другой хост резервного копирования. Или сделайте снимок уровня LVM, чтобы сделать это на уровне хоста. В любом случае, резервное копирование не будет завершено, пока оно не будет скопировано на другой сторонний носитель.