[RESOLVED] Full Backup after vmProtect 8 Upgrade ?
Hello,
today we start the first time our backup-tasks after the upgrade from vmprotect 7 to vmprotect 8.
we see that the tasks, especially our big windows 2008 r2 task, are running much longer than expected for an incremental backup and the weeks before with vmprotect 7.
after the backup completion we look in the "recovery points" view of the vm's and see that there is a recovery point with the same size like the initial full backup (you can see this in the attachment).
is this the normal behavior after the upgrade ?
sincerely yours
sven
Issue resolved here.
Attachment | Size |
---|---|
recoverypoints.jpg | 22.88 KB |

- Log in to post comments

Hello,
i have attached the logs from our appliance.
I can't see an error in the logs. Our tasks were completed successfully and the tib-file has nearly the same size as before the Tasks. I think this is caused by dedup ?
The warnings in the logs results from old vmware-tools. we're upgrading at the moment from vsphere 5.0 to 5.1.
I'm curious about what the appliance will do this Weekend when our Jobs are running.
Sincerely yours
Sven
Attachment | Size |
---|---|
116820-104734.zip | 129.42 KB |
- Log in to post comments

Hello again,
today our 3 tasks for our test-environment have finished.
We see that the appliance creates incremental backups, but we also see that our retention rules were not used.
as you can see in "retention_policy.jpg" we have created a rule that deletes the oldest backup after we have more than 4 backups of a vm.
in "recovery_points.jpg" you can see that we now have 6 recovery points of a vm. it seems that he creates a whole new backup-chain.
i think this is why the appliance generates complete new ".lck" and ".x_backup.lck" files on the datastore. you can see this in "files_in_backup_1 and 2".
the creation dates 10.11.2012 and 11.11.2012 reflects the dates then our tasks first run afte the upgrade.
sincerely yours
sven
Attachment | Size |
---|---|
116923-104767.jpg | 25.62 KB |
116923-104770.jpg | 24.62 KB |
116923-104773.jpg | 98.96 KB |
116923-104776.jpg | 52.72 KB |
- Log in to post comments

Hello Sven,
Thank you for keeping us posted.
Here is what the logs that you posted showed:
According to the log the retention rules were last run at the following dates and archives:
<evt msg="25 Backup(s) wurde(n) aus dem Archiv Prod_Windows2008R2_Archiv.TIB gelГ¶scht." j="00000018" tm="11/11/12 07:00:54.381" tp="I"/>
<evt msg="8 Backup(s) wurde(n) aus dem Archiv Prod_Windows2003_Archiv.TIB gelГ¶scht." j="0000000E" tm="11/11/12 04:00:14.355" tp="I"/>
<evt msg="3 Backup(s) wurde(n) aus dem Archiv Prod_Windows2008_Archiv.TIB gelГ¶scht." j="00000017" tm="11/11/12 03:00:08.789" tp="I"/>
<evt msg="1 Backup(s) wurde(n) aus dem Archiv Prod_Linux_Archiv.TIB gelГ¶scht." j="0000000B" tm="11/11/12 02:00:03.834" tp="I"/>
------------------
<evt msg="14 Backup(s) wurde(n) aus dem Archiv Test_Windows2008R2_Archiv.TIB gelГ¶scht." j="00000008" tm="10/11/12 04:00:21.289" tp="I"/>
<evt msg="1 Backup(s) wurde(n) aus dem Archiv Test_Windows2008_Archiv.TIB gelГ¶scht." j="00000001" tm="10/11/12 03:00:04.565" tp="I"/>
<evt msg="3 Backup(s) wurde(n) aus dem Archiv Test_Windows2003_Archiv.TIB gelГ¶scht." j="00000009" tm="10/11/12 02:00:05.421" tp="I"/>
------------------
The retention rules looks like were not applied properly on the last task run on this weekend which we need to check. The previous log contains messages until 16.11.2012, while we need to check the log for 17th and 18th of Nov. Can you please collect the same log once again and attach it here, so that we can check it?
Please also send us the contents of /var/lib/Acronis/vmProtect folder (packed in .zip) from the Virtual Appliance which can be collected as described in troubleshooting section of this article.
What concerns the long run time of the 1st backup after upgrade – we will check it with our QA team to see if we can reproduce similar behavior.
You can always contact me via a private message to send me the logs.
Please let me know if you have additional questions.
Thank you.
- Log in to post comments

Hello Sven,
After additional investigation we found the following issue. There is no need to collect the diagnostic information that I requested from you above.
After additional investigation we have found the following: the issue with the long backup time (1st time backup into existing archive after upgrade) is caused by the fact that the VMs identification architecture has been changed in the 8th version. Therefore the VMs IDs recorded in the existing archive (created with 7th version) are not applicable to 8th version. This means that the 1st backup after upgrade is like adding new VMs into existing archive (even though these VMs are the same ones, they are considered by the product as different ones due to changed IDs) and therefore the whole base archive needs to be re-read in order to apply the new data into the archive. This causes the 1st time backup task to run for approximately the same time as the full archive, however the size (due to deduplication) of the created recovery point is in fact a small one (equal to usual incremental recovery point size). The size shown on UI (size of Full recovery point) is not correct and does not reflect the real situation. Also the retention rules application is also affected by the same root cause (changed IDs architecture), i.e. they are calculating whether to remove the recovery points basing on the 1st recovery point created after the upgrade, so in your case you will see 4 more incremental backups created and only after that the recovery points will be rotated starting from that 1st recovery point created with 8th version.
In other words this is a one-time only issue which indeed may be confusing, though there is not too much we can do about it, since the architectural changes mentioned above are quite core ones and while they improve all the other aspects of the VMs identifications (i.e. solve multiple different issues), we had to trade off these fixes in expense of the issues described here.
Please note that the retention rules in 8th version are applied in the end of the backup task, while in 7th version they were applied in the beginning which means that with 7th version you always had X+1 recovery points (when your retention rules are set to keep X recovery points). In 8th version you will have the proper amount of recovery points present at each time.
Let me know if there is anything else we can do for you.
Thank you.
- Log in to post comments

Hello,
thanks for your effort in solving our Problem.
we now have deleted all our recovery Points and files to start a new clean backup chain (our backups are only for a complete disaster in our mirrored san's :-))
also thanks for the hint rerlating to the Retention rules.
Sincerely Yours
Sven
- Log in to post comments