Skip to main content

Internal error 4 after upgrade from 12.0 to 12.5

Thread needs solution
I have management server 12.0 on one server (2008 R2 SP1), and agent 12.0 on second server (2008 R2 SP1).
I manually uninstalled management server and agent, and install clean 12.5
I created new backup plan - weekly full backup all logical drives on second server to network share on third server
But backup task runs 2 hours and finished with error:
{4}
internal error
 
I made three attempts to backup, but only one finished successfully. With 12.0 agent this backup job finished at 50 min
What internal error 4 means?
 
Collected logs I send to support incident 03002126
0 Users found this helpful

I was able to reproduce this bug on test virtual machine.
Backup task may fail to backup logical drive with many files (236 GB, 710615 files). And 552000 stored it single directory.
I tried to backup test virtual machine twice. First try was successfull, but second try failed with internal error.

Error description from Application Windows log:

Событие 0x900001: Код ошибки: 14
| Не удалось выполнить задание "Full backup". TOL: Failed to execute the
| command. Резервное копирование Дополнительные сведения:
| --------------------
| Код ошибки: 22
| Модуль: 309
| LineInfo: 8d165e86fb81959b,
| k:\7048\enterprise\common\tol\command\command.cpp,
| Tol::`anonymous-namespace'::MakeFailResult, 461
| Поля:  CommandID : 8F01AC13-F59E-4851-9204-DE1FD77E36B4, $module :
| service_process_vsa64_7048
| Сообщение: TOL: Failed to execute the command. Резервное копирование
| --------------------
| Код ошибки: 22
| Модуль: 309
| LineInfo: 8d165e86fb81959b,
| k:\7048\enterprise\common\tol\command\command.cpp,
| Tol::`anonymous-namespace'::MakeFailResult, 461
| Поля:  CommandID : 8F01AC13-F59E-4851-9204-DE1FD77E36B4, $module :
| gtob_backup_command_addon_vsa64_7048
| Сообщение: TOL: Failed to execute the command. Резервное копирование
| --------------------
| Код ошибки: 3
| Модуль: 329
| LineInfo: 1cd98aae889424f9,
| k:\7048\enterprise\managers\gtob\util\impl\convert_batch_result.cpp,
| Gtob::Backup::ConvertBatchResult, 58
| Поля:  $module : disk_bundle_vsa64_7048
| Сообщение: Сбой при резервном копировании.
| --------------------
| Код ошибки: 1060
| Модуль: 1
| LineInfo: b43e776571144def,
| k:\7048\processor\diskadm\da_operation.cpp,
| DaProcessor::OperationImpl::Execute, 203
| Поля:  $module : disk_bundle_vsa64_7048
| Сообщение: Не удалось подтвердить операции.
| --------------------
| Код ошибки: 52
| Модуль: 7
| LineInfo: 30ba355f9fd4ff2c, k:\7048\core\resizer\archive3\utils.cpp,
| `anonymous-namespace'::ArchiveWriterImpl::Write, 219
| Поля:  function : archive_stream_write, code : 5100, $module :
| disk_bundle_vsa64_7048
| Сообщение: internal error
| --------------------
| уровень трассировки: ошибка

 

After change archive type from default tibx to tib - backup task is complited in 50 minutes without errors. Previous attempts to backup same server in tibx - took ~2 hours

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi,

The problem indeed appears to be related to archive format and likely is caused by specifics of the VM being backed up - thank you for the details on that. As far as I can see the work on your submitted support ticket is in progress, so let's continue the investigation in there. I'll also make some recommendations to our support team (we need to try reproducing the problem in our QA lab).

Thank you.