Какой самый быстрый способ делать ежедневные резервные копии для файлов 500k +?

303
raullarion

У нас есть приложение, которое сгенерировало более 540 тыс. Изображений. Изображения хранятся в древовидной структуре, которая на данный момент использует 5 миллионов инодов.

Мы хотели бы ежедневно делать резервные копии данных на удаленном стороннем сервере. Мы подумали об использовании rsync, но не уверены, что это будет самый быстрый способ.

Ребята, есть ли у вас рекомендации по эффективной стратегии резервного копирования?

4
Как много из этого меняется? Есть ли изменения в файлах, или добавляются только новые файлы (а существующие остаются прежними)? Есть ли у вас какие-либо требования к объему памяти (сжатию)? Какова ваша пропускная способность между источником и пунктом назначения? У вас есть какие-то жесткие ограничения по времени (например, 2 часа), а не просто "самый быстрый"? Bob 6 лет назад 0
Файлы подвержены постоянным изменениям. Вчера наше приложение сгенерировало 24 тыс. Новых файлов. Мы не отслеживаем, сколько из них удаляется ежедневно, но можно с уверенностью предположить, что около 10 тыс. Удаляются ежедневно. Приложение находится в Амстердаме, сервер резервного копирования - в США, на восточном побережье. Мы не знаем точную пропускную способность между серверами, но мы используем один и тот же сервер резервного копирования для других приложений, и все работает довольно быстро. У нас нет жестких ограничений по времени, но мы не хотим, чтобы процесс резервного копирования вызывал большие нагрузки на нашем сервере приложений. raullarion 6 лет назад 0
540K изображений, 5M inode, много подкаталогов? В приложениях, которые генерируют очень много файлов, обычно хорошей идеей является сохранение файлов во временных каталогах, чтобы избежать слишком большого количества дочерних каталогов. Затем вы создаете новый каталог каждый год / месяц / день / час в зависимости от скорости создания. это уже так? Если это так, то, зная, когда ваша последняя резервная копия была, поможет сосредоточиться на том, когда искать новые файлы (да, это не заботится о старых файлах, которые изменились, но приложения также избегают этого, предпочитая создавать новый файл). xenoid 6 лет назад 0
К сожалению, да, слишком много подкаталогов. Это очень большой недостаток дизайна, но я боюсь, что мы ничего не можем сделать сейчас для наших существующих файлов. raullarion 6 лет назад 0

1 ответ на вопрос

2
Deltik

Чувак, так долго каждый день нужно сканировать 5 000 000 инодов, чтобы найти файлы, которые изменились!

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

Ну, вы можете ... со снимками !

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

В Linux две хорошо известные файловые системы моментальных снимков:

  • Btrfs - Разработано для Linux, менее проверено в бою
  • ZFS - портирован на Linux, был дольше

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

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

Btrfs инкрементные резервные копии

Это пример команд, которые вы можете запускать для создания инкрементных резервных копий и отправки их на сервер резервного копирования:

# Make a snapshot btrfs subvolume snapshot -r /app/data /backup/app-data-$(date "+%Y%m%dT%H%M%S%Z")  # Ensure the snapshot is saved sync  # Find your latest snapshot, referred to as `/backup/app-data-THIS_BACKUP_TIMESTAMP` below ls -lhtr /backup/  # Send the snapshot since the previous snapshot to the backup server btrfs send -p /backup/app-data-LAST_BACKUP_TIMESTAMP /backup/app-data-THIS_BACKUP_TIMESTAMP | ssh BACKUP_USER@BACKUP_SERVER "btrfs receive /backup/app-data"

Примечание. Исключить -p /backup/app-data-LAST_BACKUP_TIMESTAMPиз последней команды, если это первая резервная копия.

Инкрементные резервные копии ZFS

Это пример команд, которые вы можете запускать для создания инкрементных резервных копий и отправки их на сервер резервного копирования:

# Create a snapshot of the "data" dataset in your "app-pool" zpool zfs snapshot app-pool/data@$(date "+%Y%m%dT%H%M%S%Z")  # Find your latest snapshot, referred to as `app-pool/data@THIS_BACKUP_TIMESTAMP` below zfs list -rt snapshot app-pool/data  # Send the snapshot since the previous snapshot to the backup server zfs send -i app-pool/data@LAST_BACKUP_TIMESTAMP app-pool/data@THIS_BACKUP_TIMESTAMP | ssh BACKUP_USER@BACKUP_SERVER "zfs receive backup-pool/app-data"

Примечание. Исключить -i app-pool/data@LAST_BACKUP_TIMESTAMPиз последней команды, если это первая резервная копия.

Похожие вопросы