03-19-2012 10:30 AM
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?
Solved! Go to Solution.
03-22-2012 06:59 AM
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.
03-21-2012 09:58 AM
It's best to define the swapped USB devices as off-site copy targets. This should do the trick:, have a look here:
https://www-secure.symantec.com/connect/forums/ssr-2011-need-solution-backing-external-usb-drives
03-22-2012 06:59 AM
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.
03-23-2012 08:53 AM
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.
03-23-2012 09:06 AM
Markus: Thanks for your input. I appreciate the time you took to respond.
03-23-2012 11:03 AM
PorterJervis,
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.
Chris
03-25-2012 10:59 AM
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