1

--- ファイル makebackup.sh

#!/bin/bash
DATE='date'
mysqldump --all-databases | gzip -9 > /backup/temp_db.gz
tar -Pcf /backup/temp_ftp.tar /public_html/
tar -Pcf /backup/temp_backup.tar /home/temp_db.gz /backup/temp_ftp.tar
sleep 60 && /backup/upload.sh $DATE

--- ファイル upload.sh

#!/usr/bin/expect -f

# connect via scp
spawn scp /backup/temp_backup.tar root@mybackup.com:/home/backup_$argv.tar
#######################
expect {
-re ".*es.*o.*" {
exp_send "yes\r"
exp_continue
}
-re ".*sword.*" {
exp_send "mypassword\r"
}
}
interact

なぜこれがうまくいかないのか、sleep を使いたくないので、前回の tar がいつ終了したかを知り、upload.sh ファイルを実行する必要があります。代わりに、最後の tar ファイルが開始されるとすぐに実行されます。

&&はsleep 60を外しても何もしません

4

1 に答える 1

0

「代わりに、最後の tar ファイルが開始されるとすぐに実行されます」と言うように、通常は、行末に「&」があることを意味します。または、tar が本当に機能していると確信していますか? 初期に作成された古い tar.gz を見ていますか? 正しいサイズの新しい tar ファイルであることを確認してください。 編集ファイルを削除する必要があると言っているわけではありません。最終的なtarに何が含まれているかをdbl-checkしてください。

最終的な tar コマンドへの入力ファイルのサイズをチェックしていますか? (/home/temp_db.gz /backup/temp_ftp.tar)? 編集これはつまり、圧縮されていない tar ファイル (temp_ftp.tar) は、含まれるすべてのファイルのサイズの合計よりもわずかに大きくなければならないということです。temp_ftp.tar を構成するファイルが 1 MB あることがわかっていて、そのファイルが 1.1 MB であれば問題ありません。0.5 MB であれば問題ありません。(リモート ホストへの送信時間を短縮するために、全体を gzip することも検討してください)。圧縮された db ファイルは、おそらく機能しているとは言い難いですが、ファイル サイズが 25 バイト程度の場合は、ファイルの作成中にエラーが発生したことを示しています。

そうでなければ、あなたの言っていることは本当に不可能に思えます。それはこれらのことの1つであるか、他の何かが物事を盛り上げています.

最後の tar にかかる時間をデバッグする 1 つの方法は、コマンドを 2 つの日付コマンドでラップすることです。

date
tar -Pcf /backup/temp_backup.tar /home/temp_db.gz /backup/temp_ftp.tar
rc=$?
date

printf "return code from quick tar was ${rc}\n"

また、タイトル「前のステップを確認してください」に従って、tar からのリターン コードを取得し、値を出力することを追加しました。

繰り返しになりますが、Linux シェル スクリプトでは、前のコマンドが完了する前に 1 つのコマンドの実行を開始する方法はありません (「&」文字を使用したバックグラウンド ジョブを除く)。

ファイルの所有権と権限を編集すると、ファイルの所有権と権限が台無しになる可能性があります。使用する \

ls -l  /backup/temp_backup.tar /home/temp_db.gz /backup/temp_ftp.tar

自分のユーザー ID がファイルを所有していて、それらに書き込めることを確認します。必要に応じて、投稿を編集してその情報を含めます。

また、見出しには「cron」と書かれています。状況のデバッグに役立つように、このスクリプトの可能なすべての出力をキャプチャしていますか? set -vxmakebackup.sh の上部付近でシェル デバッグをオンにします。デバッグ出力を tar コマンド '-v' に追加します。

次のようなプロセス全体のcron出力をキャプチャします

59 23 31 12 * { /path/to/makebackup.sh 2>&1 ; } > /tmp/makebackup.`/bin/date +\%Y\%m\%d.\%H\%M\%S.trace_log

また、エラー メッセージが表示されていないことを確認してください。

( Crontab サンプル、min hr day mon (曜日、0-6 または *) 、テストのニーズに合わせて日付/時刻を変更)

あなたの期待スクリプトは '\r' を使用していますが、Unix/Linux 環境で '\n' は必要ありませんか? Windows ベースのサーバーの場合は、 '\r\n' が必要です。

編集はスクリプトが正常に機能することを期待していますか? ファイルがコピーされていることを確認しましたか? バックアップ サイトでファイルのサイズは同じですか? 日付は変更されていますか?

バックアップによっていつかシステムが救われると期待している場合は、プロセス全体がどのように機能するか、およびそれが期待どおりに機能しているかどうかをよりよく理解する必要があります。状況と代替コンピューターの可用性に応じて、バックアップの復元のテストをスケジュールして、それらが実際に機能するかどうかを確認する必要があります。-P を使用してフルパス情報を保存しているため、作業中のシステムを古いファイルで上書きしないように注意する必要があります。

私のアドバイスを要約すると、すべてを再確認してください。

これが役立つことを願っています。

于 2011-12-16T03:09:03.120 に答える