IMG folders are not beeing deleted on network share

[FrancescoC]

Hi all,

IMG folders are not beeing deleted on network share, even if there are expired. This happens since about three weeks now. Before it was working without any problems (then on Version 16) a very long time. After one week I have seen this issue, I've upgraded the Version to 20 with the hope to solve this issue - but nothing changed in behavior.

Has anybody a hint or any idea where to search ?

(I have two systems with the same issue - since the same period)

Thank You.
Francesco

[Gurvinder]

Test the following -

1) create a new local disk storage. Take a backup and expire that set. Does it get deleted ? ( you can check the audit log to confirm ) this is just to ensure BE DLM, which expires and deletes the set is working. If not, ensure DLM is enabled https://www.veritas.com/support/en_US/article.000021156

2) in the network share, go to backup sets section. Right click on the expired set and check if any dependant set exists ? If not, try to expire the set by right click -> expire, does the set go away ?

3) if only IMG folder is not getting deleted just check the content of the folder. Is nothing deleted from the folder. Is something locking the files when BE tries to delete the IMG ?

[FrancescoC]

to 1) Local Storage: Took a Backup to a local Storage. Then I tried to let it expire. The Database set forst didn't go away. After Restarting all the BackupExec Services, there was a purge of the Database entries as well as on the local files (including the IMG folders). The DLM is enabled (I checked back with the registry)

to 2) there is no way to get rid of the IMG files there (even if I reastart all the Backup Exec Services)

to 3) the strange thing about is, that only the IMG folders are not deleted. There is no concurent transaction, neither any files are locked or write protected inside the IMG folder.

The most strange thing is, that both installation behave the same. One Installation is a virtual machine with Windows Server 2008 R2, and the other is a virtual machine with Windows Server 2016. Both virtual machines are Backup Domain Controllers.

Mysterious to me is, that from June 28th onwards, this behaviour exists. Installation of two Windows Updates on the Windows Server 2008 R2 machine took place on June 27th (KB4291493 and KB4284842). On the Windows 2016 machine there where no updates running during this period.

Maybe I have one more other hint: The IMG folders normaly are numbered consequently upwards. My IMG folders are all in the range of i.e. IMG000129 - IMG000134. I do daily full backups on a NAS share with different store names (\\NAS\share\night monday\, \\NAS\share\night tuesday\, and so on). We do this procedure for at last five years without a problem. We didn't have any other system outages during this period (no uncontrolled power loss or so).

Thanks for any further help
Francesco

[Colin_Weaver]

For your tests

You need to run a GRT enabled backup, then maybe 2 hours later run the job again and then wait for the expiration of the first backup. (after it has expired you may have to wait up to an hour) The rules of last recovery chain will not delete the IMG if it is the last copy of a given backup set (and this may include incremental chains)

---

Also for your daily jobs

Have you created different backup definitions or just created one definition with either a repateing schedule or separate configs for each day (within that single definition)

We do not recommend separate job definitions per day as it creates a last recovery chain against each day of the week instead of only maintaining the set from the last backup as being the only last recovery chain  (which then means reclaim operations may not happen when you expect.)    In fact we no longer recommend the disk storage device per day setup you are using either as that was something that made more sense before DLM and things like GRT capabilities were introduced

------

Note: if this does info does not halp you, for us to understand exacty what you are doing and what the issue is, I think a formal support case will be needed.