Jobs failing after updating to v6

[seiniku]

Has anyone seen some (not all) of their jobs fail after updating to v6? A few of mine fail when they attempt to create the vbm file at the start of the job, claiming that access is denied. The repository is a local folder, and the service account does have read/write access. Logs show that the vbm file's content is generated, but fails to write to the file using the RPC function DoRpcWithBinary.
Any suggestions as to what the fix could be? I really would like this resolved before the weekend starts and haven't gotten any suggestions from support yet on ticket ID#5163841.

Thanks for any help you can provide,

Justin

[Gostev]

Hmm, strange. Is your service account a member of Local Administrators? I have no immediate idea what this could be, except some weird custom NTFS permission, or security policy on this server. Definitely have not heard anything similar. To start, I personally would try create new folder and new repository pointing to it.

[seiniku]

The account is a local admin, and permissions seem to be the same as other jobs that are working.
I attempted to make a new repository and point the old job at the new location, but it kept saying that all the backup files were not present (even after I moved them).

My next step was to make a new job and have it use the new repository, which worked in a way that I didn't expect. The new repository was at E:/backups/new, the job created a folder like E:/backups/new/job1. That isn't how the broken repository is working. The old one is configured similar to E:/backups/new/job1 and places it's files without making another directory. Perhaps that is part of the problem.

In any case, the new job does work. I'm fine with having new jobs/repositories as long as it works. If I go that route, how do I keep my existing backups useful? Is there a way to have the retention policy purge them as they get older?

[Gostev]

OK, glad it worked. This could be some upgrade-related issue then. No, unfortunately retention of "new" jobs will not be purging any "old" jobs - you would have to be removing those "old" backups manually.

[seiniku]

Sounds good. What's the best way to remove them manually? Just delete the files through windows explorer? What are the chances that there is an awesome powershell script floating around for this?

Thank you very much for the help, Gostev. It is much appreciated

[Gostev]

Best is to remove using the backup console, otherwise records about those backups will still remain in the configuration database. You just right-click the backup, and choose Delete from Disk. Why complicate such a simple task with a PowerShell script?

[seiniku]

The problem with that is that it deletes all of the restore points at once (if I understand it right). It'd be nice to be able to phase it out so that I don't run out of disk space. The higher-ups want 90 days of backups (~20TB), so there probably isn't enough space to store both. I can make it work, but it'd be much better to delete some of them at a time

[Gostev]

If phasing out is required, then you can be removing the restore points manually (starting from oldest backups) by deleting the files from disk. Just don't forget to clean up the configuration when you are done (same right-click menu, but use the Remove from Backups) option instead. And don't try to restore from points which are already removed from disk

[seiniku]

That should do the job. Thanks for the help!