Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

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.

ssi_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.

ssi_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