none
WindowsServer2008R2において、タスクスケジュールで登録したバッチが実行されるとシステムファイルが破損する。 RRS feed

  • 質問

  • いつも参考にさせて頂いております。

    タイトルに書いた内容についてご質問させて頂きたいと思います。

     

    現在、タスクスケジュールにバッチを登録し、DBバックアップ+ファイル処理を行おうと考えています。

    バッチファイルをキックし、きちんとDBバックアップ+ファイル処理がされていることを確認した上で、タスクスケジュールに登録を行いました。

    ところが、テストということで一度実行してみたところ、「フォルダが見つかりません」(だったかと記憶しています)のようなエラーメッセージが出ました。

    その後、タスクスケジュールを開いてみようとすると、タスクスケジュールのサービス自体がどうも落ちているようでした。

     

    その状態で一度再起動をかけてみたところ、起動途中でブルースクリーンが一瞬表示され、また最初から起動するという状態に。

    自動修復が選択できるようだったので、選択してみるのですが、「StartupRepairOffline」のイベントが修復出来ず、再起動→修復→修復出来ず→再起動のループ状態になってしまいました。

    イメージから復旧後、再度試してみたところ、やはりそのエラーで破損したようなので、タスクスケジュール、もしくはバッチに原因があるのだろうと思っています。

    これまでこうした状況は他の方であったのでしょうか。過去ログ等も少し見てみたのですが、探し出せていません。

    何か解決方法、回避方法等あれば何卒ご教授願います。

     

    なお、稚拙な内容で恥ずかしいのですが、バッチファイルの中身を以下に記載致します。

    バッチファイルからSQLファイルを呼び出すようになっています。

    --------------------------------------------------------------------------------------------------

    echo off
    rem ----------------------------------------------------
    rem ディレクトリ構成
    rem ---BACKUP(日々のバックアップ格納用)
    rem       |
    rem       ----各日付のディレクトリ
    rem                |
    rem                ------DBBACK(バックアップしたファイル)
    rem ---DBBackup.bat
    rem ---backup.sql
    rem -----------------------------------------------------

    rem バックアップ用SQLファイル
    set SQLFILE=D:\XXXX\BackUp\backup.sql
    rem バックアップ格納先
    set TAGDIR=D:\XXXX\BackUp
    rem 一時ディレクトリ
    set WKDIR=Work
    rem DBBackUpファイル名
    set BACKFILE=XXXX.bak

    set DB_SERVER=AAAAAAA
    set DB_USER=hoge
    set DB_PASSWORD=hoge
    set DB_DBNAME=hogeDB

    rem --------------------------------------
    rem 日時の取得
    rem --------------------------------------
    set YYYY=%Date:~0,4%
    set MM=%Date:~5,2%
    set DD=%Date:~8,2%
    set TIME_TMP=%TIME: =0%
    set TT=%TIME_TMP:~0,2%%TIME_TMP:~3,2%
    set yyyymmdd=%YYYY%%MM%%DD%
    set yyyymmddtt=%YYYY%%MM%%DD%%TT%
    rem --------------------------------------

    rem -S :Server Name
    rem -U :Login User Name
    rem -P :Password For Login
    rem -d :Database Name
    rem -i :SQL Files

    echo "ワークディレクトリ作成"
    MKDIR %TAGDIR%\%WKDIR%

    echo "ワークディレクトリへDBBackUp"
    sqlcmd -S %DB_SERVER% -U %DB_USER% -P %DB_PASSWORD% -d %DB_DBNAME% -i %SQLFILE%

    echo "bakファイルをコピー"
    XCOPY %TAGDIR%\%WKDIR% %TAGDIR%\%yyyymmdd% /Y /C

    F

    echo "Workディレクトリ削除"
    RMDIR %TAGDIR%\%WKDIR% /Q /S

    echo "最新5日分残してそれ以外を削除"
    CD %TAGDIR%
    for /F "skip=5" %%A in ('dir /b /o-n') do RMDIR %%A /Q /S

     

    • 移動 Jundan Wu 2012年10月3日 17:16 (移動元:Windows Server 2008 R2 全般)
    2011年2月15日 15:24

