Перейти к содержимому


Фото
- - - - -

DrWeb 10 и Time Machine под OS X 10.9.5 Mavericks


  • Please log in to reply
10 ответов в этой теме

#1 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 26 Сентябрь 2014 - 02:57

Всем здравствуйте,

 

С первого раза обеспечить возможность резервного копирования на Apple Time Capsule G5, увы, не удалось.

 

Сразу после установки (так сложилось, что Time Machine в это же время начала резервное копирование) DrWeb попытался переместить с резервной копии найденые там файлы в карантин, но ему не хватило на это прав, но ругани было много.

 

После внесения исключений в настройки Time Machine и в настройки DrWeb по образу и подобию предыдущих версий DrWeb <http://forum.drweb.com/index.php?showtopic=292642#entry416928>:

  1. Time Machine (места расположения карантина изменились, пришлось угадывать):
    1. ~/.com.drweb.quarantine
    2. ... для других пользователей
    3. /"Library/Application Support/DrWeb/quarantine"
    4. ~/"Library/Application Support/DrWeb/quarantine"
    5. ... для других пользователей
  2. DrWeb (на основании выдачи `tmutil destinationinfo' и `tmutil machinedirectory':
    1. "/Volumes/Резервные копии Time Machine"
    2. "/Volumes/Резервные копии Time Machine-1"
    3. ...
    4. "/Volumes/том"
    5. "/Volumes/том-1"
    6. ...
    7. "/.MobileBackups"
    8. "/Volumes/MobileBackups"

 

Ругань прекратилась, но процесс не пошел. А именно:

  1. При "tmutil enablelocal" подготовка резевной копии проходит, но копирование движется со скоростью нескольких мегабайт в час (если вообще движется);
  2. А при "tmutil disablelocal" процесс подготовки резервной копии замирает.

 

Ясное дело, если отключить "Spider Guard" резервное копирование происходит нормальным обычным образом.


Сообщение было изменено Serge3leo: 26 Сентябрь 2014 - 03:02


#2 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 26 Сентябрь 2014 - 03:06

P.S.

Использовалась демонстрационная лицензия на 30 дней.

 

P.P.S.

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


Сообщение было изменено Serge3leo: 26 Сентябрь 2014 - 03:10


#3 Dmitry Volkov

Dmitry Volkov

    Poster

  • Dr.Web Staff
  • 1 034 Сообщений:

Отправлено 26 Сентябрь 2014 - 13:59

В рамках проводимого тестирования на наших устройствах выполняется процесс резервного копирования без видимых проблем (угрозы блокируются спайдером и не попадают в бекап).

У вас, я так понимаю, уже были угрозы записаннные на тайм капсулу и происходит попытка их синхронизации?

Какое поведение у вас, если на устройствах нет угроз совсем?

Какой объем синхронизируется и сколько это занимает времени у вас и сколько занимает времени с выключенным спайдером?



#4 Vasbor

Vasbor

    Newbie

  • Posters
  • 8 Сообщений:

Отправлено 27 Сентябрь 2014 - 01:52

На 9-ой версии Dr.Web, кстати, подобная проблема тоже присутствовала / присутствует.

Т.е. копирование 3-5 Гб внезапно может растянуться чуть ли не на сутки, да еще и прерваться под конец из-за "неизвестной ошибки". Происходило подобное достаточно регулярно.

Полная проверка  системы на наличие угроз, с последующим созданием  резервной копии заново, проблему не решило.

В результате, обязательное отключение Dr.Web перед резервным копированием, уже давно вошло в привычку.



#5 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 27 Сентябрь 2014 - 20:15

В рамках проводимого тестирования на наших устройствах выполняется процесс резервного копирования без видимых проблем (угрозы блокируются спайдером и не попадают в бекап).

Вы тестируете резевное копирование на сетевую файловую систему AFP, как у Time Capsule?
(замечу, что "блокируются спайдером и не попадают в бекап" - спорное положение, т.к. базы обновляются ещечасно, а резевные копии хранятся годами)

 

У вас, я так понимаю, уже были угрозы записаннные на тайм капсулу и происходит попытка их синхронизации?
Какое поведение у вас, если на устройствах нет угроз совсем?

  • Проверить пока затруднительно, т.к. для этого надо как-то высвободить место на Time Capsule для эксперимента;
  • С другой стороны, установлены исключения, как в TM на предположительные папки с карантином (они, кстати правильные? "/Users/пользователь/.com.drweb.quarantine" ?), так и DrWeb на используемые сетевые тома.

Какой объем синхронизируется и сколько это занимает времени у вас и сколько занимает времени с выключенным спайдером?

 

Размеры:

XXXX$ df -h
Filesystem                                                         Size   Used  Avail Capacity   iused    ifree %iused  Mounted on
/dev/disk0s2                                                      828Gi  774Gi   53Gi    94% 203084283 13957145   94%   /
devfs                                                             200Ki  200Ki    0Bi   100%       691        0  100%   /dev
/dev/disk0s4                                                      732Mi   27Mi  706Mi     4%      6820   180678    4%   /Volumes/FB10XXXX
/dev/disk0s9                                                       77Gi   66Gi   11Gi    86%    403949 11481675    3%   /Volumes/BOOTCAMP
map -hosts                                                          0Bi    0Bi    0Bi   100%         0        0  100%   /net
map auto_home                                                       0Bi    0Bi    0Bi   100%         0        0  100%   /home
//XXXX@time-capsule-XX\.XXX\.XXX._afpovertcp._tcp.local/XXXX      2.7Ti  2.6Ti  146Gi    95% 693892211 38150135   95%   /Volumes/XXXX
/dev/disk2s2                                                      2.7Ti  2.6Ti  145Gi    95% 693874803 38141943   95%   /Volumes/Резервные копии Time Machine

Типичные времена резервного копирования со DrWeb версии 9, как со включённым спайдером, так с выключенным, составляют от 5-7 минут (если почти ничего не изменялось и всё хорошо), до часа-полутора (если TM решает сверить копии, при прерывании предыдущего копирования). Хотя это время трудно предсказать и оценить, т.к. оно зависит от многих факторов.

Однако, замечу, что в любом случае присутствует сетевая и дисковая активность. А пока, при включенном DrWeb 10 версии, копирование замирает без значимой сетевой и дисковой активности.



#6 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 27 Сентябрь 2014 - 20:22

На 9-ой версии Dr.Web, кстати, подобная проблема тоже присутствовала / присутствует.

...

В результате, обязательное отключение Dr.Web перед резервным копированием, уже давно вошло в привычку.

 

Тоже метод, однако, лично мне, неизвестно как TM перевести в чисто ручной режим. Или как повесить команды остановки/запуска  DrWeb на работу TM.

 

Во-вторых, пропадает удобство ежечасных локальных snapshot-ов.

 

Впрочем, у меня с 9-ой и предыдущими версиями DrWeb, после установки исключений для DrWeb и TM, проблем резервного копирования не было.


Сообщение было изменено Serge3leo: 27 Сентябрь 2014 - 20:24


#7 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 27 Сентябрь 2014 - 22:13

Прошу прощения,  я - господин "соврамши".

 

Типичные времена резервного копирования со DrWeb версии 9, как со включённым спайдером, так с выключенным, составляют от 5-7 минут (если почти ничего не изменялось и всё хорошо), до часа-полутора (если TM решает сверить копии, при прерывании предыдущего копирования). Хотя это время трудно предсказать и оценить, т.к. оно зависит от многих факторов.

Впрочем, у меня с 9-ой и предыдущими версиями DrWeb, после установки исключений для DrWeb и TM, проблем резервного копирования не было.

 

У меня до сих пор нормально работала 6.х



#8 Vasbor

Vasbor

    Newbie

  • Posters
  • 8 Сообщений:

Отправлено 28 Сентябрь 2014 - 01:05

Тоже метод, однако, лично мне, неизвестно как TM перевести в чисто ручной режим. Или как повесить команды остановки/запуска  DrWeb на работу TM.

 

Во-вторых, пропадает удобство ежечасных локальных snapshot-ов.

 

Впрочем, у меня с 9-ой и предыдущими версиями DrWeb, после установки исключений для DrWeb и TM, проблем резервного копирования не было.

 

 

Если вам действительно необходимы ежечасные бэкапы, тогда понятно, что каждый раз вручную отключать Dr.Web - это крайне  неудобно.

Мне в этом плане проще - необходимость в бэкапах возникает лишь раз в несколько дней. Т.е. ТМ у меня вообще выключена, а когда надо - запускаю её в строке меню через "Создать резервную копию сейчас", предварительно отключив Dr.Web. После чего, ТМ создает копию и снова выключается.

Одно время, еще  пользовался утилитой TimeMachine Editor, настроив её на создание копий в определенные дни недели и часы, и привязав ко времени регулярного бэкапа уведомления из календаря - чтобы успеть вовремя отключить Dr.Web :-) Но позже, мне этот вариант показался слишком сложным :-) и в результате перешел на полностью "ручной" режим.



