Предыстория вопроса - упомянутый NAS - штука древняя как говно мамонта и тупая до безобразия. Одна из первых моделей недорогих рейдов для домашнего пользования. 4 винта. Поддержка производителем прекращена, новые прошивки и плагины уже не пишутся. Больше двух терабайт винты не хавает. Скорость по сети - катастрофически маленькая - на чтение на более 18 МБ/сек, на запись и того меньше - до 9 МБ/сек. Собственно все вышеперечисленное и послужило поводом для приобретения Synology.
Synology был успешно куплен, забит винтами, залит файлом и пр... но паранойя не дает спокойно спать - а не дай Бог че случится - торрентов-то я и новых накачаю, а вот семейный архив фото и видео за ...дцать лет - штука не восстановимая. Старичок Промис показался мне как нельзя более годным для хранения резервной копии критичных данных.
Но не все было так просто - Промис - штука не получившая большого распространения, а в нашей стране вообще нумизматика. И вся насквозь закрытая. Слава Богу за границей пользователей этого у-ва поболе, чем у нас, и коллективный разум все-таки его поборол.
В самой железке предусмотрен некий режим синхронизации между НАС. Но по дебильной логике ее создателей, синхронизацию пользователи должны были проводить только между двумя одинаковыми устройствами и только в отношении всей хранящейся информации - каких-либо механизмов выбора чего-либо производителем не предусмотрено. Слава Богу где-то в описаниях я натолкнулся на инфу, что в основу их закрытой синхронизации положен старый добрый rsync, после чего жить стало сразу же веселее. Попробовал настроить сетевое резервирование на Synology в лоб, указав Промис получателем - и потерпел фиаско. Не проходит авторизация, какие б я комбинации логина и пароля не пробовал. Хоть тресни.
Проблемы следующие - полная непонятность что, как и куда он копирует при резервировании - второго такого у-ва у меня нет. Полные непонятки можно ли эти параметры настраивать и если можно, то как. И даже если вдруг понять что надо делать - как делать, учитывая, что в куцых документах производителя нет никаких ссылок на методику входа в у-во через консоль и даже не описывается сама возможность такового.
Ну, как говорится, гугл и пара вечеров нам в помощь и результат налицо. Самой ценной ссылкой, на которую я набрел, стала вот эта:
http://forums.smallnetbuilder.com/showthread.php?t=5706
Но ничего не заработало все равно. Методом проб и ошибок я проблему решил и ниже выкладываю отредактированный алгоритм на великом и могучем:
Итак, приступим.
1. Заходим на железку через вэб-интерфейс под админом, идем во вкладку Резервная копия, репликация NAS, настройка, ставим галку на Резервный сервис и в окошке Другой IP адрес сервера указываем айпишник своей синологи. Топаем ОК.
2. Идем на вкладку Файл и печать - управление протоколом, смотрим, включен ли доступ по протоколу UNIX/Linux. Если нет - идем на вкладку UNIX/Linux и включаем его.
3. Синолога по умолчании кладет свою резервную копию в папку вида ИМЯ_СИНОЛОГИ_МАК_АДРЕС_ЕЕ_ЖЕ. Но в корне промиса она ее сама создать не сможет, следовательно ей надо помочь в этом. Мне, например, захотелось, чтобы бэкап складывался в папку NETBACKUP - идем на вкладку Файл и печать - Общий доступ к файлам - Создать, выбираем том (по умолчанию - VOLUME1), в окошке Имя папки вводим свое любимое имя (в моем случае, повторюсь, NETBACKUP), проставляем галки возле Windows и Unix/Linux, жмакаем ОК. Именно внутри этой папки синолога и создаст свою.
4. Если мы будем делать резервирование под админом - больше ничего с папками и доступом делать не надо. Но как-то некрасиво это, лучше создать под эту задачу отдельного юзера. ВНИМАНИЕ!!!! синолога почему-то разрешает делать резервное копирование только под пользователями admin, root или rsync!!!, так что мы дополнительно идем на вкладку Пользователи и группы - Управление пользователями - создать пользователя и создаем пользователя rsync. Создаем для него пароль. Затем идем в Файл и печать - Настройки общего доступа - Общий доступ Windows/Macintosh/FTP, выбираем созданную нами папку (NETBACKUP), смотрим, стоит ли напротив нашего свежесозданногоо юзера точка в графе Чтение и запись и стоят ли нужные галки. Если нет - ставим, жмакаем ОК. Перемещаемся на закладку Общий доступ в Unix/Linux, выбираем свою папку, в графе Новый IP адрес вводим айпишник синологи, жмакаем Добавить, контролируем, что он появился в окошке снизу.
5. Получаем telnet/SSH доступ к коробочке. По этому адресу лежит работа неизвестного умельца, собравшего под данное у-во полноценный Dropbear. Там много размышлизмов, нам они все малоинтересны, нам нужен только вот этот файл. Скачиваем его, кладем в любую локальную папку на NAS (я использовал папку DOWNLOAD). Заходим на NAS через вэб-интерфейс под логином admin и соответствующим паролем, идем в меню файл и печать - подключаемые модули приложений на вкладку "подключаемые модули приложений", там выбираем том, где лежит наш файлик (в моем случае, как, видимо, и у большинства, это VOLUME1), папку (в моем случае DOWNLOAD) и в графу "Имя файла" вбиваем точное имя файла - dropbear_005200.ppg. Лучше через Ctrl-C Ctrl-V. Нажимаем ОК. Железка думает, пишет что она BUSY, и через некоторое время пережевывает плагин. Идем на вкладку "Информация", видим установленное приложение Dropbear SSH2 server, если оно уже ON - хорошо, если OFF - нажимаем на кнопу Включить. Ждем пока не включится. Обязательно перегружаем зверька!!! Открываем заранее скачанный PuTTY, вбиваем IP нашей железки, протокол telnet, порт 2380, или SSH, порт 22, коннектимся. Должно появиться стандартное приглашения логина - вбиваем admin, жмем Enter, появляется запрос пароля - вводим пароль админа на этой железке (с которым заходили в вэб-интерфейс, пароль на экране не отображается, так что вводим вслепую и по окончании ввода нажимаем Enter) - вуаля, должно появиться приглашение работать.
6. Это пока еще полдела. Доступ-то есть, прав тока нету. Чтобы получить полный доступ достаточно сделать простейшую вещь, и по вышеприведенной ссылке это написано, но тотальный перевод гугла вкупе с собственной безграмотностью, не позволили мне сделать это сразу.
Итак - набивам в терминальном окне простейшую фразу:
sudo -s
Фсе. Выскакивает повторно то же приглашение, но вы в системе уже не под непонятным ей бесправным admin-ом а с правами root-a.
7. Был бы в системе mc - все было бы вообще просто... Но такового нет, поэтому придется пользовать что есть. А есть там vi. Как говорится "Арфы нет, возьмите бубен". Для тех, кто не в курсах - vi - это такой простейший *nix-овый текстовый редактор, управляемый исключительно текстовыми клавишами. Для общего развития можно спросить у яндекса что-то типа "редактор vi" - вывалится исчерпывающее количество описаний и мануалов.
Далее все делаем очень внимательно. Пишем следующее:
vi /etc/rsyncd.conf
Видим что-то типа этого:
[192.168.1.4] path=/ comment=Backup Server of "192.168.1.4" uid=root gid=root auth users=promise read secrets file=/etc/rsyncd.secrets log file=/var/log/rsyncd.log
Все предыдущие неудачи запуска копирования были связаны с тем, что во-первых с точки зрения Synology почему-то задачи сетевого резервного копирования могут выполнять только пользователи admin, root и rsync. Пользователя promise, как нетрудно заметить, в этом списке нет. Во-вторых, директория для резервного копирования по умолчанию указана /, т.е. - фактически в системную область, или во флеш память, не знаю точно. Ну и в третьих - науке не известен пароль пользователя promise. Т.е. - задача заточена именно под свою узкую специфику синхронизации двух одинаковых НАС-ов.
Значицца делаем следующее. Стрелочками перемещаем курсор на последнюю позицию в строке path=/ - это будет символ "/".
Один раз нажимаем на клавиатуре букву i - это переход в режим вставки.
Один раз нажимаем стрелку вправо - курсор перемещается на пустое место справа от косой черты.
Набираем на клавиатуре VOLUME1 или VOLUME1/NETBACKUP - смотря куда и под кем будет делаться резервная копия, см. ранее. Должна получиться строка path=/VOLUME1 или path=/VOLUME1/NETBACKUP
Нажимаем на клавиатуре Esc - это выход из режима вставки.
Стрелками уходим вниз на 6-ю строчку, там где auth users.
Встаем курсором на букву "p" в слове promise и 7 раз нажимаем клавишу "x" - это удаление, ибо всякие делиты и прочие бакспейсы в этом суровом редакторе не пашут.
Снова нажимаем "i" и вводим admin или rsync - в зависимости от того, что мы там ранее насоздавали, от кого пойдет процесс.
Жмем Esc.
Нажимаем на клавиатуре Shift и, удерживая ее, два раза подряд букву "z" - получится две большие Z подряд - ZZ. Это команда безусловного выхода с сохранением.
Если где-то ошиблись и не знаем как отсюда выйти - из режима вставки выходим через Esc, аварийный выход из редактирования файла вообще - вводим символ двоеточия (это там, где буква ж на клавиатуре, только с шифтом), курсор должен упасть в самый низ экрана, где и появится это самое двоеточие. Далее вводим команду q! (маленькая q с восклицательным знаком) и нажимаем Enter. Все, мы вышли из этого дурного редактора, можно попробовать снова сначала.
После того, как все закончили и сохранились через ZZ - контрольный выстрел - снова вводим
vi /etc/rsyncd.conf
и смотрим, что получилось. Должно получиться как-то так:
[192.168.1.4] path=/VOLUME1/NETBACKUP comment=Backup Server of "192.168.1.4" uid=root gid=root auth users=rsync read secrets file=/etc/rsyncd.secrets log file=/var/log/rsyncd.log
Естественно айпишник у вас будет свой, тот самый, который вы на шаге 1 прописали через вэб-интерфейс.
8. Итак мы решили проблему неправильного пути сохранения и имени пользователя, под которым это самое сохранение будет происходить. Осталась маленькая проблема - сменить, или хотя бы узнать, пароль этого юзера. Придется снова воспользоваться vi. Вводим:
vi /etc/rsyncd.secrets
Видим что-то похожее на:
# RSYNC Authentication File promise:94su394214n3
Синтаксис прост как мычание - первая строка закомментирована, во второй до знака двоеточия - имя логина, после двоеточия - его пароль. Вот этот бессмысленный набор цифр и был тем самым паролем юзера promise, который мы не знали. Что мы тут делаем. Во-первых меняем имя юзера с promise на либо admin, либо rsync, смотря чего мы там решили ранее, во вторых, меняем ему пароль на что-то более удобоваримое. Принцип редактирования тот же. Выходим через ZZ с сохранением, контрольный просмотр что получилось - и вуаля.
С железкой на этом все.
Заходим на синологу через вэб-интерфейс, идем в панель управления - Сетевые службы - Сетевое резервирование, ставим галку на Включить службу сетевого резервирования, отмечаем точкой режим сетевого резервирования rsync, жмакаем ОК. Закрываем панель управления.
Идем в главное меню - резервирование/восстановление, открываем. На первой же вкладке Резервирование жмакаем Создать. Запускается мастер. Имя задачи выбираем произвольно, топаем далее. На вкладке Выберите тип целевой папки выбираем третий сверху пункт - Сетевое резервирование (rsync-совместимый сервер), далее. Попадаем на вкладку Задайте конечный путь резервирования. Первая графа - айпишник нашего промиса. Затем топаем на стрелку справа второй графы - в выпадающем меню вываливается единственный пункт - айпишник самой синологи. Это говорит о том, что именно она сама будет управлять процессом. Соглашаемся. Далее вводим логин-пароль юзера с промиса (admin или rsync соответствнно) и жмакаем кнопу Тестовое подключение. Должно вывалиться окошко "Тестирование подключения выполнено успешно". Если нет - отматываем алгоритм назад и смотрим где мы ошиблись. Если все нормально - проставляем галки по вкусу (сжатие и шифрование я бы не включал - во-первых не факт что синолога и промис подружатся по алгоритмам, а во-вторых тухлый промисовский процессор при обычном простом резервировании загружен на ~80%, Боливар может не вынести двоих. Во всяком случае я эти галки не ставил). Идем далее - выбираем папки, приложения, расписание - это уже по вкусу. Сохраняем задачу и запускаем ее на чем-нибудь маленьком. Смотрим, что пишется в правом верхнем углу окна. Если процесс идет - все намано. Если отваливается сразу не начавшись - мы намудрили либо с именами папок, либо с правами доступа на них, либо с логинами/паролями. Если процесс вроде как начинается, но пройдя считанные доли процента вылетает с ошибкой - значит мы либо зажали квоту юзеру rsync в вэб-интерфейсе промиса, либо пытаемся резервироватся в корень 
Вот как-то так. Чудес от скорости не ждите, по моим прикидкам ~600-700 ГБ/сутки, но это только первый раз так долго - в дальнейшем, если правильные галки проставить, будут гоняться только изменившиеся данные, что на несколько порядков меньше и быстрее.
А теперь ложка дегтя в эту бочку - к сожалению все настройки конфигурационных файлов, которые мы правили ручками при помощи vi слетают при перезагрузке промиса полностью. То есть - эта песня хороша, начинай сначала.
Я знаю, что на этом форуме присутствуют люди, волокущие в *nix-ах существенно больше меня. Подскажите пожалуйста, куда копать?? Может скриптик какой написать, который будет вытаскивать альтернативный конфиг откуда-нибудь??? А положить его куда? Я в этом деле не очень пока, к сожалению... Если пытаться открыть файл rsyncd.conf при выключенном сервере резервирования, то он пуст полностью...
В данный момент это работает у меня под admin-ом в папку NetBackup. Под rsync-ом и в корень тома я сам не проверял - проверю послезавтра.
З.Ы. Еще несколько ссылок по этому экзотическому зверьку... ну чтоб два раза не вставать:
http://www.16paws.com/projects/NS4300N/
http://www.readynas.com/forum/viewtopic.php?f=4&t=42205
http://mizupc8.bio.mie-u.ac.jp/pukiwiki/?Promise%20NS4300N
З.З.Ы. Одна маленькая, но неприятная особенность данного девайса (промис), которая в свое время вынесла мне мозг еще когда я пользовал его в качестве основного НАСа и пытался подключить к нему Дюну по NFS, состоит в том, что как имена томов (VOLUME1,2 и т.д.), так и имена корневых папок необходимо везде указывать в верхнем регистре!!! И даже если ты через вэб-интерфейс создаешь корневую папку в нижнем регистре, система автоматом переводит ее в верхний, например ты пытаешься создать папку NetBackup, а создается в итоге NETBACKUP. Это нужно знать и учитывать во всех случаях прописывания адресов обращения к железке со всех *nix-based устройств. Иначе ошибки неминуемы.
З.З.З.Ы. Послезавтра наступило. Резервирование успешно закончилось. Проблема с утратой нужных конфигов при перезагрузке промиса пока не решена. Резервирование под юзером rsybc опробовано - работает. В корень тома не работает, как и ожидалось... Пост подкорректирован. Рецепт пока один - нефиг перегружаться
З.З.З.З.Ы. По непонятной мне причине крякнутый dropbear может вешать систему на промисе. Выражается это в десятикратном падении скорости резервирования и полностью занятом процессоре, если смотреть через top. Отсюда мораль - попользовались telnet (SSH) доступом на зверька - отключите dropbear через веб-интерфейс.