Различие между резервными копиями: см. Права доступа, различия между группой и владельцем и символьные ссылки - proUbuntu
4 голосов
/

Вопрос

Используя только командную строку, можно ли определить, совпадают ли резервная копия rsync (на NAS) и исходное дерево папок (на веб-сервере)? Я имею в виду размеры файлов, атрибуты и символические ссылки?

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

Контекст Я настраиваю систему резервного копирования rsync, в которой мой NAS (ручной процессор) подключается к моему выделенному веб-серверу, расположенному далеко, и создает резервную копию раздела /.

В случае сбоя диска я планирую выполнить точно такую ​​же настройку раздела на новом диске, установить ту же операционную систему (14.04), чтобы установить загрузчик MBR / boot.

Затем я перешагиваю резервную копию с NAS на сервер, перезагружаюсь и скрещиваю пальцы.

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

Опции, которые я использую с rsync:

rsync -rlptgoDXvxzH --numeric-ids --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}

Опция A вызывает проблемы.

РЕДАКТИРОВАТЬ: ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

Мне нужна рабочая стратегия резервного копирования, которая позволит мне:

- выполнить быстрое быстрое резервное копирование. Поскольку я выполняю резервное копирование системного раздела /, я отключаю большинство служб на сервере (apache, postfix, dovecot, mysql и т. Д.), Чтобы иметь резервную копию safe . Любое решение, такое как rsync, хорошо, потому что я могу обновить каталог mirror на NAS. Затем в автономном режиме я могу позаботиться о стратегии резервного копирования (инкрементной и т. Д.) Из обновленного зеркала.

- для быстрого восстановления (я не хочу передавать образ диска размером 100 ГБ). У меня действительно очень быстрое соединение между NAS и сервером. Я имею в виду очень быстро. Передача образа диска объемом 10 ГБ занимает считанные минуты.

Что я не могу сделать : изменить физическую настройку размещенного сервера. У меня есть один диск на 500 ГБ. Вот и все.

Что я могу сделать : загрузить сервер в режиме восстановления, в котором диск вообще не подключен. Режим восстановления даже работает с мертвым диском. Я использую этот режим для выполнения двоичных образов разделов.

Текущая настройка: / 10 ГБ, 17% заполнено СВОП 512 мес /var 80 ГБ /bkup Остальное… до 500 ГБ.

Ответы [ 2 ]

2 голосов
/

Мой эксперимент

  1. Настройка

Сначала я создал раздел Ext4 на своем компьютере, используя gparted.

Затем я загрузился в небольшую установку Arch GNU / Linux в надежде, что это принесет лучшую производительность. Затем я подключил свой Raspberry Pi к ПК только с немного измененной установкой Raspbian GNU / Linux через Ethernet.

Затем я установил раздел Ext4.

  1. Копирование

После этого я скопировал / раздел Pi на мой ПК.

rsync -rlptgoDXvxzH --numeric-ids --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} root@raspberrypi:/ rsync_mount/

Это заняло около 20 минут. Если вы копируете свой сервер на NAS, вам может потребоваться

  • фиксированная ставка (или много денег;))
  • много времени

    1. кирпич Raspberry Pi

Затем я обмул свой Raspberry Pi, используя

ssh root@raspberrypi

rm -r /run /var /etc /usr

Потом мне пришлось отключить кабель питания, потому что больше ничего не работало.

  1. ремонт Raspberry Pi

Наконец, я подключил SD-карту Rpi к компьютеру, смонтировал и отремонтировал, используя

cp -rpvxH  rsync_mount/* rpi_mount/

после отсоединения SD-карты и загрузки Rpi все снова заработало нормально.

Fazit

Часть с rsync работала нормально, но я не знаю, будет ли она работать с полной новой установкой. Возможно, тогда ядро ​​не будет соответствовать тому, что вы копируете обратно на сервер.

Я сделаю еще одну попытку, где я установлю более новую версию ядра после rsyncing.

1 голос
/

На самом деле вы спрашиваете: Какая стратегия резервного копирования для моего сервера , и это зависит от того, что вы хотите сделать, когда молния ударит по вашему серверу ...

Для меня быстрое восстановление - это то, что я хочу, так что я делаю:

У меня есть еще один маленький, старый, дешевый диск с двумя дополнительными разделами на сервере: раздел ext4 объемом 500 ГБ, содержащий резервные копии системы, и загрузочный раздел FAT32 объемом 500 МБ, раздел diag (да, MegaByte, и он слишком большой !) содержащий CloneZilla.

Всякий раз, когда я собираюсь внести некоторые радикальные изменения в сервер или когда я чувствую, что могу позволить себе 5 минут простоя, я загружаю сервер в раздел FAT32 CloneZilla, который затем создает резервную копию моего корневого раздела, исключая "/ домой "за 5 минут! (используя диск-образ)

Мне пришлось восстанавливать образ только один раз, и он работает как чудо: сервер был переустановлен на 1 месяц (поскольку я не был уверен, когда я представил проблему), установил все его обновления, а затем мне пришлось повторить моя работа с прошлого месяца, которая в основном устанавливала несколько утилит.

В дополнение к этому, я rsync мой /home и раздел резервного копирования образа системы еженедельно в понедельник 03:00 (то есть, когда сервер использует самое низкое использование).

Если вам этого достаточно, используйте ту же стратегию.

...