#9 Dmitry Volkov

Dmitry Volkov

    Poster

  • Dr.Web Staff
  • 1 034 Сообщений:

Отправлено 29 Сентябрь 2014 - 13:58

Разработчики и тестировщики анализируют сейчас данную проблему. Будет новая информация - отпишемся.



#10 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 29 Сентябрь 2014 - 19:45

Если вам действительно необходимы ежечасные бэкапы, тогда понятно, что каждый раз вручную отключать Dr.Web - это крайне  неудобно.
Мне в этом плане проще - необходимость в бэкапах возникает лишь раз в несколько дней. Т.е. ТМ у меня вообще выключена, а когда надо - запускаю её в строке ...

 
Мне остаётся только завидовать, как в плане внутренней дисциплины и аккуратности. В Mac OSX, конечно отличный механизм UnDo (Cmd+Z), но для операций с файлами и папками его глубина невелика, да и в командной строке его, увы, вовсе нет.
 
Так и в плане предусмотрительности, у меня же всякое бывало, и водкой заливал, и воровали.
 
Что ж до реальной необходимости частых резервных копий, то перефразируя известного персонажа: "Да, данные пропадают, но это было бы ещё полбеды. Плохо то, что они иногда внезапно пропадают, вот в чём фокус!". И, наверное, то что уже многие и многие годы использую Mac OSX - это в основном Time Machine. Я ей благодарен и в неё верю, с ней возможно на просьбу "Очень нужен компьютер", просто залезть в рюкзак и сказать: "На, дарю, пользуйся".
 