回答

  • echo "最新5日分残してそれ以外を削除"
    CD %TAGDIR%
    for /F "skip=5" %%A in ('dir /b /o-n') do RMDIR %%A /Q /S

    ここらへんが怪しいですね。D:に移動できていないのでは。

    CD /d %TAGDIR% でいかがでしょうか?

     

    2011年2月15日 20:27
  • 「最新5日分を残してそれ以外を削除」より前の処理は、SQLFILEやTAGDIR等、ドライブ名を含めたフルパスで
    処理がなされていると思います。

    ですのでカレントドライブがC:であってもファイル作成やSQL実行等は問題なく実行されるのですが
    最後のCD %TAGDIR% は、D:ドライブのカレントディレクトリを変更しているだけで、
    カレントドライブを変更していないのでは。ですからタスクスケジューラ等から実行されたときに
    カレントドライブがC:になっていて、意図しないC:のカレントディレクトリ以下の
    ファイルを削除してしまっているのではないでしょうか。

    最初のリプライはCDコマンドでカレントドライブとカレントディレクトリを
    一緒に変更するために /d オプションをつけてみてはいかがでしょうかという意味です。

    (Windowsはカレントディレクトリはドライブレター毎に存在します)

    2011年2月16日 12:26

すべての返信

  • echo "最新5日分残してそれ以外を削除"
    CD %TAGDIR%
    for /F "skip=5" %%A in ('dir /b /o-n') do RMDIR %%A /Q /S

    ここらへんが怪しいですね。D:に移動できていないのでは。

    CD /d %TAGDIR% でいかがでしょうか?

     

    2011年2月15日 20:27
  • pitchcat様>

    ご返答ありがとうございます。

     

    >ここらへんが怪しいですね。D:に移動できていないのでは。

    作業用ディレクトリが取得出来ていないということでしょうか。。。

    ただ、エラーメッセージは出るものの、ファイル等は作成されていましたのでバッチでの一連の処理は完了しているようでした。

     

    現状、バッチ実行で確実にシステムファイルが破損するため、修正した上での検証を控えております・・・。

    近々、検証用にサーバを用意して指摘頂いた箇所を確認してみたいと思います。

     

    ------------------------------------------------------------------------------------------------------------------------------------------------------

    ひとまずバックアップに関しては、DBでメンテナンスプラン作成することで回避致しました。

    タスクスケジュールでのバッチ実行でシステムファイル破損するとは思いも寄らなかったので、少しトラウマになりそうです・・・。

    2011年2月16日 2:17
  • 「最新5日分を残してそれ以外を削除」より前の処理は、SQLFILEやTAGDIR等、ドライブ名を含めたフルパスで
    処理がなされていると思います。

    ですのでカレントドライブがC:であってもファイル作成やSQL実行等は問題なく実行されるのですが
    最後のCD %TAGDIR% は、D:ドライブのカレントディレクトリを変更しているだけで、
    カレントドライブを変更していないのでは。ですからタスクスケジューラ等から実行されたときに
    カレントドライブがC:になっていて、意図しないC:のカレントディレクトリ以下の
    ファイルを削除してしまっているのではないでしょうか。

    最初のリプライはCDコマンドでカレントドライブとカレントディレクトリを
    一緒に変更するために /d オプションをつけてみてはいかがでしょうかという意味です。

    (Windowsはカレントディレクトリはドライブレター毎に存在します)

    2011年2月16日 12:26
  • こんにちは、フォーラムオペレーターの三沢健二です。

    pitchcat さん、アドバイスありがとうございます。
    別のドライブに移動する場合は "/D" オプションが必要になりそうですね。
    参考リンク

    直接的な原因がどこにあったのかは色々調べてみないと分からないと思いますが、案内いただいた内容は確認すべきポイントの一つとして参考になる情報ではないかと思いましたので、勝手ながら [回答としてマーク] を付けさせていただきました。

    よろしければ、検証の結果などを投稿いただけるととても嬉しいです。


    それでは、今後とも TechNet Forum をよろしくお願いします。

    ______________________________________
    日本マイクロソフト株式会社 フォーラム オペレーター 三沢健二

    2011年2月25日 1:15
    モデレータ