nunciate wrote:There has to be some logic to determine drive is X% full and to stop backing up to that drive. Is there anything like that because if there is it isn't working.
nunciate wrote:One other big problem I have noticed is that the jobs don't always pick the best extent that matches the size of the VM. I have a large 10Tb VM I am trying to backup to a this scale out repository for the first time. I have 12Tb free on 1 extent, 7Tb free on another and less than 2 on the others. I run the job and it tries to put the backup on the extent with 7Tb free. I kill the job, put that extent into maintenance mode and reran. Now it tries to backup to an extent with less than 2Tb free all the while ignoring the one extent it can actually be successful at using with 12Tb free. Ridiculous. I literally had to put all extents into maintenance mode to force it to the last one and then re-enabled them all.
sdeath wrote:When job has backups files on 2 extents, ext1 and ext2, you won't experience any issue: VBM file will be written to both ext1 and ext2, and if ext1 ran out of space completely, then we will fail to write VBM to ext1 but we will be able to write VBM to ext2 and in this scenario job won't fail - it will detect that it could write at least one copy of VBM.
Now, we have one Backup Copy job writing to two extents so just confirming if it should be working as suggested in the third paragraph....
A.J. wrote:Our latest investigations showed that the copy jobs will fill up a repository extent until 0 bytes free. The next incremental file will be placed on another extent but the merge process will fail because the primary extent of the job has 0 bytes free.
Users browsing this forum: matt1237, Yahoo [Bot] and 16 guests