none
Vista File Backup can not find drive after change of media (0x81000006)

    Question

  • We seem to have implemented a less common approach to using Vista backup resulting in a backup location not found error (error code 0x81000006). Can you please advise us on how to resolve this issue.

    Environment:

    Vista SP2 64-bit with a 1TB WDC MyBook connected to a firewire port as backup device. The Mybook is defined with the drive letter H:

    Backup Procedure:

    In the Task Scheduler we defined a single daily task that runs various cleanup and maintenance operations including a Complete PC Backup using wbadmin.exe and a Windows File Backup using the command %systemroot%\system32\rundll32.exe  /d sdengin2.dll,ExecuteScheduledBackup

    We use two identical MyBooks as backup devices with one connected to the Vista machine and the other MyBook stored off site. Once a week we swap the MyBooks. Both MyBooks have the drive letter H: when connected to the Vista machine.

    Problem:

    The complete PC backup task runs daily without a single error even after we swap the MyBooks but the File Backup gives the 0X81000006 Backup location not found error after swapping the MyBooks. We then have to manually reconfigure the File Backup using the GUI, manually run the File Backup and then turn off the schedule the GUI sets (as we use a custom task). After that File Backup runs without errors till the next swap. File Backup and Complete PC Backup both use H:\ as the backup device.

    Apparently Complete PC and File backup use a different parameter to identify the backup device. Can we set the parameter for the file backup device by other means than using the Backup Status and Configuration GUI?  I don’t mind if I have to modify the registry to this end and if this can be done I would like to know what the required parameter value is. Or can we configure the MyBooks such that File Backup doesn’t complain after swapping the devices (they already use the same device letter)? Would the problem be solved if I connected the drive to the PC using a eSata connector?

     

    Tuesday, September 22, 2009 7:40 AM

Answers

  • Hello Luke.

    I understand the scenario & expectation you have clearly.

    To answer your questions:

    >> How does file backup identify the backup disk?
    >> How can I change this identifier to the current value of the attached disk?


    The incremental file backup is tied to the combination of most recently taken backup and the backup target volume to which it was most recently configured to. It cannot be made to point to any other earlier backup version or a different volume/disk or any other backup target.

    We did not design the incremental backup feature keeping in mind the scenario you described. We always expect the backup target to be available. We will definitely keep this scenario in mind when designing the backup solution in future.

    >> Where have the storage folks stored the documentation for sdclt.exe and sdengin2.dll. How do I find out that the utility is named sdclt and that valid parameters are /kickoffnew or ExecuteScheduledBackup and what they do? When should I use /kickoffjob instead of /kickoffnew.

    The command line options for sdclt.exe/ExecuteScheduledBackup are not documented anywhere. The reason being: It was never meant to be used by customers. We are suggesting these options as workaround to certain issues that we could not fix in the product. If you have any specific issue/scenario that you cannot solve using the backup UI features, pl. let us know through this forum.

    We hear your concern of not having a command-line utility for backup. We will try to address this concern in future release.

    Thanks,
    Sriram [MSFT]
    Tuesday, September 29, 2009 12:25 PM
  • I did some tests and also found out that it is not only the volume but that the file backup utility also tests for the existence of the last backup set. I agree there is also logic to the approach and can live with that.

    If I understand the behavior correctly, the schedule the utility defines is always an incremental backup that is appended to the last full backup set (that may already have previous incremental backups). If I swap the drives or just delete the last backup set the scheduled (incremental backup) task fails even if it could revert to an older existing backup set. To create a consistent state for the backup utility I must make a new full backup. I would do that if I knew how to do it correctly.

    I also found out that
    sdclt.exe /KickoffNew runs a task scheduler job that creates new full backup and that
    sdclt.exe /KickoffJob runs a task scheduler job that creates an incremental backup
    Both /KickoffNew and /KickoffJob run the job immediately using the last known parameters (target volume and selected file types) but I can’t schedule them. That is inconvenient because I want to wrap my maintenance tasks in a single procedure of in sequence executed job steps that stops a service as the first job step and restarts the same service as the last job step. The service is a legacy database application with exclusive file locks that interfere with most maintenance tasks.

    Fortunately I saw that sdclt.exe /KickoffJob has the
    %systemroot%\system32\rundll32.exe  /d sdengin2.dll,ExecuteScheduledBackup
    command line equivalent that I now use in a flawed workaround to the problem. I moved the incremental backup job step to the bottom of my list of job steps (just before I restart the legacy service). I noticed that if the file backup fails (e.g. after a drive swap) I get an event log entry with event id 4104 that I use to as a task scheduler trigger that after a short time delay launches the full backup job sdclt.exe /KickoffNew that I also wrapped in a stop/restart service. The time delay is chosen as to allow the running job to complete before the full backup commences; they should not run in parallel.

    This workaround isn’t robust and won’t win any beauty contests but we should survive till the enhancements you mentioned are available in a future release. My users now only need to remember to swap the off-site drive with the on-site drive (and take it off-site). They don’t need to manually check the backup status and  initiate a full backup during office hours (bringing the system to a near standstill).

    My work around seems such a farfetched solution to straightforward problem of unattended backups. Anyway the new Backup technology is superior to NTBackup, it isn’t flawed but definitely misses features before it is a full-fledged replacement.

    I will remove the question mark on this thread

     

    • Marked as answer by Luke S Tuesday, October 06, 2009 3:29 PM
    Tuesday, October 06, 2009 3:25 PM

