Weekly drive rotation: Does not recognise new Drive
Hi all,
BESR ver 8.5
My problem is simillar to the ones in other posts except for:
My client has 2 usb drives, I have setup 1 Backup job to run Tuesday - Saturday ( incremental) and the Base runs on the monday.
now the problem is when we change the HDD`s on a monday morning it does not allocate the job to the new drive
I have to manually edit the backup job every monday to point to the new HDD.
BESR did name the drives with HDD(1) and HDD(2) but still will not work.
The idea we have, is to have one drive off-site for the week, incase of theft / fire / waterdamage.
Any input would be greatly appreciated.
Kindest regards
The Scarlet IT Team
Removing Drives AND Targets
Good luck with that. I found out early on that BESR does not play nicely with removable media. I wanted to do the same thing with a Dell PowerVault RD1000 (rotate two cartridges on a weekly basis) but if you remove either the "destination" or the target machine you are backing up, from the network, it throws the job into a state of disarray. Keep in mind that this is in a configuration that uses the BESR Manager, I'm not sure if these same issues occur with a standalone installation, local to the target. I'm now finding that if I remove my laptop from the network after creating a base (full backup), BESR sees that as a new target and will run a full backup on the next run instead of an incremental. Symantec support advises that they have no intention of doing anything to change this type of behavior and now I'm wondering if a simple reboot of a target will cause the same types of issues. For whatever reason, BESR relies way too heavily on a heartbeat between the application, the destination, and the target.
Drive rotation
Scarlett IT,
You are correct - you cannot use 2 different destination drives for the same job. If you are going to backup to 2 separate drives, create 2 separate jobs. Or utilize the offsite feature. Either way, if you happen to miss one of the backups or offsite copy, they should resume when the drives are reconnected.
When I say offsite, it should be noted that offsite is used loosely to define a location separate from the backup job destination drive. Offsite could be a network location, another drive or a remote FTP site.
Andreas Horlacher
Symantec Enterprise Support Svs
More Feedback?
Andreas,
I see you posting in here quite a bit. What is your take on the target being removed from the network? One of your techs believes it is expected behavior that the backup job will start over and run a full base rather than an incremental, much the same as if you remove the backup destination from the network (removeable media).
I find this a hard pill to swallow because you have to reboot systems at some point or another, and I assume that maintenance is going to cause the same problem. Not to mention that laptops are meant to be mobile so it's highly likely that most companies will never be able to run backup sets (with incrementals) against laptops/notebooks, with this software.
NTFS Junction points can get
NTFS Junction points can get around the USB drive identification feature at the minor expense of needing your backup drives to have a consistent drive letter. See http://www.symantec.com/connect/forums/howto-usb-drive-rotation-besr-70-85
Jkornheiser, the only requirement for BESR to make an incremental is that must be able to see all parts of the current incremental chain when the backup starts. If a job is triggered when the laptop is away from the network and the destination is entirely unavailable for writing and the chain still breaks, then that would be an unfortunate bug (why break the chain when the backup can't run?). If the base really was relocated while the network share maintains availability, then running a new base that would be the expected behaviour.
It is possible that the manager is causing issues as well. I'd used it in version 8.0, but found it to be somewhat troublesome, and we don't change the backup configuration often enough to make it worthwhile. Email reporting gets the job done, and one unmanaged BESR installation can manage others easily enough (not to mention the usual RDP administration, etc).
Not True According to Support and Testing
"the only requirement for BESR to make an incremental is that must be able to see all parts of the current incremental chain when the backup starts."
That's what I thought Andrew, but that's not what I'm being advised by Support (Symantec Case 281-749-345) and that's not what I'm seeing with testing.
I setup a job to backup my laptop on a weekly basis and on the first run, it created a base, then an incremental the second week, then a full base again on the third week. I contacted Support and they asked me to delete the backup job, all of the PQH files, recreate the job, and try again. This time it created a full base on the first run, then in week 2 tried to create a full base again. Support then suggested that I try a daily backup job since my laptop typically stays on the network through the week, and goes home with me on the weekend.........so I followed their advice, it ran a full base on Monday, and an incremental on Tuesday, Wednesday, Thursday, and Friday. No problem with it trying to run a full base out of nowhere.
The destination and the backups themselves are not moving. They are dumped to a fixed disk that is always there. I agree that it should only check the target, destination, and previous backups when the job is kicked off, but that's not what I'm seeing occur. It is apparent that removing the laptop from the network (but making sure it is there when the job is scheduled to run), is not preventing a full base from being run randomly when it is expected to run an incremental.
Source Request
Andrew,
What is your source for the statement I quoted you on? Is it documented somewhere?
I'm not sure if it's
I'm not sure if it's documented anywhere; I'm speaking from my observed behaviour of the product.
One cause I may suspect is the amount of time you're allowing to elapse between backups (if I'm understanding your schedule correctly). I've never set a job to run more infrequently than once every couple of days. I do believe that BESR depends upon the NTFS USN journal for keeping track of incrementals - if the journal wraps before another incremental is run, then a base has to be created, since BESR can't tell what has changed since the last backup. If memory serves, I read about the USN dependency in a KB article about BESR and BEWS's interaction with SQL backups.
It may be possible to grow the journal with an existing volume - I know it can't be reduced without formatting - but I would be wary of doing that. I once inherited a Windows 2000 server that had an abnormally large USN journal and it took ages to boot, despite having 15K RPM SAS drives. Clearing the journal from the BESR SRD (a feature of NT6's chkdsk) would allow it to start up nice and quickly until the journal filled up again. It may have been related to the server being an Active Directory domain controller (which also depends upon USN), but I'd avoid growing the journal nontheless.
Rotating Drives
Scarlet IT -- Are you still manually editing the job or have you tried Andrew's Junction Point method? I'm working on a similar scenario to yours but with ESATA drives instead of USB drives. I have some VBS code that can update the destination drive , but it doesn't fully overcome this products limitations when doing "base and incrementals" backups to rotating media.
Am I correct in assuming that the destination drives have different drive letters?
I have not tested Andrew's
I have not tested Andrew's configruation with the Junction Point method. Regardless, BESR identifies drives in several ways. If the destination changes, even if the drive letter stays the same, BESR will detect that. The incremental chain will be broken and a new base image will be created, from which to build the incrementals. Offsite works a little different than this and you can rotate the drives.
Andreas Horlacher
Symantec Enterprise Support Svs
Breaking the chain
Andreas -- Could you please verify Andrew's comments above about BESR's use of the USN journal?
I think your info on breaking the incremental chain is actually pointing toward a solution for Scarlet IT's issue. Since Scarlet IT is the original poster, I would like to get the posted issue solved first before delving into other aspects of the BESR incremental chain. If I understand Scarlet IT correctly, the desired behavior is to break the incremental chain every Monday and begin anew -- just with different drives as a destination. Defining two different backups to different destinations is possible, but one of the backups would have to be an independent recovery point. If I understand correctly, Independent recovery points are always full backups, so that would not meet Scarlet IT;s criteria.
I was under the false impression that it was not possible to update the parameters of a defined recovery point set job via script, but working on the solution to the following post opened my eyes:
https://www-secure.symantec.com/connect/forums/two...
I've done some further testing and found that it is quite possible to isolate the correct job ID if you have multiple jobs and they have unique display names. I've yet to assemble all the code together, but here is my proposed path toward the solution:
I have most of the code written for these steps already, just in different scripts. The fun part will be assembling all the snippets together and testing them to see if the desired final result is achieved. If it works, it will be another example of how the capabilities of BESR can be extended with VBScript.
I've also done some further testing with Andrew's method, and it seems to work well. However, I like to isolate my images to folders named for the week ending date. The code I'm planning to generate could easily be combined with Andrew's junction point method to achieve the same result. My USB drive seem to retain a drive letter well, but my ESATA are not faring as well. I have to change their drive letters every time, but luckily this can be done with VBScript too.
Progress and some success
Well, it was more work than I anticipated, but I proved it was possible to have BESR image job destination settings updated via script. I was able to get this to work with both junction points and standalone external drives. However, I'll only be posting the standalone drive code today. The junction point version of the script only works with Vista and Server 2008, so I'm holding off until I can get it to work with XP and Server 2003 reliably. One of the routines in the JP version actually checks to see if the external drive associated with the junction point is attached. The routine relies on the output of the dir /aL command. The XP and Server 2003 versions of the dir /aL command will reveal the junction points, but not their destinations. I'm searching for some other method of doing this without installing some other program.
The code is heavily commented, so I'm not going to document too much here. One thing I can add is to make sure the external drives are swapped out before invoking the script either manually or via Windows Task Scheduler. Otherwise, the same attached drive will be used again, but with a different destination folder. Desirable if there is enough space and the swap out day is a holiday. Also, there is an expriration date setting made for the base and incremental tasks. Some users may want to comment the .EndDateLocal seting in oTask and oIncTask in order to disable it. When the expiration date is reached, the imaging job will seem to disappear from the Run or Mangage Jobs GUI. The job has not disappeared, it is just hidden from view. It will appear again when the script updates the new schedule. If this functionality bothers you, then by all means comment the above referenced settings to keep the job visible regardless of schedule.
The schedule is based on Scarlet IT's desired schedule, but the code is easily modified for those with a different desired weekly schedule. I am working on adapting the code foe a monthly schedule. By extending BESR's capabilities with this code, I think it shows that Rotating External Drives functionality could be built into future versions of BESR. There is an obvious demand for it if the posts in this forum are any indication.
Batch file to invoke the script:
The script:
' BESRRotateDrives.vbs ' ' Edited and adapted by marcogsp ' ' Purpose: ' ' Script to update an existing BESR imaging job's settings when rotating external drives for storing images. ' When rotating external drives a new base-incremental recovery point set is created. The incremental images are not ' spanned across different drives. This script does not create a new imaging job. It iterates through the list of ' existing imaging jobs, determines which drives are being imaged, and updates the imaging schedule and images location. ' ' It is assumed that the setting for prepending the computer name to the image is being used. Coupled with the file spec ' used in the script, the resultant image name might look something like this(C:\ drive as sample): ' ' ComputerName_C_001.v2i ' ' There are two marked sections in this script that the user needs to edit to suit their own environment. ' The first marked section is near line 142. The user must define an array of drive letters matching the drive letters ' of the rotated external drives. A minimum of one drive must exist in the array. ' Please refer to the first marked section for further documentation on this process. Also in the first marked section, ' the user must supply the display name of the job to be updated, and the day of the week you wish to be the start day. ' The start day is the base for all the date calculations in this script. ' ' The second marked section of the script (Near line 329) contains settings for the base and incremental tasks schedules. ' Edit this section to change the start time and scheduled days ' ' ' The script creates a folder for storing images based on the the week ending date, i.e. Saturday's date ' A sample folder name would be in this format: WE-09-29-09 ' Reflected date is in MM-DD-YY format. ' ' This script is invoked from a simple batch file. The batch file command would be: ' cscript.exe BESRRotateDrives.vbs ' ' The batch file is then scheduled to run as a once weekly task job in the Windows task scheduler. ' The scheduled day should be the day you swap out external drives for best results in capturing ' the most images. ' ' If an external drive fails and is replaced, either run the Windows task scheduler job manually. ' or the batch file it invokes. As long as the replaced drive has a drive letter specified in this script's array ' of available drives, the target folder will be recreated and a new base-incremental ' recovery point set is started ' ' Both the batch file and this script should be placed in the same folder. Option Explicit Dim sDate Dim sShortMonth, sShortDay, sWEfolder Dim iDaysTillSaturday, sSatDate Dim aExtDrives, sDriveLetter, sDestDrive Dim sImagesFolder Dim iDayInterval, sStartDate, sEndDate, sStartTime Dim iStartDay Dim sServerName Dim sJobID, sJobDisplayName, sExpectedDisplayName Dim aVols() Dim iSize, sVolumesArray Dim sArrayMember Dim oFSO, oDriveLetter Dim oWshShell Dim oV2iAuto, oImageJob, oCurrentJob Dim oTempVolume, oVol Dim oTask, oIncTask ' Drive Letter Volume Objects Dim oVolume_C Dim oVolume_D Dim oVolume_E Dim oVolume_F Dim oVolume_G Dim oVolume_H Dim oVolume_I Dim oVolume_J Dim oVolume_K Dim oVolume_L Dim oVolume_M Dim oVolume_N Dim oVolume_O Dim oVolume_P Dim oVolume_Q Dim oVolume_R Dim oVolume_S Dim oVolume_T Dim oVolume_U Dim oVolume_V Dim oVolume_W Dim oVolume_X Dim oVolume_Y Dim oVolume_Z ' Image storage location objects Dim oImageLocation_C Dim oImageLocation_D Dim oImageLocation_E Dim oImageLocation_F Dim oImageLocation_G Dim oImageLocation_H Dim oImageLocation_I Dim oImageLocation_J Dim oImageLocation_K Dim oImageLocation_L Dim oImageLocation_M Dim oImageLocation_N Dim oImageLocation_O Dim oImageLocation_P Dim oImageLocation_Q Dim oImageLocation_R Dim oImageLocation_S Dim oImageLocation_T Dim oImageLocation_U Dim oImageLocation_V Dim oImageLocation_W Dim oImageLocation_X Dim oImageLocation_Y Dim oImageLocation_Z 'Day of the week constants -- For use with the DateAdd Function Const Sunday = 1 Const Monday = 2 Const Tuesday = 3 Const Wednesday = 4 Const Thursday = 5 Const Friday = 6 Const Saturday = 7 'Begin Section - Edit this section to suit your environment. ' '************************************************************************************ ' ' Variables user must set manually to reflect their environment iStartDay = Monday 'Set the start day from list of constants above - no abbreviations ' Set variable for imaging job's display name that you want the script ' to find. sExpectedDisplayName = "Non-Scheduled Image Job for C:\ and D:\" ' Construct an array of external drives used to store BESR images ' Edit to reflect drive letters used in your environment ' Note: No colons or backslashes used in Array ' Be sure to enclose drive letters in quotes as shown ' and separated by commas ' ' ' Sample for array of five drives ' aExtDrives = Array("V","W","X","Y","Z") ' ' Array can and may contain just one member ' ' Sample: aExtDrives = Array("X") ' Define array of external drives below ' aExtDrives = Array("Z","X") ' ' '************************************************************************************ ' 'End Section sDate = Date WScript.Echo "The date is: " & sDate & VbCrLf ' How many days until Saturday and what is Saturday's Date iDaysTillSaturday = (7 - (DatePart("w", sDate))) sSatDate = DateAdd("d", iDaysTillSaturday, sDate) WScript.Echo "Saturday's date is: " & sSatDate & VbCrLf ' Iterate through the array and determine which external drive ' if any, is attached to the computer. The first attached drive found ' will be the destination drive for the images Set oFSO = WScript.CreateObject("Scripting.FileSystemObject") For Each oDriveLetter In aExtDrives sDriveLetter = oDriveLetter Select Case oFSO.DriveExists(sDriveLetter) Case True sDestDrive = sDriveLetter & ":" Exit For Case False ' sDestDrive is a null value WScript.Sleep 0 Case Else WScript.Echo "Drive status cannot be determined." WScript.Echo "Ending script execution." & VbCrLf Call subCleanup End Select Next ' Fail this script if sDestDrive is set to a null value If sDestDrive = "" Then WScript.Echo "None of the designated external drives were attached to the server." & VbCrLf WScript.Echo "Ending script execution." & VbCrLf Call subCleanup Else WScript.Echo sDestDrive & " is available." & VbCrLf WScript.Echo "Proceeding............." & VbCrLf End If Call subGenWEdate 'Create string representing destination folder's name sImagesFolder = sDestDrive & "\" & sWEfolder ' Determine if image destination folder exists, otherwise create it Select Case oFSO.FolderExists(sImagesFolder) Case True WScript.Echo "Folder " & sImagesFolder & " exists." & VbCrLf Case False WScript.Echo sImagesFolder & " does not exist." & VbCrLf oFSO.CreateFolder(sImagesFolder) WScript.Echo "Folder has been created." & VbCrLf Case Else WScript.Echo "Destination folder status cannot be determined." & VbCrLf WScript.Echo "Folder was not created -- Ending script execution." & VbCrLf Call subCleanup End Select ' Need to do some more date arithmetic before updating the image job. ' In this Script, a base image will be made on Mondays, and incremental ' images made on Tuesday through Saturday. If this script is run on a Sunday, ' the following Monday will be determined and set as the start date for the job. ' If this script is run on Monday through Saturday, the Monday of the current week will ' be the start date of the job. ' An end date for the job (7 days from Monday) will also be calculated and set. ' Since this script is designed to be once weekly, setting an end date for the job ' assures that next weeks images will start a fresh base and be stored in a separate ' date generated folder. ' If the Monday job is missed, the chain is broken and ' a new base is created regardless of incremental schedule. ' If you wish to change the start day to something other than Monday ' just edit the iStartDay variable at the beginning of the script. ' The same forward and backward date calculations will still apply, ' only based on the day you choose. ' Set the start and end date variables iDayInterval = iStartDay - Weekday(sDate) sStartDate = DateAdd("d",iDayInterval,sDate) 'Start on Monday's Date WScript.Echo "Start Date: " & sStartDate sEndDate = DateAdd("d",7,sStartDate) 'End 7 days from now WScript.Echo "End Date: " & sEndDate &VbCrLf 'set variable for server name Set oWshShell = WScript.CreateObject( "WScript.Shell" ) sServerName = oWshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" ) WScript.Echo "The server name is: " & sServerName ' Create BESR automation object and connect to local BESR agent Set oV2iAuto = CreateObject("Symantec.ProtectorAuto") Call oV2iAuto.Connect(sServerName) 'Begin Section - Edit this section to suit your environment. ' '************************************************************************************ ' ' ''Set the Base and Incremental Task Settings sStartTime = "21:00" 'Set start time for job in 24 hour format Set oTask = CreateObject("Symantec.Scheduler.Task") With oTask .Description = "Weekly full backup task" .RepeatInterval = oTask.Constants.IntervalWeekly '.AddRepeatDay(0) ' Sunday .AddRepeatDay(1) ' Monday '.AddRepeatDay(2) ' Tuesday '.AddRepeatDay(3) ' Wednesday '.AddRepeatDay(4) ' Thursday '.AddRepeatDay(5) 'Friday '.AddRepeatDay(6) ' Saturday .StartDateTimeLocal = sStartDate & " " & sStartTime .EndDateLocal = sEndDate Call .Validate() ' Make sure we built the task correctly End With ''Create a task to schedule the incremental backups Set oIncTask = CreateObject("Symantec.Scheduler.Task") With oIncTask .Description = "Daily Incremental Backups" .RepeatInterval = oIncTask.Constants.IntervalWeekly '.AddRepeatDay(0) ' Sunday '.AddRepeatDay(1) ' Monday .AddRepeatDay(2) ' Tuesday .AddRepeatDay(3) ' Wednesday .AddRepeatDay(4) ' Thursday .AddRepeatDay(5) ' Friday .AddRepeatDay(6) ' Saturday .StartDateTimeLocal = sStartDate & " " & sStartTime .EndDateLocal = sEndDate Call .Validate() End With ' ' '************************************************************************************ ' 'End Section ' Iterate through the images jobs and find the one with the desired display name For Each oCurrentJob In oV2iAuto.ImageJobs Select Case oCurrentJob.DisplayName Case sExpectedDisplayName sJobID = oCurrentJob.ID sJobDisplayName = oCurrentJob.DisplayName WScript.Echo "The current job ID is: " & sJobID & VbCrLf WScript.Echo "Job Display Name: - " & sJobDisplayName _ & " - matches the expected display name."_ & VbCrLf Exit For Case Else WScript.Echo "Job with description - " & sExpectedDisplayName & " - cannot be found -- Exiting Script" Call subCleanup End Select Next Set oImageJob = oV2iAuto.ImageJob(sJobID) ' Determine which volumes the imaging job is imaging iSize = 0 For Each oVol In oImageJob.Volumes ' Populate array with drives listed in imaging job ReDim Preserve aVols(iSize) aVols(iSize) = oVol iSize = iSize + 1 Next ' Iterate through the newly populated array and build sVolumesArray string ' sVolumesArray = "" For Each oVol In aVols If sVolumesArray = "" Then sVolumesArray = funcFindArrayMember(oVol) Else sVolumesArray = sVolumesArray & "," & funcFindArrayMember(oVol) End If Next WScript.Echo "sVolumesArray: " & sVolumesArray & VbCrLf 'Update the image job settings Set oImageJob = oV2iAuto.ImageJob(sJobID) With oImageJob .Type = oImageJob.Constants.ImageTypeBase .IncrementalSupport = True .Reason = oImageJob.Constants.ImageReasonAutomatic .RunOnce = False .Volumes = Array(sVolumesArray) .Task = oTask .IncrementalTask = oIncTask 'Uncomment the .Task and .IncrementalTask lines below 'if you wish to blank out the job schedule. Also comment 'the two similar lines above to avoid confusion. .Task = Nothing .IncrementalTask = Nothing On Error Resume Next ' Allows for skipping over undefined locations .Location(oVolume_C.ID) = oImageLocation_C .Location(oVolume_D.ID) = oImageLocation_D .Location(oVolume_E.ID) = oImageLocation_E .Location(oVolume_F.ID) = oImageLocation_F .Location(oVolume_G.ID) = oImageLocation_G .Location(oVolume_H.ID) = oImageLocation_H .Location(oVolume_I.ID) = oImageLocation_I .Location(oVolume_J.ID) = oImageLocation_J .Location(oVolume_K.ID) = oImageLocation_K .Location(oVolume_L.ID) = oImageLocation_L .Location(oVolume_M.ID) = oImageLocation_M .Location(oVolume_N.ID) = oImageLocation_N .Location(oVolume_O.ID) = oImageLocation_O .Location(oVolume_P.ID) = oImageLocation_P .Location(oVolume_Q.ID) = oImageLocation_Q .Location(oVolume_R.ID) = oImageLocation_R .Location(oVolume_S.ID) = oImageLocation_S .Location(oVolume_T.ID) = oImageLocation_T .Location(oVolume_U.ID) = oImageLocation_U .Location(oVolume_V.ID) = oImageLocation_V .Location(oVolume_W.ID) = oImageLocation_W .Location(oVolume_X.ID) = oImageLocation_X .Location(oVolume_Y.ID) = oImageLocation_Y .Location(oVolume_Z.ID) = oImageLocation_Z On Error GoTo 0 End With ' 'Note: AddImageJob method also updates job settings Call oV2iAuto.AddImageJob(oImageJob) WScript.Echo "Imaging Job settings have been updated" Call subCleanup ' subCleanup -- Subroutine to cleanup objects and quit script Sub subCleanup Set oFSO = Nothing Set oDriveLetter = Nothing Set oWshShell = Nothing Set oV2iAuto = Nothing Set oImageJob = Nothing Set oCurrentJob = Nothing Set oTempVolume = Nothing Set oVol = Nothing Set oTask = Nothing Set oIncTask = Nothing ' Drive Letter Volume Objects Set oVolume_C = Nothing Set oVolume_D = Nothing Set oVolume_E = Nothing Set oVolume_F = Nothing Set oVolume_G = Nothing Set oVolume_H = Nothing Set oVolume_I = Nothing Set oVolume_J = Nothing Set oVolume_K = Nothing Set oVolume_L = Nothing Set oVolume_M = Nothing Set oVolume_N = Nothing Set oVolume_O = Nothing Set oVolume_P = Nothing Set oVolume_Q = Nothing Set oVolume_R = Nothing Set oVolume_S = Nothing Set oVolume_T = Nothing Set oVolume_U = Nothing Set oVolume_V = Nothing Set oVolume_W = Nothing Set oVolume_X = Nothing Set oVolume_Y = Nothing Set oVolume_Z = Nothing ' Image storage location objects Set oImageLocation_C = Nothing Set oImageLocation_D = Nothing Set oImageLocation_E = Nothing Set oImageLocation_F = Nothing Set oImageLocation_G = Nothing Set oImageLocation_H = Nothing Set oImageLocation_I = Nothing Set oImageLocation_J = Nothing Set oImageLocation_K = Nothing Set oImageLocation_L = Nothing Set oImageLocation_M = Nothing Set oImageLocation_N = Nothing Set oImageLocation_O = Nothing Set oImageLocation_P = Nothing Set oImageLocation_Q = Nothing Set oImageLocation_R = Nothing Set oImageLocation_S = Nothing Set oImageLocation_T = Nothing Set oImageLocation_U = Nothing Set oImageLocation_V = Nothing Set oImageLocation_W = Nothing Set oImageLocation_X = Nothing Set oImageLocation_Y = Nothing Set oImageLocation_Z = Nothing WScript.Quit End Sub ' subGenWEdate --Subroutine to generate week ending date String Sub subGenWEdate If Month(DateValue(sSatDate)) < 10 Then sShortMonth = "0" & Month(sSatDate) Else sShortMonth = Month(sSatDate) End If If Day(sSatDate) < 10 Then sShortDay = "0" & Day(sSatDate) Else sShortDay = Day(sSatDate) End If 'Set the sWEfolder Variable sWEfolder = "WE-"_ & sShortMonth & "-" _ & sShortDay & "-" _ & Right(Year(DateValue(sSatDate)), 2) End Sub ' funcFindArrayMember(oVol_In) ' ' Function to return array member for building sVolumesArray string. ' Also sets associated volume and image location objects for volumes ' that are found Function funcFindArrayMember(oVol_In) On Error Resume Next For Each oTempVolume in oV2iAuto.Volumes(false) If oVol_In = oTempVolume.MountPoint Then Select Case oVol_In Case "C:\" Set oVolume_C = oTempVolume sArrayMember = "oVolume_C.ID" Set oImageLocation_C = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_C.Path = sImagesFolder oImageLocation_C.FileSpec = "C_" Case "D:\" Set oVolume_D = oTempVolume sArrayMember = "oVolume_D.ID" Set oImageLocation_D = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_D.Path = sImagesFolder oImageLocation_D.FileSpec = "D_" Case "E:\" Set oVolume_E = oTempVolume sArrayMember = "oVolume_E.ID" Set oImageLocation_E = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_E.Path = sImagesFolder oImageLocation_E.FileSpec = "E_" Case "F:\" Set oVolume_F = oTempVolume sArrayMember = "oVolume_F.ID" Set oImageLocation_F = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_F.Path = sImagesFolder oImageLocation_F.FileSpec = "F_" Case "G:\" Set oVolume_G = oTempVolume sArrayMember = "oVolume_G.ID" Set oImageLocation_G = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_G.Path = sImagesFolder oImageLocation_G.FileSpec = "G_" Case "H:\" Set oVolume_H = oTempVolume sArrayMember = "oVolume_H.ID" Set oImageLocation_H = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_H.Path = sImagesFolder oImageLocation_H.FileSpec = "H_" Case "I:\" Set oVolume_I = oTempVolume sArrayMember = "oVolume_I.ID" Set oImageLocation_I = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_I.Path = sImagesFolder oImageLocation_I.FileSpec = "I_" Case "J:\" Set oVolume_J = oTempVolume sArrayMember = "oVolume_J.ID" Set oImageLocation_J = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_J.Path = sImagesFolder oImageLocation_J.FileSpec = "J_" Case "K:\" Set oVolume_K = oTempVolume sArrayMember = "oVolume_K.ID" Set oImageLocation_K = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_K.Path = sImagesFolder oImageLocation_K.FileSpec = "K_" Case "L:\" Set oVolume_L = oTempVolume sArrayMember = "oVolume_L.ID" Set oImageLocation_L = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_L.Path = sImagesFolder oImageLocation_L.FileSpec = "L_" Case "M:\" Set oVolume_M = oTempVolume sArrayMember = "oVolume_M.ID" Set oImageLocation_M = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_M.Path = sImagesFolder oImageLocation_M.FileSpec = "M_" Case "N:\" Set oVolume_N = oTempVolume sArrayMember = "oVolume_N.ID" Set oImageLocation_N = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_N.Path = sImagesFolder oImageLocation_N.FileSpec = "N_" Case "O:\" Set oVolume_O = oTempVolume sArrayMember = "oVolume_O.ID" Set oImageLocation_O = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_O.Path = sImagesFolder oImageLocation_O.FileSpec = "O_" Case "P:\" Set oVolume_P = oTempVolume sArrayMember = "oVolume_P.ID" Set oImageLocation_P = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_P.Path = sImagesFolder oImageLocation_P.FileSpec = "P_" Case "Q:\" Set oVolume_Q = oTempVolume sArrayMember = "oVolume_Q.ID" Set oImageLocation_Q = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_Q.Path = sImagesFolder oImageLocation_Q.FileSpec = "Q_" Case "R:\" Set oVolume_R = oTempVolume sArrayMember = "oVolume_R.ID" Set oImageLocation_R = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_R.Path = sImagesFolder oImageLocation_R.FileSpec = "R_" Case "S:\" Set oVolume_S = oTempVolume sArrayMember = "oVolume_S.ID" Set oImageLocation_S = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_S.Path = sImagesFolder oImageLocation_S.FileSpec = "S_" Case "T:\" Set oVolume_T = oTempVolume sArrayMember = "oVolume_T.ID" Set oImageLocation_T = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_T.Path = sImagesFolder oImageLocation_T.FileSpec = "T_" Case "U:\" Set oVolume_U = oTempVolume sArrayMember = "oVolume_U.ID" Set oImageLocation_U = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_U.Path = sImagesFolder oImageLocation_U.FileSpec = "U_" Case "V:\" Set oVolume_V = oTempVolume sArrayMember = "oVolume_V.ID" Set oImageLocation_V = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_V.Path = sImagesFolder oImageLocation_V.FileSpec = "V_" Case "W:\" Set oVolume_W = oTempVolume sArrayMember = "oVolume_W.ID" Set oImageLocation_W = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_W.Path = sImagesFolder oImageLocation_W.FileSpec = "W_" Case "X:\" Set oVolume_X = oTempVolume sArrayMember = "oVolume_X.ID" Set oImageLocation_X = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_X.Path = sImagesFolder oImageLocation_X.FileSpec = "X_" Case "Y:\" Set oVolume_Y = oTempVolume sArrayMember = "oVolume_Y.ID" Set oImageLocation_Y = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_Y.Path = sImagesFolder oImageLocation_Y.FileSpec = "Y_" Case "Z:\" Set oVolume_Z = oTempVolume sArrayMember = "oVolume_Z.ID" Set oImageLocation_Z = CreateObject("Symantec.VProRecovery.FolderLocation") oImageLocation_Z.Path = sImagesFolder oImageLocation_Z.FileSpec = "Z_" Case Else WScript.Sleep 0 End Select Else WScript.Sleep 0 End If Next On Error GoTo 0 funcFindArrayMember = sArrayMember End FunctionSHARE USB DRIVE AND USE A MAPPED DRIVE LETTER
Hi All
I was experiencing the same issues with rotating USB hard drives and think I came across the solution when using a USB Quantum GoVault which comes up as a USB drive in Windows 2003 SBS but Symantec System Recovery could not access the drive letter directly and the application hung. I shared the Quantum F:\ giving everyone full permission. Then I mapped a drive to the share called S:\ SSR is now able to access the drive and make backups without any issues. I have set the backup job to to a full snapshot on Monday and incremental until Saturday. I then change the disk every Monday morning so I'm getting a full on Mondays and snapshot for the rest of the week.
When using a mapped drive letter the system works perfectly and does not complain when the disks are changed.
Hope this Helps
Nice Approach B_Abbey
Cool suggestion B_Abbey! Have you tried using the URL of the shared drive(s) instead of a mapped drive in your imaging job setup? For thise folks with way too many drive letters to manage, using the URL of the share might be a way to adapt your solution to their situation.
I actually do something similar to your solution in my production network. The main file and print server has a SCSI drive enclosure which has a shared folder for storing BESR images. The imaging jobs use the URL location of this folder as the base for their storage location. However I like to segregate the images by week ending date (and Server) and the the File System Object will not work with URLs to create folders. The scripts I use map a drive to the shared folder temporarily, create the desired folder, and then unmap the drive. The newly created folder can then be added to the URL path.
Anyway, thanks for your suggestion. I often get problem solving ideas from other peoples' perspectives, and your's has helped with another situation I'm working on.
Would you like to reply?
Login or Register to post your comment.