3

Я сделал скрипт инкрементного резервного копирования rsync для своего сервера, который будет копировать резервную копию базы данных MySQL и заданный путь к папке на удаленный сервер. Вот код на Github.

Отрывок кода из строк 53-57:

############### Create most current hand link

echo "Creating most current hard link on backup server $most_recent_backup_link"
ssh $remote_backup_server rm -rf ${most_recent_backup_link}
ssh $remote_backup_server cp -alv ${remote_backup_folder}/backup-${backup_folder_name}/ ${most_recent_backup_link}

У меня проблема с созданием самых последних жестких ссылок на сервере резервного копирования (строки 53-57 в программе). Все работает, и rsync копирует только 1-2 МБ данных. Но процесс копирования жесткой ссылки использует около 30 МБ данных. Я получаю огромный список файлов, которые не изменились, и только те, которые изменились, имеют очень маленький размер. Обычно это не проблема, но при резервном копировании каждый час, резервная копия должна быть как можно меньше.

Например, последняя резервная копия, которую я сделал, rsync передала 1,3 МБ. Но каталог резервного копирования вырос на 35 МБ.

Почему жесткие ссылки занимают так много места на жестком диске?

2 ответа2

1

Глядя на ваш код (на git hub), создается впечатление, что вы создаете один файл .sql.gz для каждой резервной копии. несмотря на то, что есть только 1 или 2 МБ изменений, резервная копия будет совершенно новым файлом, если говорить о rsync, поэтому он разыменует файл, чтобы создать новый, поскольку они теперь другие.

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

-2

Вы должны заглянуть в storeBackup (storeBackup.org). Это делает дедуплицированные резервные копии с использованием жестких ссылок, и это очень мощный.

Он имеет больше возможностей, чем rsync для создания жестко связанных резервных копий. Для ежечасных резервных копий вы можете рассмотреть опцию storeBackup "lateLinks", которая откладывает создание всех жестких ссылок. Вы можете сделать одно ежедневное резервное копирование со всеми жесткими ссылками. (Или вы можете связать все отложенные резервные копии позже, если вы решите хранить каждую почасовую резервную копию.)

В storeBackup также есть функция, которая позволит вам решить, какие резервные копии хранить. Например, вы могли бы сказать, что следует хранить все почасовые резервные копии только за последние 24 часа, а также хранить ежедневную резервную копию за последние 30 дней и хранить первую резервную копию за этот месяц. Таким образом, вы не будете тратить так много места.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .