LINUX.ORG.RU
ФорумAdmin

Синхронизация большого количества файлов с сохранением жёстких ссылок

 , , , ,


0

3

Привет всем!

Подскажите, какие есть альтернативы для rsync в плане синхронизации большого количества файлов с большим количеством жёстких ссылок на удалённый компьютер с доступом по ssh?

У меня есть локальная резервная копия рабочих данных. Точнее можно сказать, это несколько снимков по датам, которые создаются с помощью команды rsync и опции --link-dest=. Т.е. за счёт использования жёстких ссылок, занимаемое место ровняется объёму одной копии, плюс разницы между копиями, но при этом я получаю несколько снимков состояния в разное время. На данный момент хранится 4 копии, за 4 дня, но это не суть.

Теперь я это хочу синхронизировать на удалённый компьютер по ssh. Но с rsync есть проблема, т.к. опция --hard-links работает только в рамках одной сессии синхронизации, про что написано в мануале: Note that rsync can only detect hard links between files that are inside the transfer set. В моём случае это не вариант, т.к. объём данных достаточно большой, и интернет соединение точно будет разорвано ещё до передачи всех данных. Да и в рамках одной сессии это работает недостаточно надёжно, о чём написано, например, тут: https://serverfault.com/questions/363670/rsync-avzhp-follows-hardlinks-instead-of-copying-them-as-hardlinks (есть некоторый лимит отслеживаемых ссылок, после которого перестаёт работать) Т.е. связанность распадается и я получаю в четыре раза больше передаваемых и хранимых данных. Это очень нехорошо, т.к. на целевом сервере ограничен трафик и место.

Ещё хочу уточнить, что резервную копию я делаю не непосредственно с локальных данных, а через gocryptfs в реверсивном режиме. Т.е. локальные данные у меня доступны как есть, а в точке монтирования gocryptfs они представлены в зашифрованном виде. Однако, насколько я могу судить, проблема не в gocryptfs, т.к. stat для разных путей, что ведут к одним и тем же данным, показывает точно один и тот же inode. Получается, что проблема именно в rsync.

Чем бы его заменить?

★★★★★

А если поменять утилиту для бекапов на borgbackup или restic, тем самым избавиться от hard линков ?

Samamy ★★★
()

Ну ты можешь сделать tar на локальной машине и отправлять на удалённую уже архив. Там распакуешь.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

сделать tar на локальной машине и отправлять

В смысле каждый раз пересылать целый архив? Так это будет тот же расход трафика просто так да и просто долго.

ls-h ★★★★★
()
Ответ на: комментарий от Samamy

поменять утилиту для бекапов на borgbackup или restic

Локально? Мне нравится локальный rsync тем, что резервную копию я могу просто открыть если надо что-то восстановить и посмотреть версию несколько дней назад.

ls-h ★★★★★
()
Последнее исправление: ls-h (всего исправлений: 1)

Я подумал, может быть есть что-то уровнем ниже, чем файловая система, чтобы гонять изменившиеся блоки нижележащего блочного устройства? Я тут случайно нагуглил штуку под названием `dm-era`. Но пока не нахожу какие есть утилиты для работы с такими данными.

Вообще, может быть перейти на ZFS и использовать `send / receive`? Правда мне обязательно, чтобы данные были на той стороне зашифрованными. Да, сама файловая система это поддерживает, однако насколько я понимаю, после того как я смонтировал данные в расшифрованном виде в какую-то точку монтирования, то и `send / receive` будут передавать расшифрованные. Так? Кроме того пока не совсем понимаю, как продолжить передачу, если она остановилась из-за разрыва сообщения.

ls-h ★★★★★
()
Ответ на: комментарий от Samamy

borgbackup и restic

Спасибо. Насколько я вижу, оба могут монтировать с помощью FUSE. Это хорошо и удобно. Несколько вопросов:
1. И что же из них лучше?
2. Дедупликация основана на хешировании. Т.е. теоретически могут быть коллизии, когда данные изменились, а хеш совпал? Или я неправильно понял фишку?
3. Можно сделать так, чтобы основным был локальный бекап, который бы самой же этой утилитой синхронизировался на тот самый удалённый сервер? Или надо будет просто локальные файлы бекапа гонять туда через `rsync`?

ls-h ★★★★★
()
Ответ на: комментарий от ls-h
  1. И что же из них лучше?

Для своих бекапов использую borgbackup из-за параметра --chunker-params (https://borgbackup.readthedocs.io/en/stable/usage/notes.html?highlight=chunker-params#chunker-params), который позволяет выбрать размер блока на которые резать файлы для хранения в репозитории, чем меньше блок тем больше шансов что попадется такой же, тем выше коэффициент дедупликации и выше потребление RAM.

В restic такого не нашел, использую его на работе из-за возможности хранить репозиторий в s3.

На хабре есть сравнение restic и borgbackup https://habr.com/ru/company/southbridge/blog/454734/

  1. Дедупликация основана на хешировании. Т.е. теоретически могут быть коллизии, когда данные изменились, а хеш совпал? Или я неправильно понял фишку?

Да основана хеширование, вот что пишут разработчики

The probability would be around to 0.0000000000000000000000000000000000000000000000000000000000043.
https://borgbackup.readthedocs.io/en/stable/faq.html#how-probable-is-it-to-get-a-hash-collision-problem

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

У restic можно копировать снапшоты между репозиториями (https://restic.readthedocs.io/en/latest/045_working_with_repos.html#copying-snapshots-between-repositories), у borgbackup такой возможности нет, разработчики предлагают для лучшей надежности делать отдельные репозитории (https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-copy-or-synchronize-my-repo-to-another-location)

Samamy ★★★
()
Ответ на: комментарий от Samamy

вот что пишут разработчики

Хоть цифра и невероятно маленькая, но внутренний перфекционист говорит «Как так? Средство бекапа, которое с некоторой вероятностью превращает данные в мусор? Возмутительно!». А можно это как-то отключить, что если файл изменился, то файл целиком добавляется в бекап?

ls-h ★★★★★
()
Ответ на: комментарий от ls-h

Там все файлы разрезаются на блоки этого не изменить(ну или я не нашел как можно отключить)

Samamy ★★★
()
Ответ на: комментарий от ls-h

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

theurs ★★
()
Ответ на: комментарий от theurs

а ты надеешься на случайное совпадение

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

ls-h ★★★★★
()

Если ты руками делаешь аналог снапшотов zfs(btrfs), то почему бы тебе руками (скриптом) не находить что изменилось, копировать (создавать жесткие ссылки) на удаленный комп?

Или использовать zfs и его возможности синхронизации через сеть?

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от futurama

Если ты руками делаешь аналог снапшотов zfs(btrfs)

Я бы не сказал, что руками, всего-то одна дополнительная опция для rsync.

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

И как именно ты это предлагаешь, если rsync не работает как удалённо с жёсткими ссылками?

Или использовать zfs и его возможности синхронизации через сеть?

С ним у меня есть несколько вопросов, см. тут: Синхронизация большого количества файлов с сохранением жёстких ссылок (комментарий)

ls-h ★★★★★
()
Последнее исправление: ls-h (всего исправлений: 1)
Ответ на: комментарий от ls-h

dm-era

Ещё нашлась некая похожая технология - DRBD. Может быть кто использовал? Насколько это применимо через интернет или это только для локальных сетей?

ls-h ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.