Jump to content
XPEnology Community

Denn

Rookie
  • Posts

    8
  • Joined

  • Last visited

Posts posted by Denn

  1. Добрый день!

    есть такая схема: Cloud Station server на облаке, на земле два DSM с запущеным Cloud Station ShareSync, и с обоих папки (разные) синхронизируются на облачный сервер.

    До недавнего времени эта схема работала без нареканий. НО, с недавних пор на Cloud Station ShareSync стало постоянно висеть "Синхонизация" с указанием количества файлов. Ну и фактически синхронизация происходит непонятно как, - то некоторые файлы синхронизируются быстро, то вообще не дождешся...

    На момент появления проблемы, синхронизируемых файлов на сервере было под 300к., уменьшение общего количества до ~200к. - результата не принесло.

    Поиск по данной проблеме ничего не дал. (или я плохо искал)

     

    Может кто сталкивался? подскажите пожалуйста, что делать?

     

    ЗЫ: DS3615xs все, изначально везде версия 6.1.7, обновление до 6.2.3 и Cloud Station до Synology Drive Server результата не принесло.

    ЗыЗы: похоже я ошибся разделом, Администраторы - тему наверно надо перенести в "Программное обеспечение" ?

     

    syno1.jpg

    syno2.jpg

  2. Кто нибудь знает, возможно ли установить (восстановить) версию 6.2.3 на ESXi ?  для DS3615xs

     

    Для себя, пока понимаю так:

    на загрузчик 1.03b можно установить версию 6.2 (обязательно МАК в грубе привести в соответствие с сетёвкой)

    далее при обновлении на версию 6.2.3 - выдает ошибку "файл поврежден", нужно подсовывать скрипт FixSynoboot.sh , в соответствии с

    - после этого обновление до версии 6.2.3 проходит успешно, и далее  до 6.2.3 up3  - также успешно.

     

    А вот теперь, в случае краха системы, - ничего сделать нельзя!?

    - если есть только загрузчик (но нет системы или она повреждена) установить/восстановить ОС невозможно, - если подсовываешь файл версии 6.2.3 - говорит "файл поврежден", если файл версии ниже - пишет "необходимо использовать файл установки 6.2.3-25426 или более поздний"...

    для себя отметил, что при установке версии 6.2.3 файлы в загрузочном образе (synoboot 50MB) меняются, уже другой размер и даты изменения.

     

    Сценарий восстановления вижу так:

    1. Установка новой DSM 6.2 на загрузчик 1.03b

    2. Применение скрипта FixSynoboot.sh и обновление до 6.2.3

    3. Восстановление настроек DSM через файл бекапа настроек старой DSM.

    4. Подключение дисков старой DSM в новую.

    юзаем восстановленную DSM.

     

    Если кто-то может что-нибудь подсказать - милости прошу.

     

  3. Протестировано опытным путем, на DSM 6,2 обе версии утилит приостанавливают запись на диск при получении снапшота (с сотоянием ФС) в гипервизоре.

    НО ! Windows не может возобновить/продолжить копирование на DSM, только новая попытка.

  4. Нужна помощь по сабжу (кто какую версию использует?):

    Здесь на форуме упоминаются ссылки на  spk.4sag.ru  где на данный момент лежит версия open-vm-tools v10.2.0-1

    https://spk.4sag.ru/packages/open-vm-tools_x64-6.1_10.2.0-1.spk    размером 4,5 МБ, и здесь же на форуме писали, что данный пакет решает вопросы управления питанием и heartbeat гостевой DSM.

    На ГитХабе нашлась 11 версия утилит  https://github.com/leonardw/synology-open-vm-tools/releases   , аж целых 4 релиза, размером 17,5 МБ !!! где в описании нормально расписан весь перечень возможностей этого пакета.

     

    Меня в первую очередь интересует блокировка дисковых операций в гостевой DSM, гипервизором (VMware ESXi) когда он выполняет снапшот/консолидацию/удаление снапшота.      

     

    Вопросы:

    1) Умеет ли блокировать дисковые операции VM tools с сайта spk.4sag.ru ? (размер 4,5 МБ)

    2) Использует ли кто VM tools с ГитХаба ? (размер 17,5 МБ)

     

    ЗЫ: Если модератор посчитает, что сабж не достоин отдельной темы, - перенесите в подходящую тему.

    ЗыЗы: Для меня это оказалось очень важным: недавно ночью рассыпалась ФС на одном разделе (отдельный vmdk 2ТБ), VM tools не было никаких, на этот раздел складываются бекапы баз и папок. Так же ночью делаются полные бекапы всех ВМ.  Предположительно, при консолидации после бекапа на гипервизоре (в это время велась активная запись на раздел в  гостевой DSM) произошло или рассогласование или конфликт блокировок, но консолидация окончилась ошибкой, ФС в гостевой DSM на этом разделе пострадала.

    Машину из предыдущего суточного архива восстановили, но вопрос - как не допустить подобного в будущем - актуален.                     

×
×
  • Create New...