Различие между резервными копиями: см. Права доступа, различия между группой и владельцем и символьные ссылки
Вопрос
Используя только командную строку, можно ли определить, совпадают ли резервная копия 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 и т. д.), чтобы иметь безопасное резервное копирование. Любое решение, такое как rsync, хорошо, потому что я могу обновить mirror каталог на NAS. Затем в автономном режиме я могу позаботиться о стратегии резервного копирования (инкрементная и т. Д.) Из обновленного зеркала.
- иметь быстрое восстановление (я не хочу передавать образ диска размером 100 ГБ). У меня действительно очень быстрое соединение между NAS и сервером. Я имею в виду очень быстро. Передача образа диска объемом 10 ГБ занимает считанные минуты.
Что я не могу сделать: изменить физическую настройку размещенного сервера. У меня есть один диск на 500 ГБ. Это все.
Что я могу сделать: загрузить сервер в режиме восстановления, в котором диск вообще не подключен. Режим восстановления даже работает с мертвым диском. Я использую этот режим для выполнения двоичных изображений разделов.
Текущая настройка: / 10 ГБ, 17 % полный своп 512 мес. /var 80 ГБ /bkup остальное… до 500 ГБ.
2 ответа
Мой эксперимент
- Настроить
Сначала я создал раздел Ext4 на моем компьютере, используя gparted,
Затем я загрузился в небольшую установку Arch GNU/Linux в надежде, что это принесет лучшую производительность. Затем я подключил свой Raspberry Pi к ПК с помощью немного измененной установки Raspbian GNU/Linux через Ethernet.
Затем я установил раздел Ext4.
- копирование
После этого я скопировал / раздел пи на мой компьютер.
rsync -rlptgoDXvxzH --numeric-ids --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} root@raspberrypi:/ rsync_mount/
Это заняло около 20 минут. Если вы копируете свой сервер на NAS, вам может понадобиться
- фиксированная ставка (или много денег;))
много времени
- кирпич Raspberry Pi
Затем я кирпич мой Raspberry Pi, используя
ssh root@raspberrypi
rm -r /run /var /etc /usr
Затем мне пришлось отключить кабель питания, потому что больше ничего не работало.
- ремонт малины пи
Наконец, я подключил SD-карту Rpi к компьютеру, смонтировал и отремонтировал, используя
cp -rpvxH rsync_mount/* rpi_mount/
после размонтирования SD-карты и загрузки Rpi все снова заработало нормально.
Fazit
Часть с rsync работал нормально, но я не знаю, будет ли он работать с полной новой установкой. Возможно, тогда ядро не подойдет тому, что вы копируете обратно на сервер.
Я сделаю еще одну попытку, где я установлю более новую версию ядра после rsyncing.
Что вы действительно спрашиваете: что такое хорошая стратегия резервного копирования для моего сервера, и это зависит от того, что вы хотите делать, когда молния попадает на ваш сервер...
Для меня быстрое восстановление - это то, что я хочу, так что я делаю так:
У меня есть еще один небольшой, старый, дешевый диск, содержащий 2 дополнительных раздела на сервере: раздел ext4 объемом 500 ГБ, содержащий резервные копии системы, и загрузочный диск FAT32 объемом 500 МБ, раздел diag (да, MegaByte, и он слишком большой!), Содержащий Clonezilla.
Всякий раз, когда я собираюсь внести некоторые радикальные изменения в сервер или когда я чувствую, что могу позволить себе 5 минут простоя, я загружаю сервер в раздел FAT32 CloneZilla, который затем создает резервную копию моего корневого раздела, исключая "/home" в 5 минут! (используя диск-образ)
Мне пришлось восстанавливать образ только один раз, и он работает как чудо: сервер был переустановлен на 1 месяц (поскольку я не был уверен, когда я представил проблему), установил все его обновления, а затем мне пришлось повторить свою работу с последний месяц, который в основном устанавливал несколько утилит.
В дополнение к этому я rsync мой /home и раздел резервного копирования образа системы еженедельно в понедельник в 03:00 (то есть, когда сервер использует самое низкое использование).
Если это достаточно хорошо для вас, используйте ту же стратегию.