web-dev-qa-db-ja.com

バックアップファイル-削除しても安全ですか?

最初にローカルディスクに書き込み、次にディスクがリモートでバックアップされるバックアッププロセスがあります。バックアップ(ログ、差分、完全)のたびに、ローカルディスク上のすべてのファイルを削除します。 SQL Serverはこれに気付きますか?

MS SQLはbakファイルを読み取って、何がバックアップされ、何がバックアップされていないかなどを確認しますか?

AWSに、バックアップ専用のディスクを備えたデータベースがあります。すべてのバックアップ後に、ディスクのスナップショットが(AWS CLIスクリプトを介して)取得されます。これで、ディスクとスナップショットにデータができました。ディスクのコストは月額200ドル以上です。

バックアッププロセスを変更してディスクを作成し、バックアップを実行して、スナップショットを取り、ディスクをドロップします。この方法でログファイルを変更すると、SQL Serverは混乱しますか?

2
Patrick

バックアップ(ログ、差分、完全)のたびに、ローカルディスク上のすべてのファイルを削除します。 SQL Serverはこれに気付きますか?

Oracle などの他のデータベースソリューションとは異なり、SQL Serverにはネイティブにcross-checkバックアップファイルがディスク上にまだ存在するかどうか。バックアップファイルのメタデータは msdbのバックアップ履歴テーブル に保存されます。これらのテーブルは、バックアップの実行時に入力されるため、バックアップコマンドの完了後に行う変更(OSからのファイルの削除、ドライブなど)はここでは追跡されません。

質問に答えるために、SQL Serverがファイルを作成できる限り、その後のファイルの操作は関係ありません。

バックアッププロセスを変更してディスクを作成し、バックアップを実行して、スナップショットを取り、ディスクをドロップします。この方法でログファイルを変更すると、SQL Serverは混乱しますか?

繰り返しになりますが、ドライブへのバックアップを作成できる限り(たとえば、権限が正しい、ドライブに十分なスペースがあるなど)、SQL Serverは、事後のドライブまたはファイルの処理を気にしません。

これらのファイルがすぐに利用できないことを気にかけてデータベースを復元する必要があるイベント?他の質問に対する私のコメントが述べているように、DBAの主な仕事は、常にデータベースを回復できるようにすることです。障害が発生した場合にデータベースを迅速に回復するのを妨げるようなことをする場合は注意が必要です。

2
John Eisbrener

特に「AWS CLIスクリプトを介して」話すことはできません。しかし、SQLはバックアップの場所を気にしません。それは彼らが連れて行かれ、どこに書かれたかを知っています。

[〜#〜] tsm [〜#〜] のようなシステム全体のバックアップ製品を使用して、SQLバックアップとマシンの残りの部分をバックアップするとします。

フルと差分を削除しないでください、それらを上書きします。

午前6時にフルバックアップまたは差分バックアップを実行し、正午にリモートでバックアップする場合。翌日の午前6時に安全に上書きできます。

ローカルのtログがリモートの場所にある場合は削除できます。 「事故」(誰かが何か愚かなことをした)回復のためにローカルで24〜48時間残しておくとよいでしょう。

リモート(TSM)バックアッププロセスを実行する前に、SQLバックアップが完了していることを確認することが重要です。 TSMのような製品はmdfやldfファイルのような使用中のファイルをバックアップしないため、SQLバックアップを作成します。また、オフサイトバックアップ中に書き込まれたSQLバックアップもバッ​​クアップされません。バックアップファイルを追加して7週間の実験を行いましたが、TSMは実験が終了するまでサイトのバックアップを移動しませんでした。

オフサイトバックアップ、オフサイトバックアップソリューション(IBM Spectrum)がtrnファイルをバックアップしていないようです。これは、ファイルが常に編集されているためと考えられます。 ソース

オフサイトの場所からの復元を使用して、バックアップソリューションを定期的に検証してください。

2
James Jenkins