Video Screencast Help

Swapping USB drives with Symantec System Recovery 2011

Created: 19 Mar 2012 • Updated: 23 Mar 2012 | 6 comments
This issue has been solved. See solution.

I have a backup routine where we swap USB disks out weekly.

I have run into an issue where the backup jobs do not find the new drives after the old ones are removed. 

If I edit the job and specifiy the drive letter, in this case F:, it can find them for that weeek, but after we change the drives again the next week, we go through this dance again.

I adjusted the settings in Tasks/Options, under General and set the destination to F, but after I save, it changes it to the drive volume name.

How can I make it use the drive letter, or do I have to just give all my volumes the same name?

Comments 6 CommentsJump to latest comment

Markus Koestler's picture

It's best to define the swapped USB devices as off-site copy targets. This should do the trick:, have a look here:

*** Please mark thread as solved if you consider this to have answered your question(s) ***

PorterJervis's picture

Markus:  Thanks for your input.  I appreciate the time you took to respond.

kqf_chris's picture

I backup directly to external USB drives and rotate weekly. Here is what I did:

1. Setup a weekly task on the server to run 5 minutes before the first new backup that wipes the plugged in USB drive (E: in my case). This is because SSR will no longer clean up the old backups when you directly rotate disks.

2. On the SSR side I set the backup job destination to \\localhost\e$\. Every time I plug in the USB drive it gets the E: drive letter. Since SSR allows backing up to a network share this makes it appear that the target never changes.

Let me know if this helps. It's the best solution I've found to a problem Symantec refuses to address.

PorterJervis's picture

CPontus:  Thanks for the feedback.  Looks like it wll work.  Too bad the backup time jumps 100x as it is going over the LAN now.  Funny how a good product has such a major flaw. 

Thanks again for your comments.

kqf_chris's picture


Glad I could help. I haven't seen any difference in backup time going direct to the disk or through localhost. The traffic never leaves your machine. I could be wrong but I think the limiting factor would be your CPU handling the TCPIP traffic locally.


PorterJervis's picture

Chris, My fault.  I was looking at the log incorrectly.  When I restarted the backup it had some catching up to do, which took it so long.  It's performing properly.  Thanks again