А каждый час или нет, это не очень важно. Сейчас взглянул, резервные копии на внешний диск (Time Capsule), уходят не каждый час, а реже:
XXX:~ XXX$ tmutil listbackups
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2013-11-16-074838
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2013-11-23-043605
...
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-28-235022
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-002635 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-013612 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-024326 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-035202 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-050119 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-060849 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-113844 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-145101 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-154527 
/Volumes/Резервные копии Time Machine/Backups.backupdb/XXX/2014-09-29-171053
 
А в локальные резевные копии, чаще:
XXX:~ XXX$ ls -l /Volumes/MobileBackups/Backups.backupdb/XXX/
total 10
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-092330
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-100418
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-110520
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-134342
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-135624
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-140300
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-140815
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-144119
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-154307
drwxr-xr-x@ 3 root  wheel  102 Sep 29 19:37 2014-09-29-170833
lrwxrwxrwx  0 root  wheel    0 Sep 29 17:08 Latest -> 2014-09-29-170833
XXX:~ XXX$ sudo sh -c 'du -mcsx /.MobileBackups/Computer/*'
14	/.MobileBackups/Computer/2014-09-29-092330
1	/.MobileBackups/Computer/2014-09-29-100418
30	/.MobileBackups/Computer/2014-09-29-110520
26	/.MobileBackups/Computer/2014-09-29-134342
15	/.MobileBackups/Computer/2014-09-29-135624
19	/.MobileBackups/Computer/2014-09-29-140300
17	/.MobileBackups/Computer/2014-09-29-140815
6	/.MobileBackups/Computer/2014-09-29-144119
14	/.MobileBackups/Computer/2014-09-29-154307
7	/.MobileBackups/Computer/2014-09-29-170833
144	total

Сообщение было изменено Serge3leo: 29 Сентябрь 2014 - 19:48


#11 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 20 Октябрь 2014 - 03:23

Какое поведение у вас, если на устройствах нет угроз совсем?

Я вроде бы узнал, как "проредить" резервные копии и высвободить несколько сотен гигабайт на сетевом томе резервной копии. Этот эксперимент с drweb-1001-mac.dmg ещё имеет смысл?
# eval tmutil delete `tmutil listbackups | awk '{ l=$0; if(0 == i%2) { print l; }; i++ }' | sed -e 1d -e '$d' -e 's/.*/"&"/'`
Заметил ещё одну особенность Time Machine, которая создаёт SPARSEBUNDLE с параметрами по умолчанию, т.е. в одном каталоге "/Volumes/<имя тома>/<имя компьютера>.sparsebundle/bands" для моего случая создаётся около 300000 файлов по 8 МиБ, каждый. Предполагаю, эти файлы постоянно открываются/закрываются в процессе работы TM. Это может порождать проблемы в Dr.Web в случае если "/Volumes/<имя тома>/<имя компьютера>.sparsebundle" внесён в исключения?

Я встретил рецепты, как уменьшить это число, например, до 20000 файлов по 128 МиБ. Такое уменьшение может повлиять на Dr.Web?

Сообщение было изменено Serge3leo: 20 Октябрь 2014 - 03:24



Читают тему: 1

0 пользователей, 1 гостей, 0 скрытых