We have strange behavior of BE 2015. Environment:
1. BE2015 server with local disks for local disk-based storage. e:\ f:\ g:\ h:\, each logical volume on one HDD.
installed features: Copy Server Configurations,Virtual Tape Library Support,Deduplication Option,Agent for VMware and Hyper-V,Agent for Applications and Databases.
2. Configured disk based storages in BE2015 using local disks and named:
Deduplication disk storage 0001- H:\BackupExecDeduplicationStorageFolder
Disk storage Full- E:\BEData\
Disk storage inc- G:\BEData\
Duplication storage- F:\BEData\
3. Test server being backed up on ESXi named wksmon01. It is just a regulary flat machine with win7 no additional application on it.
4. Test job which backs up virtual machine wksmon01 with options: GRT (for files) + NBD. Two templates: full - uses "Deduplication disk storage 0001", incremantal- uses "Disk storage inc". One stage: duplicate to disk immediate after full backup uses "Duplication storage".
Let's start action!
а. Full backup- passes with no errors. GRT provide restore individual files.
b. Automatically passes duplication stage. No errors.
c. First Incremental backup- passes. No errors.
d. Remove duplication storage:
- make "Duplication storage" to disabled state
- make disk F:\ offline using disk management console
e. Second incremental backup- ERROR. 0xe00095b3 - Unable to create the virtual disk. Full error text in attach.
After a big series of test jobs with different options and different storage i have that:
Incremental jobs start to fail only after removing "Duplication storage" which was used to duplicate baseline full backup. If i change job option to not using GRT than all subsequent incremental jobs runs fine with no errors even after removing "Duplication storage".
If i use "Deduplication disk storage 0001" for both full and incremental jobs with GRT enabled than all subsequent incremental jobs runs fine wiht no error also.
If i use "Disk storage Full" for full backup and "Disk storage inc" for incremental with GRT enabled i also have no errors with all subsequent incremental jobs even after removing "Duplication storage".
incremental jobs with enabled GRT option start to fail after removing "Duplication storage" which was used to copy baseline full backup in case when full backup uses Deduplication disk storage and incremental jobs use Disk storage.
I don't really know case number, because my manager created it. I don't have permissions to open any cases. I receive e-mail from support with subject "RE: 09501639 Backup job failed-VMDK-Error:0xe00095b3 - Unable to create the virtual disk [ ref:_00D30jPy._50038hRQQ5:ref ]".
Just had a look at your case. It is currently with an Advanced-level support engineer and i'll have the case severity increased for a quicker response time. Thanks.
Please configure one job to one type of storage only. Like same type of storage.
When full backup targeted to dedup incremental also should go to dedup only
each storage type has its own storage file system and it understand its own file format.
You need to have one backup job of any selection list full backup and incremental backup should be targeted to same type of storage (Dedup/Disk/Tape)
This is the limitation of each device
Never heard that requirement before.
Always used different types of storage and everything was OK before try to use AVVI+GRT+Dup.
Using same type of storage for full and inc solves issue but it is hard to call this a solution it is more similar to be a workaround.
We have stated it for mixing disk and tape before (which OK tape is is a completely different process so perhaps more understandable)
GRT relies on mounting the image data for the complete backup chain to form a consistent result with incremental sets being added to the mounts of previous chain members back to the full so that we can the extract the individual files or folders inside the GRT set. You canot just mount the incremental set on it's own and this mount proces is used to generate both the catalogs (during the backup) and the restore opations
If you mix disk and dedup in an incremental chain, whilst the backup sets in both locations are valid the way the backup sets are mounted to get at the GRT is different and this potentially causes a problem when trying to join all the mounts in the chain together. Note I say potentially as we probably do need to check the facts with the developers which will have to take place as part of the handling of your technical support case.