Мы используем резервную копию на основе rsync для наших серверов Lonux, и это просто фантастика. Мы синхронизируем весь наш Linux-сервер с нашим большим файловым сервером Samba для Linux. К сожалению, этот сервер полностью устарел и переведен на Active Directory.
Теперь я столкнулся с проблемой создания инкрементных резервных копий с сервера Linux. Мне особенно понравилось, как rsync может копировать измененные или удаленные файлы.
Теперь я хочу сделать резервную копию Linux на сервере Windows.
Я посмотрел на решение для резервного копирования, но почти все были основаны на rsync. Я искал rsync для Windows (Cygwin или Microsofts SFU (сервисы для Unix)). Но похоже, что это не поможет.
Чтобы правильно указать владельца и права rsync, действительно нужны два целых числа и несколько флагов в файловой системе. Хотя NTFS теоретически обеспечивает это, SFU и Cygwin действительно пытаются сопоставить это с существующими пользователями.
Также rsync для SFU кажется ненадежным и т. Д.
На наших текущих серверах нас просто не заботит какое-либо сопоставление: как вы знаете, серверы Linux просто хранят два целых числа в файловой системе (в простых случаях), без длинных идентификаторов безопасности, специфичных для машины, как Windows. Их значение определяется файлом / etc / passwd. А если этого нет, это просто целые числа. Но если он возвращается на сервер, он снова работает.
Кто-нибудь нашел для этого хорошее решение?
Я даже поискал UMSDOS, где Linux раньше можно было хранить в FAT16 !!! Он использовал текстовые файлы с длинными именами файлов и правами и атрибутами unix. К сожалению, он был удален из ядра. В противном случае я мог бы смонтировать общий ресурс на новом файловом сервере Windows, используя CIFS-mount и слой umsdos поверх него. К сожалению, ничего подобного не существует.
Почему я не хочу использовать tar? Потому что мне очень нравится, как наш DPM-сервер мгновенно выполняет резервное копирование нашего файлового сервера Windows, и я не хочу полностью создавать резервную копию всего tar-файла!
Похоже, ваша настоящая проблема в том, что вы хотите сохранить настройки владельца и группы, но при этом перенести данные в систему, которая хочет сопоставить настройки со своими собственными. Вы также хотите сохранить настройку минимальной передачи данных, которую вы получаете с помощью rsync, но переход от «здесь» к «там» может занять больше времени и усилий, чем то, во что вы хотите вложить деньги. Tar решит эту проблему, но для этого потребуется весь образ каждого файла вместо дельт.
Подводя итог: вам нужно что-то, что делает дельты измененных данных, но сохраняет атрибуты, такие как tar, игнорируя сопоставления пользователей целевой системы (потому что нет общих учетных записей).
Коммерческое решение
Первый (и, вероятно, нежизнеспособный) вариант - проверить, есть ли резервный клиент для системы, которую вы используете в Windows. Например, Ретроспектива включает клиентов OS X и Linux, которые позволяют машине Windows создавать резервные копии файлов с прикрепленными атрибутами. В моей работе эта схема использовалась в течение нескольких лет, и, за исключением некоторых всплесков ввода-вывода на стороне клиента, она работала так, как рекламировалось. Посмотрите, есть ли клиент, который вы можете установить на Linux, который позволил бы вам «преодолеть разрыв» между ними, и вам не придется об этом беспокоиться. Примечание: Я заметил, что вы не опубликовали, какое решение для резервного копирования вы используете, а это значит, что если вы используете собственное резервное копирование Windows (ick), вам не повезло.
Решение с открытым исходным кодом
Вот что-то совершенно безумное: запустите сервер Samba на стороне Linux, разместите общий ресурс для административного использования (скрытый, настроенный только для администраторов и т. Д.), Сопоставьте общий ресурс или используйте путь UNC на сервере резервного копирования Windows, а затем выполните бэкап из общего ресурса. Да, ваши SID не будут совпадать и т. Д. (Потому что между AD <-> passwd нет сопоставления), но это не имеет значения, потому что Samba сделает перевод за вас, как во время резервного копирования, так и восстановления. Обратной стороной является то, что вы захотите делать регулярные резервные копии файлов Samba .tdb, чтобы гарантировать, что вы не потеряете какие-либо настройки вместе с вашими пользовательскими картами в / etc / passwd и т. Д. Вы также захотите настроить это Поделиться очень осторожно, так как неправильные настройки приведут к повторному отображению файлов на другие значения. Идея здесь в том, что мы превращаем Samba в грубое приближение «клиента резервного копирования», к которому можно получить доступ способом, совместимым с Windows. Это также предполагает, что ваше программное обеспечение резервного копирования позаботится о любых функциях дельта / сжатия, которые вы хотите ...
В отличие от коммерческого решения, у этого есть дополнительное преимущество, заключающееся в возможности работать со встроенным резервным копированием Windows, поскольку общий ресурс является просто еще одним UNC-сервером Windows.
Второе решение уже упоминалось @Brent, и на него стоит обратить внимание. Это будет на несколько шагов выше метода, который я дал. Вместо того, чтобы заниматься плагиатом его поста, иди и прочитай это вместо.
Домашнее решение
Одним из решений было бы отделить метаданные (атрибуты владения) от данных и передать их на сервер. Для этого сохраните настройки в отдельном точечном файле, а затем передайте точечный файл вместе с содержимым. Это позволит вам использовать rsync (если вы захотите), сохраняя настройки. В качестве дополнительного бонуса rsync применит тот же механизм дельта-передачи и к точечному файлу. Во время восстановления вы должны обратить процесс, извлекая настройки из вашего точечного файла и применяя их к содержимому каталога. Это занимает много времени и занимает немного места на диске, но просто (вы видите, что происходит) и прочный (это просто текстовые файлы, поэтому это легко исправить), и простота иногда оказывается самым простым способом, даже если это кажется «грубой силой». Я бы выбрал этот вариант в качестве последнего. Мало того, что у вас будут условия гонки (если вы попытаетесь запустить резервное копирование во время выполнения сценария, будут ли файлы точек обновляться вовремя, прежде чем они будут скопированы?), Но вам также необходимо создать все вручную.
Вам потребуется всего три сценария: один для восстановления файлов точек в каждом каталоге для настроек, один для их восстановления и один для очистки файлов точек, когда они не нужны.
При генерации / создании: сохраните точечный файл в каждом каталоге, которому он принадлежит. Точечный файл по существу содержит ls -la так что атрибуты фиксируются. Установите владельца точечного файла как root, чтобы свести к минимуму вред. После обработки этого каталога попросите его вернуться и извлечь каждый каталог из точечного файла (достаточно простого grep), а затем рекурсивно перейти в каждый подкаталог, вызвав сам сценарий. По завершении во всей ветке каталога, в котором вы начали, будут все точечные файлы для каждого каталога. Запустите этот сценарий перед резервным копированием, чтобы «регенерировать» и «обновить» свои настройки, или, если возможно, запустите его последовательно вместе с самим сценарием резервного копирования, чтобы убедиться, что он завершится до начала резервного копирования.
При восстановлении: сценарий восстановления сбрасывает все точечные файлы для правильного владения (опять же, чтобы избежать неприятностей), а затем рекурсивно обрабатывает точечные файлы в каждом каталоге, восстанавливая ваши настройки для каждого файла. Для каждого точечного файла потребуется 3 прохода: пропуск для группы-владельца, пропуск для присвоения имени владельцу и пропуск для присвоения имени группе. Операции с файлами обычно не так уж и плохи, так что это должно быть очень быстро, обнажая очень большие каталоги с файлами типа waaay-to-many.
При очистке: просто, рекурсивно пропустите каждый каталог, удаляя точечный файл.
Да, это уродливый взлом. Если я скоро найду лучший ответ, я отредактирую заново. А пока это решает проблему.
Не уверен, действительно ли вы хотите использовать rsync или просто сохранить преимущества инкрементного резервного копирования.
Если вам просто нужны преимущества, многоплатформенная система резервного копирования (например, bacula) может быть хорошим решением. Он будет делать только инкрементные резервные копии - если это то, что вы хотите - но он сохранит все в одном (или нескольких) больших файлах (а не в зеркале оригинала). Опять же, не уверен, хотите вы этого или нет.