changing backup settings to allow new hard drives

I researched the settings of SSR 2013 on that job some more. The backup job is using "Start a new recovery point set (base): The first time the backup is run in a new week".

Can you re-create the job?

I will see if I can. Thanks.

Edit: wrong reply.

Have you re-created the job yet?

I did recreate the job. First, let me tell you what I ended up trying.

I was still not able to get the SSR 2013 to recognize the new hard drives with the existing backup settings. I ended up changing the backup destination from the USB hard drives to the network share of the hard drives. (Ex: backup destination was now \\servername\driveletter . I was then able to intermix different types of hard drives in the backup destination. I put in the admin username and password for that network admin share to the hard drive. It ran successfully like this for several nights.

However, I encountered an error one morning. The following messages from the SSR log explain it:

7/16/2015 21:00:22 PM High Priority Info: Info 6C8F1F65: The drive-based backup job, Drive Backup of System Reserved (*:\), (C:\), driveD (D:\), driveE (E:\), has been started automatically. 0x00 (Symantec System Recovery)
7/16/2015 23:17:59 PM High Priority Error: Error EC8F17B7: Cannot create recovery points for job: Drive Backup of System Reserved (*:\), (C:\), driveD (D:\), driveE (E:\).
    Error ED800019: The recovery point file '\\servername\i$\SERVERNAME_D_Drive353.v2i' could not be opened.
        Error E7D1000E: Unable to open '//servername/i$/SERVERNAME_D_Drive353.v2i'. It does not exist. 0xED800019 (Symantec System Recovery)
 (UMI:V-281-3215-6071)

We are running SSR 2013 Small Business Server Edition, v 11.0.2.49853.

Based on the above error messages, I have NO idea why the backup failed. The backup job started at 9 PM, but then the job failed because it couldn't open the drive, it seems. The drive was still being sensed by Windows and SSR the next morning when I came in and checked (expecting my backup files to be present in the removable USB drive...surprise!). No further error messages in the Event Viewer on the server were available for that time frame that referenced SSR 2013.

I ran several backup jobs on the nights after that with the identical settings. No errors.

After that, I did not trust the backup job to run correctly. I thought that perhaps the network drive sensing was flaky, and so I deleted the backup job. SSR hung when I tried to delete the job and I had to kill the service and start it again. Then I was able to delete the backup job and recreate it, using individual drives like in the original job.

Since then, jobs have run but the USB drives will not eject safely. It says that the drive is in use. I am troubleshooting this issue, and it appears as if the network share of the I drive is what is locking the drive. (This is because if I remove the network admin share for the USB drive (\\servername\i$) from the Share and Storage Managament console, the drive is able to be ejected. Also, I can't rename the aliases for the USB hard drives after I named them initially. Do you have an answer to either of these problems?

Once I have an answer about why the job failed when the job settings were set for network drive, I will mark this question as solved. However, we have switched over all of our hard drives to the new type, so we no longer have the need for mixed drives in the back up job. Thanks.

After I rebooted the server, something new came up.

I rebooted the server last night, then let the backup job run normally. It completed successfully, then the next morning I tried to eject the USB drive. It wouldn't let me, so I removed the I$ share for that drive (using the Share and Storage Management program). Then, after running Process Explorer, I saw that VProSvc.exe still had a handle open on the drive. I tried ejecting the USB drive, but it still told me it was busy. 

I tried stopping the Symantec System Recovery service, but it said the process was not accepting control messages at this time (paraphrased). I ended up killing the VProSvc and it then let me eject the USB drive.

I am wondering if SSR 2013 somehow hasn't fully let go of the drive letter/network share destination that I had previously told the backup job to save to, and that is causing the lock on the I: drive admin share. I am going to try manually assigning a different job letter to the hard drives so that they are all now the J: drive. I will see if I can unplug these drives successfully.

I was able to reproduce the problem: plug in usb hard drive, can't eject it. I changed the drive letter assignment for that drive from I: to J: using Disk Management and I was able to eject the drive without closing any handles. 

I was able to reproduce this solution, as well: every time I change the drive letter assignment for the usb drive from I: to J:, I can eject the drive.

I am going to run the backup tonight with the new drive letter assigned to the removable drive and will change the destination in SSR 2013 to point to that removable drive with the new letter. I will then see if it completes AND lets me eject the drive tomorrow morning. I will then verify that this fix is long-term over the next few days and does not stop working. 

So, to sum up:

1) The original backup job had been pointing to the I: drives for backups. I changed this to \\servername\i$ to try and allow us to use different USB drive types and it worked and the backups completed. However, the USB hard drive would not allow me to eject it (both types of drive, new and old).

2) I switched all our USB drives to the new type. I deleted the modified backup job and created a new backup job that matched the old settings (pointed to I: drive for saving). The backups would complete, but they would not eject safely.

3) I had to change the drive letter assignment for the USB hard drives from I: to J: in order to get the hard drives to eject safely. I changed the job settings to point to this new hard drive letter (J:). I am able to eject the hard drives now. I will confirm that the job completes successfully and check whether or not I can eject the drive safely afterwards.

Changing the letter assignment for the drives worked. My workaround is to manually assign J to each backup drive. 

When I plugged in the I: drive, I turned off the Symantec System Restore service and stopped the VProTray.exe process. I was still not able to eject the I: drive safely. I checked the handles and there had been three "System" processes with PID 4 that were open on the I: drive; after turning off SSR service and killing VProTray.exe, there were only two.

I had to stop sharing the I: drive admin share ($) in order to get the handles to close and the drive to eject.

After I changed the drive letter to J:, I was able to eject easily with no problems.

Symantec, can you recreate this problem?  Small Business Server 2011 (which is built on Server 2008 R2).

I have updated this ticket.