All replies

  • I have the same problem. My server has aa H: drive used just for Image & File Backup backups. The drive is copied to a "Hot Swap" drive for off site storage, but when it gets too full it is just cleared.
    Hope you get an answer.
    Wednesday, September 23, 2009 3:14 AM
  • (reference  Vista 0x81000006 sdclt.ext /KICKOFFNEW )

    (Continued) And when the H: drive gets cleared (everything deleted), the client PC File Backups will not work until you do a "full" File Backup at the client PC. It would be nice to know how to tell the client PCs that they need to do a 'full' backup on the next scheduled backup.


    --Update--

    sdclt.exe /kickoffnew

    - - -  ! ! ! !   U P D A T E    -   D O   N O T   D O   T H I S :      

    Bad:  May be a solution, worked on cmd line, have not tried the following yet:
    Bad:
    Bad: I am going to make a script, in which I will first check for the existance
    Bad:  of an appropriate file created in a previous backup, and if
    Bad: not there, will run sdclt.exe /kickoffnew, wait for the sdclt.exe task that
    Bad:  it kicks off to complete, then wait a few seconds more.
    Bad:
    Bad: I am going to put this script as the first Action
    Bad: in the "AutomaticBackup" task scheduler task.
    Bad: The next Action in that task will backup again, doesn't bother me...
    ------------------------------------------------------------------------------------

    ! ! !   W H Y   ?   ! ! !
      Seems the SDCLT /kickoffnew sets up backup then initiates task scheduler task "AutomaticBackup"
           which creates a recusive loop if you put SDCLT /Kickoffnew as another Action in AutomaticBackup. 

     A L S O ,  if "AutomaticBackup" is Disabled and you run SDCLT /kickoffnew, it still runs "AutomaticBackup"
    and when you look at it in Task Scheduler it says "Running". 

    Curreently using this .BAT  run in task scheduler an hour before the "AutomaticBackup" of the PC is run. 
         (My PCs have their backups stagered so they do not all run at the same time.)

    If exist \\Server1\PcBackup\FileBackup\%COMPUTERNAME%\Backup*.* Goto :EOF
    C:\Windows\System32\sdclt.exe /KICKOFFNEW

    Of course, you have to touch it up and make sure it works for you,
    and it will not work for Luke because Backup files exist on the drive he
    is rotating in. However,  he might want to save off the backup folder
    "Modified" date, for example,  at the end of his procedure, and
     then check for a change the next time the procedure is run.

     - - - N O T E   T O    L U K E - - -
    Starting a new Backup Set with sdclt /kickoffnew, should not delete anything
    as far as I know. You should see a new folder starting with "Backup Set" and a date,
    but I can't say if you will still get the error. Be sure to look at above stuff...

    Hope this helps.
    Just reading Lukes post triggered some thought that solved my problem !
    Althought I also plan to get a second offsite drive so that all my
    offsite eggs are not in one basket.
    Thanks Luke 
    • Proposed as answer by RWNG Wednesday, September 23, 2009 9:57 PM
    • Edited by RWNG Friday, September 25, 2009 12:49 AM
    Wednesday, September 23, 2009 8:36 PM
  • Hello.

    The file backup solution expects the same drive where previous backup was taken to be present. Wwapping the backup target causes the incremental chain to be broken and inturn causes this failure. Taking a full backup to the swapped target would help get past this issue. Glad that you were able to figure out this workaround yourselves!

    We have addressed this concern in Window7 by automatically taking a full backup if the previous backup does not exist on the backup target. However for Vista, the only way to workaround this issue is by running a full backup manually (either by going through the backup configuration wizard UI or running sdclt.exe /kickoffnew).

    Thanks,
    Sriram [MSFT]
    Thursday, September 24, 2009 5:49 AM
  • Thanks RWNG for the research efforts.

    That file backup expects the same drive as the previous run was obvious because that is the essence my question: how to work around this behavior?

    Seems RWNG and I have a different backup procedure. I have two backup disks and they don’t get cleared, I still have lots of free space. If we swap the disks weekly I have one disk with backups of the even numbered weeks and one with backups with the odd numbered weeks. Examining the two backup disks with Windows Explorer there is no way of distinguishing them from each other, having exactly the same structure.

    Swapping disks should not be any different than having the disk permanently attached, making daily file backups seven days in a row, then just not making any file backups for the next seven days, and then again making daily backups for the next seven days.

    Swapping the disks does not break any incremental chains as far as I can see because the chain info is on the disk (the catalog + backup sets using dates in the name). Both disks have been ‘initialized’ with a full backup and contain a number of incremental backups. After a disk swap I expect the (incremental) backup to ‘continue where it left off the last time on the current disk’ by comparing the catalog and backup file sets on the backup disk with the files on the computer and copy any differences into a new incremental backup set.

    I have no desire to reinitialize the backup (sdlclt /kickoffnew), as long as I have space left on my backup disk I want to keep the ‘previous versions”. And please don't implement the procedure to automatically overwrite my stuff in Win7 with a full new backup and deleting my prevous versions.

    So my questions still stand:

    How does file backup identify the backup disk?
    How can I change this identifier to the current value of the attached disk?

    BTW: The error message 0x81000006 states the location is invalid, it doesn't complain about invalidated chains

    A new question: where have the storage folks stored the documentation for sdclt.exe and sdengin2.dll. How do I find out that the utility is named sdclt and that valid parameters are /kickoffnew or ExecuteScheduledBackup and what they do? When should I use /kickoffjob instead of /kickoffnew.

    Thursday, September 24, 2009 9:33 AM
  • I updated my previous post because of a "bad idea".

    And thanks Sriram for the note about Window7. 
    Friday, September 25, 2009 1:05 AM
  • Hello Luke.

    I understand the scenario & expectation you have clearly.

    To answer your questions:

    >> How does file backup identify the backup disk?
    >> How can I change this identifier to the current value of the attached disk?


    The incremental file backup is tied to the combination of most recently taken backup and the backup target volume to which it was most recently configured to. It cannot be made to point to any other earlier backup version or a different volume/disk or any other backup target.

    We did not design the incremental backup feature keeping in mind the scenario you described. We always expect the backup target to be available. We will definitely keep this scenario in mind when designing the backup solution in future.

    >> Where have the storage folks stored the documentation for sdclt.exe and sdengin2.dll. How do I find out that the utility is named sdclt and that valid parameters are /kickoffnew or ExecuteScheduledBackup and what they do? When should I use /kickoffjob instead of /kickoffnew.

    The command line options for sdclt.exe/ExecuteScheduledBackup are not documented anywhere. The reason being: It was never meant to be used by customers. We are suggesting these options as workaround to certain issues that we could not fix in the product. If you have any specific issue/scenario that you cannot solve using the backup UI features, pl. let us know through this forum.

    We hear your concern of not having a command-line utility for backup. We will try to address this concern in future release.

    Thanks,
    Sriram [MSFT]
    Tuesday, September 29, 2009 12:25 PM
  • I did some tests and also found out that it is not only the volume but that the file backup utility also tests for the existence of the last backup set. I agree there is also logic to the approach and can live with that.

    If I understand the behavior correctly, the schedule the utility defines is always an incremental backup that is appended to the last full backup set (that may already have previous incremental backups). If I swap the drives or just delete the last backup set the scheduled (incremental backup) task fails even if it could revert to an older existing backup set. To create a consistent state for the backup utility I must make a new full backup. I would do that if I knew how to do it correctly.

    I also found out that
    sdclt.exe /KickoffNew runs a task scheduler job that creates new full backup and that
    sdclt.exe /KickoffJob runs a task scheduler job that creates an incremental backup
    Both /KickoffNew and /KickoffJob run the job immediately using the last known parameters (target volume and selected file types) but I can’t schedule them. That is inconvenient because I want to wrap my maintenance tasks in a single procedure of in sequence executed job steps that stops a service as the first job step and restarts the same service as the last job step. The service is a legacy database application with exclusive file locks that interfere with most maintenance tasks.

    Fortunately I saw that sdclt.exe /KickoffJob has the
    %systemroot%\system32\rundll32.exe  /d sdengin2.dll,ExecuteScheduledBackup
    command line equivalent that I now use in a flawed workaround to the problem. I moved the incremental backup job step to the bottom of my list of job steps (just before I restart the legacy service). I noticed that if the file backup fails (e.g. after a drive swap) I get an event log entry with event id 4104 that I use to as a task scheduler trigger that after a short time delay launches the full backup job sdclt.exe /KickoffNew that I also wrapped in a stop/restart service. The time delay is chosen as to allow the running job to complete before the full backup commences; they should not run in parallel.

    This workaround isn’t robust and won’t win any beauty contests but we should survive till the enhancements you mentioned are available in a future release. My users now only need to remember to swap the off-site drive with the on-site drive (and take it off-site). They don’t need to manually check the backup status and  initiate a full backup during office hours (bringing the system to a near standstill).

    My work around seems such a farfetched solution to straightforward problem of unattended backups. Anyway the new Backup technology is superior to NTBackup, it isn’t flawed but definitely misses features before it is a full-fledged replacement.

    I will remove the question mark on this thread

     

    • Marked as answer by Luke S Tuesday, October 06, 2009 3:29 PM
    Tuesday, October 06, 2009 3:25 PM
  • I have the same problem with w7, i did upgrade from vista 64bit, and i didn't have this issue. I find any solution let me know.
    In Even viewer:
    K:\
    The backup location cannot be found or is not valid. Review your backup settings and check the backup location. (0x81000006)
    , and i received the error code 0x80070002 with the backup failed message.
    • Proposed as answer by Davvid Wednesday, January 27, 2010 2:16 AM
    Saturday, January 09, 2010 2:10 AM
  • The last upgrade i receive from Windows Update resolved this problem to me. Here is the link:

    http://support.microsoft.com/default.aspx/kb/976972
    • Proposed as answer by Davvid Wednesday, January 27, 2010 2:19 AM
    Wednesday, January 27, 2010 2:19 AM