обновление 14330
наверное, это действительно один из самых лучших апдейтов, которые я когда-либо ставил и пробовал.
1. ушли почти все проблемы с лентами, которые были раньше. раньше это был АД. сейчас тоже остались проблемы, например, с очисткой лент от старых бэкапов (они не очищаются и ссылка на восстановление с них всё-ещё остаётся). или ещё старая проблема с лентами - не виден общий объём данных, которые пишутся. как я понял по другим постам, с подсчётом места есть проблемы не только на лентах, но и просто на storage node с жёсткими дисками. самое главное - ленточник не отваливается, бэкапы пишутся и вообще, стало можно даже зайти на ленту и посмотреть её содержимое. правда, если вы закроете окно и снова попытаетесь посмотреть на содержимое ленты - оно будет пустое. нужно выйти из лент, например, в задачи, потом снова вернуться в ленты и содержимое лент снова можно будет посмотреть. но это всё мелочи.
2. проблема с относительными днями в расписании типа "последняя пятница" - все подобные задачи нужно пересоздавать. раньше они работали чётко, теперь задачи с такими параметрами пропускаются. это мелочи, так как см. п.1 - наконец-то ленты стали работать.
3. проверка резервных копий, созданных ранее. некоторые бэкапы помечаются как "повреждённые", если вы реплицируете бэкап с одного хранилища на другое и проверяете целостность бэкапа в этом "другом месте". проблема возникает только если происходит "репликация". если бэкап идёт напрямую в новое место - проблем с проверкой резервных копий нет. это мелочь, я очень рад п.1 - вот что действительно починили.
4. некоторые агенты могут отвалиться от консоли и стать "серыми". лечится рестартом сервиса акронис на агенте. редко возникает, но было пару раз. возможно, причина в параллельной установке обновлений Windows - как только они перестали приходить и устанавливаться, то и проблема вроде как перестала появляться. посмотрим. а посмотреть есть на что - на п.1.
5. была обнаружена в ранних обновлениях очень опасная проблема - невозможность восстановления агента с помощью web-консоли. например, заходишь в "устройства", выбираешь рабочую станцию или сервер (win7, win2008), выбираешь "восстановить", указываешь любой доступный способ (точку восстановления), нажимаешь ОК (указываешь disk1-disk1) и всё - рестарт, стартует агент Акронис, думает около 2 мин и закрывается. загружается ОС со старым разделом. смотришь на причины - а там ошибки при работе агента - то ОС была перезагружена, то нет доступа к файлам восстановления... суппорт не помог - только рекомендация на обновление. которое и помогло. теперь с web-консоли восстанавливается без проблем, как и работает п.1.
короче, я очень рад, что появился этот апдейт 14330. реально. спасибо команде разработчиков.
п.3 был описан в проблеме "04134435" от 30 августа. поступила рекомендация не реплицировать из storage node в другой storage node, а использовать репликацию в сетевую папку.
а если я хочу использовать все плюсы storage node (особенно дистанционное восстановление через консоль). может быть вы посмотрите - что делается с бэкапами во время репликации, что они в одном месте (изначальном) проверку целостности проходят, а во втором месте (куда их среплицировали) - уже не проходят?
Hello SCH.
There should not be any restrictions on replication from one storage node to another one.
Is deduplication is enabled on the first storage node?
I suppose that support engineers asked you to replicate to a network share in order to localize the issue - to check whether validation is OK when replicating from the storage node to a network shared folder.
Please also read my personal message.
дедупликация выключена и никогда не включалась.
проходят проверку все резервные копии, кроме тех, которые были среплицированы с другого storage node
если есть возможность и желание - поднимите стенд у себя и попробуйте:
1. сервер А (win2016, 14330), главная консоль, поднят storage node, есть ленточник
2. сервер Б (win2016, 14330), поднят storage node, есть ленточник. находится в агентах у сервера А. находится в другой подсети, чем А.
3. сервер Б хранит бэкапы компьютеров своего сайта, включая свой собственный (дедупликация выключена, слияние копий выключено, сжатие обычное, паролей нет, версия файлов 11, срок хранения 2 недели).
4. создана задача в репликациях - сервер Б реплицирует из своего storage node в storage node сервера А все свои бэкапы. ошибок в репликации нет.
5. сервер А запускает задачу "проверки" резервных копий, находящихся в storage node. успешно проходят проверку все бэкапы, кроме среплицированных резервных копий из storage node сервера Б
6. сервер Б запускает задачу "проверки" резервных копий, находящихся в storage node. успешно проходят проверку все бэкапы
наверное, что-то случилось в процессе репликации?
:-/
Hello SCH.
Can you please share with the forum users any success in resolving this issue with replications?
Добрый день, Мария!
никак не решили мы эту проблему. к тому факту, что реплицированные резервные копии с "сервера Б" на "сервер А" не проходят проверку на "сервере А", добавилась новая проблема - при попытке записать данные на ленту со storage node "сервера А", бэкапятся на ленту все резервные копии, кроме реплицированных с "сервера Б".
скриншот прикладываю. не бэкапятся они со следующей ошибкой - "the archive is invalid or type is unsupported".
и ещё заметил такую вещь, которую в прежних версиях не пробовал - в задаче по репликации включили "пароль". пишем задачу, вроде всё норм. решили дописать на этот-же набор лент ещё данные - и не получается... Акронис пытается проверить - не имеются ли эти-же данные на ленте и выдаёт ошибки.
где можно подробнее почитать про это "типа шифрование" лент?
Мария, добрый день!
нашёл ещё одну проблему, связанную с "backup validity". Нашёл чисто случайно, просьба проверить у себя на стенде. В двух словах - Акронис перезатирает поля "логин и пароль" для задания бэкапа, если сделать задание "backup validity".
Исходные данные: 3 сервера: А, Б, В, все три на Windows, на всех стоит 14330 (после апгрейда)
1. на "Сервере А", на котором стоит сервер Акрониса 14330, делается задача - на "Сервера Б" делать резервную копию диска С: в разные "места хранения", одно из мест хранения - сетевая папка на "сервере В". Для доступа в эту сетевую папку используется "логин А" <--- это важно.
2. на "Сервере А", на котором стоит сервер Акрониса 14330, делается новая задача - backup validity со следующими свойствами: агент = "Сервер Б", место проверки = сетевая папка на "Сервере В". в качестве логина используется "логин Б". Задача сохраняется. проверяется её работа - всё норм.
скорее всего, в момент сохранения задания из п.2 Акронис ПЕРЕЗАТИРАЕТ учётные данные к месту хранения, используемые в задании из п.1. Получается, что для одного и того-же места хранения Акронис хранит какую-то центральную базу мест хранения и учётных записей для них. Т.е. Акронис не для каждого задания хранит свои учётные записи.
нашёлся этот факт случайно - в задании по проверки созданных бэкапов был логин, пароль которого истёк. При этом стало фейлиться задание, которое делало бэкапы (и для которого использовался другой логин). это может привести к следующему - не трогая задания по созданию резервных копий можно их испортить, создав задание по проверки созданных резервных копий, указав в них другой логин для тех-же "мест хранения", что используются для резервирования. потом этот логин может быть удалён или просрочен его пароль - и ни одно задание по резервной копии не запустится... :0
и ещё минорное замечание про общий прогресс выполнения задания - делается резервная копия, выставлено "удалять старые резервные копии до начала резервирования", указано 2 или более мест хранения бэкапов.
сам прогресс выглядит так:
1. Удаление резервных копий успешно завершено. Общий прогресс 34%
2. Создана резервная копия в первое хранилище. Общий прогресс 99%
3. создана резервная копия во второе хранилище. Общий прогресс 99%
и т.д.
Т.е. в индикации общего прогресса задания нет учёта кол-ва шагов, которые в задание включены.
ещё хуже работает общий индикатор при выполнении репликации данных на ленту. он всегда показывает 0%, сколько бы данных не залилось.
и ещё одно замечание - при репликации на ленту вы нигде не показывается общий объём данных, которые залился уже на ленту, а показываете только объём предыдущего бэкапа, который туда был скопирован. Но при этом показываете суммарное время. получается, если предпоследний бэкап был объёмом 900 Мб (например, инкрементальный), но для копирования всех резервных копий агента был затрачен 1 час (например, копировалась цепочка двухнедельного бэкапа), то можно сделать ложный вывод, что 900 мегабайт копировались 1 час. если есть возможность - просьба исправить.
SCH wrote:нашёл ещё одну проблему, связанную с "backup validity". Нашёл чисто случайно, просьба проверить у себя на стенде. В двух словах - Акронис перезатирает поля "логин и пароль" для задания бэкапа, если сделать задание "backup validity".
Исходные данные: 3 сервера: А, Б, В, все три на Windows, на всех стоит 14330 (после апгрейда)
1. на "Сервере А", на котором стоит сервер Акрониса 14330, делается задача - на "Сервера Б" делать резервную копию диска С: в разные "места хранения", одно из мест хранения - сетевая папка на "сервере В". Для доступа в эту сетевую папку используется "логин А" <--- это важно.
2. на "Сервере А", на котором стоит сервер Акрониса 14330, делается новая задача - backup validity со следующими свойствами: агент = "Сервер Б", место проверки = сетевая папка на "Сервере В". в качестве логина используется "логин Б". Задача сохраняется. проверяется её работа - всё норм.
скорее всего, в момент сохранения задания из п.2 Акронис ПЕРЕЗАТИРАЕТ учётные данные к месту хранения, используемые в задании из п.1.
Hello SCH,
I've asked our QA team to reproduce this scenario, but they didn't get any errors. Could you please clarify the following:
- "Login A" and "Login B" are located on the same machine (with network shared folder) or these are usernames on different machines?
- Are "Login A" and "Login B" domain logins or local?
We tested a case with "Login A" and "Login B" located on the same machine (with network shared folder) and backup in step 3 was created successfully.
Мария, добрый день!
дайте догадаюсь - у вас и логин А, и логин В имеют доступ к сетевой папке, куда делается бэкап?
а вот если логину В, под которым делается проверка резервных копий на сервере В, запретите доступ на сервер А, то вы получите фейл.
схема хранения учётных записей и их паролей, которую вы создали, работает хорошо, когда все задачи выполняются под одной учётной записью. если в организации есть разделение учётных записей, прав доступа, то вы столкнётесь с тем, что безобидная задача по проверке созданных бэкапов будет ломать задачи по созданию резервных копий.
и ещё одна ошибка, которая тоже выскочила случайно - задачи, у которых выключено выполнение по расписанию (не должны запускаться) в некоторых ситуациях могут таки запуститься сами.
Описание:
Задача №1. выполнялась в тестовых целях - резервная копия рабочей станции А на ленточный накопитель с использованием шифрования. она сначала имела расписание на выполнение (запускаться в 23:00), а потом у неё это расписание выключили. задача, по-идее, не должна была запускаться вообще.
Задача №2, которая выполняется по расписанию - обычная регулярная резервная копия рабочей станции А в storage node.
если в 23:00 задача №2 была активна, то запускалась задача №1.
обнаружилось случайно - зависла задача №2 на шаге "удаление резервных копий". каким-то образом расписание задачи №1 хранится в настройках, хоть оно и выключено. и если что-то делается с рабочей станцией А, то переключатель "нет расписания" игнорируется.
получается, что выключатель расписания имеет недостаток в работе и он не полностью выключает задачу.
Мария, если у вас и эту проблему не удастся поднять на стенде - напишите мне в личку, мы созвонимся и я вас проведу по всем настройкам как этой проблемы, так и других.
SCH wrote:Мария, добрый день!
дайте догадаюсь - у вас и логин А, и логин В имеют доступ к сетевой папке, куда делается бэкап?
а вот если логину В, под которым делается проверка резервных копий на сервере В, запретите доступ на сервер А, то вы получите фейл.
схема хранения учётных записей и их паролей, которую вы создали, работает хорошо, когда все задачи выполняются под одной учётной записью. если в организации есть разделение учётных записей, прав доступа, то вы столкнётесь с тем, что безобидная задача по проверке созданных бэкапов будет ломать задачи по созданию резервных копий.
Thank you for additional information! Reproduced and reported to the RnD (internal ID for reference ABR-250211)
SCH wrote:и ещё минорное замечание про общий прогресс выполнения задания - делается резервная копия, выставлено "удалять старые резервные копии до начала резервирования", указано 2 или более мест хранения бэкапов.
сам прогресс выглядит так:
1. Удаление резервных копий успешно завершено. Общий прогресс 34%
2. Создана резервная копия в первое хранилище. Общий прогресс 99%
3. создана резервная копия во второе хранилище. Общий прогресс 99%
Т.е. в индикации общего прогресса задания нет учёта кол-ва шагов, которые в задание включены.
This behavior is also expected to be corrected in the future versions, I've added your comment as a vote for the change ( internal ID ABR-68302)