Veeam B&R восстанавливаем работу после критической ошибки.

И так, прошлая статья показала, что не стоит делать с ВМ, особенно если вы там организовали хранилище, пусть даже и бекапов (особенно). Далее я получил следующие ошибки:
"Error: Cannot proceed with the job: existing backup meta file 'Germany-Folder.vbm' on repository 'Germany' is not synchronized with the DB. To resolve this, run repository rescan"

Рескан естественно не проходил, потому что бекапы уже туда сложены (по базе данных), а файл .vbm старой версии. Можно было попробовать отредактировать базу данных, но я крайне не рекомендую этого делать. ПОэтому решаем делать так:
удаляем файлы *.vbm со всех папок на уроненом датасторе, затем заходим в репозитории, находим наш репозиторий, проходим рескан заново. После рескана пробуем запустить джоб - не получается, снова ошибка:

Processing SOME_VM_NAME Error: All instances of the storage metadata are corrupted. Failed to open storage for read access. Storage: [\\path\to\Jobe\name\JOB-NAME2020-08-16T011455_0F5C.vib]. Failed to download disk. Shared memory connection was closed. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.      01:42

Что бы решить эту пробелму идём в Home\Backups\Disk, ПКМ по нашему джобу и  Remove from configuration, длее перезапускаем джоб и радуемся уже успешному бекапу. По восстановлению более старых точек просто скажу так, есть копия, кототрая находится на другом хранилище, поэтому данными файлами я могу немного принебречь.

Vmware: почему ручные снэпшоты это плохо.

 Очень редко я пишу, особенно сюда. Но, надеюсь мне будет напоминалка или Вам руководство, ка кделать не надо. Предыстория: есть несколько нод, собранных одним vcentrom разнесены ноды по разным странам: Израиль и Германя. Бекап производится 1 бекап сервером на raid массив на самом бекап сервере (Израиль), копия на файловой windows шаре (Германия). Бекапы с серверов в Германии складываются на шару в Германии и копии летят в Израиль. В какой-то момент было необходимо по какой-то космической причине кому-то (возможно даже мне) сделать снимок на виртуалке с файловой шарой в Германии, которой под thin provision было выдано 4 Tb жёсткого диска из 5.5 возможных. Там же вертелось ещё пара виртуалок. Получив утром сообщение о том, что есть снапшот, который кто-то забыл удалить я решил попробовать это сделать по привычке, прямо из консоли, но не тут то было, удаяться он не особо хотел, ушло на это больше, чем планировалось (больше рабочего дня). На следующий день по понятным причинам не прошли некоторые бекапы и не удалился снепшот, зато появилось сообщение о том, что нужно консолидировать диски.
Пфф, думал я. А зря, консолидация не проходила, т.к. место закончилось, мало того, из-за thin provision ушатался ещё и виртуальный роутер, благодаря которому была построена часть инфраструктуры, вертелся он там же на том же разделе. Ок, если мы не можем совместить данные, давайте попробуем их вырезать (удалить, потерять, как хотите). Тушим машину, удаляем из инвентаря диск на машине (не физически), далее идём по ссх на хост и пробуем переименовать VM_Name_2-000001-sesparse.vmdk, запустить машину, (если удалить или переименовать его не удаляя диска с ВМ - ВМ не запустится!). Машина стартонула, диска вроде нет, ок, теперь вручную добавляем существующий диск - получилось. Заходим в машине в диск менеджмент и делаем снова диск онлайн - получилось. Теперь проверяем диск (можно даже онлайн) - прошло успешно за пару сек - прекрасно. Теперь смотрим на дату измененя файлов .vmdk, интересует наш (в конкретном случае VM_Name_2-flat.vmdk - дата стоит сегодня и время почти актуальное, только теперь можно удалить переименованный VM_Name_2-000001-sesparse.vmdk.bak, освободив при этом достаточно места что бы жить дальше. А дальше предстояло восттановить работу бекапов...