Назад | Перейти на главную страницу

Решение для резервного копирования 10 ТБ с использованием ubuntu

Я настраиваю резервный сервер с примерно десятью жесткими дисками емкостью 2 ТБ. Цель этой машины - просто создать резервную копию примерно 3-10 ТБ данных с другого сервера.

Как лучше всего сделать эту резервную копию. Было бы неплохо иметь историю версий. Я думал просто настроить gitosis и создать репозиторий git. Другой компьютер будет просто git commit и git push на этот сервер через определенные промежутки времени. Но я не уверен, что git может обрабатывать такие данные. Файлы состоят на 90% из изображений (jpeg, tiff и т. Д., Которые не меняются, поэтому это небольшие файлы), а 10% представляют собой большие дампы базы данных и будут меняться ежедневно.

Лучшим решением было бы выполнить синхронизацию с резервной машиной и использовать LVM для создания снимков? Как насчет использования TimeVault? Я хотел бы иметь не одну копию резервной копии, а несколько версий в разные промежутки времени. Любая информация по этому поводу была бы замечательной.

Я бы установил коробку как NAS с NextentaStor Community Edition (ZFS!) Или OpenFiler.

Зачем возиться с полным дистрибутивом, если вы не планируете использовать его как-то еще? Меньше ошибок, потому что он специально сконструирован и занимает меньше места; у OpenFiler и NextentaStor есть свои плюсы и минусы, но любой из них был бы лучшим вариантом для чистого устройства хранения, чем обычный Ubuntu.

Использование git кажется неподходящим. Если вы действительно так предпочитаете, взгляните на мерзавец который является расширением git для разумного хранения больших двоичных файлов в репозитории git.

Тем не менее, я рекомендую rsnapshot, rdiff-backup.

Я определенно НЕ рекомендую снимки LVM для этого1.

  • Скорость записи сильно снизится
  • На этих томах моментальный снимок приведет к загрузке в течение многих минут, если не часов (Вот)
  • есть фатальные ошибки при нехватке места
  • и в последний раз, когда я проверял что-либо вроде отката, все еще было удаленным обещанием
  • Имейте в виду, что даже установка снимка вместе с вашей живой файловой системой может оказаться очень сложной задачей, поскольку файловые системы полагаются на уникальные идентификаторы в заголовке fs.
  • Кроме того, запрещая использование iSCSI или DBRD (и т. Д.), Вы застреваете на том же хосте, что и live fs, что делает резервное копирование гораздо менее полезным (и еще больше снижает производительность)

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


1 Я только что нашел лакомый кусочек, о котором писал ранее:

Однако я больше не могу подсчитывать различные режимы отказа, с которыми я столкнулся при использовании снимков. Я вообще перестал ими пользоваться - это слишком опасно.

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

Важнейшие аспекты, о которых следует помнить:

  1. если у вас есть большая (ish) fs, у которой есть снимок, производительность записи ужасно ухудшается
  2. если у вас большая (ish) файловая система с моментальным снимком, время загрузки будет отложено буквально на десятки минут, в то время как диск будет перемешиваться и перемешиваться во время импорта группы томов. Сообщения отображаться не будут. Этот эффект особенно ужасен, если root находится на lvm2.
  3. если у вас есть снимок, очень легко не хватить места. Как только у вас закончится свободное место, моментальный снимок будет поврежден и не может быть восстановлен.
  4. Снимки нельзя откатить / объединить в данный момент (см. http://kerneltrap.org/Linux/LVM_Snapshot_Merging). Это означает, что единственный способ восстановить данные из моментального снимка - это фактически скопировать (rsync?) Его. ОПАСНО ОПАСНО: вы делаете не хотите сделать это, если емкость моментального снимка не меньше размера исходной файловой системы; Если вы этого не сделаете, вы скоро наткнетесь на кирпичную стену и в конечном итоге получите повреждение как исходной файловой системы, так и снимка. (Я был там!)

Я очень рекомендую не используя для этого git. Конечно, это может сработать, но это не совсем оптимально.

Вы можете использовать rsync, LVM и снимки, если хотите. Я предпочитаю метод резервного копирования для подобных случаев - использовать снимок или rdiff-резервное копирование. Они могут использовать оптимизацию, которую дает вам rsync, одновременно предоставляя дополнительный набор резервных копий.

Параметр Rsync "--backup-dir =" может устранить необходимость в ежедневных снимках. Любые измененные файлы помещаются в резервную папку и могут быть восстановлены оттуда.

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

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

Я установил меньший сервер резервного копирования с помощью BackupPC. Он находится в репозиториях Ubuntu, настроить его несложно. Использует rsync для передачи, выполняет дедупликацию на уровне файлов.

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

Зацени, это действительно хорошо.

https://help.ubuntu.com/community/BackupPC

http://backuppc.sourceforge.net/faq/BackupPC.html