リンク:ブログ紹介、現在のバックアップ体制(トップ記事に固定)
次の記事で本ブログの紹介、現在のバックアップ体制を書いています。バックアップ体制は内容に更新があれば、記事の内容を反映しております。
https://blueecho.hateblo.jp/entry/2019/03/10/232151 (2021-06-09 更新)
Facebook で自分が書いた記事の検索方法
画面左上の検索ツールで検索語の指定に加え、検索の範囲を指定可能である。フィルターで種類を投稿に限定し、自分が書いた記事のみとすれば、比較的簡単に自分の過去記事を探す事が可能である。
Amazon Glacier Deep Archive を試してみる
先日に Amazon Glacier Deep Archive の存在を知り、データを預けるだけならば料金は安い*1ので、HDD へのバックアップとは別に、更新が行われる事が無い自作データを Deep Archive へもバックアップを行ってみます。
とりあえず、現時点で Deep Archive へバックアップするデータは1昨年以前の写真データなど、完全に更新が止まっているデータとします。これらのデータは既にパソコンのディスク上にはなく、外付け HDD へ保存場所が移されています。その HDD のバックアップも別の HDD にあるのですが、いずれそのバックアップ HDD の寿命もくるので、長期的にはハードウェアの交換は行う必要があります。外付け HDD のバックアップ HDD の様な使用頻度が低いものは、場合によってはハードウェアの更新はせずに、クラウドバックアップのみに切り替えても良いかなと。
日本のデータセンターに預ける場合は、1TB で年間約24ドルです。自分が現時点で預けたいデータ量の300GB程度なので、費用は少なく見積もって年6ドルなので、この値段ならばコストはほぼ無視できるかなと思います。(ただし、取り出しは別途費用が必要)
とりあえず、本日時点ではまだバケットを作り、いくつかディレクトリをアップロードしただけです。追加報告があれば、本記事に追記または別の記事に書こうと思います。
Deep Archive で使う場合に注意が必要なのは、アップロードする対象(ファイルまたはディレクトリ)を選び、「アップロード」ボタンでアップロードの開始をする前に、ストレージクラスで "Deep Archive" を選択する操作を行わずにデフォルトの設定でアップロードをすると、ストレージクラスがスタンダードでファイルがアップロードされる事です。
このオプションは前回に設定した値を覚えていてくれるという事はないので、Deep Archive へ保存したい場合は、アップロード毎に行う必要があるみたいです。
*1:取り出しには別途料金がかかる。基本的には取り出しを行わない、または頻度が低い場合に低価格で使える事が売りのサービスです。
スラドでのバックアップ関連のスレッド
srad.jp で見つけたバックアップ関連のスレッドのリンクをリストしました。
これらのスレッドを何件か読むとバックアップ(の失敗)あるあるであり、自分には参考になっています。他人様の失敗を読み、「ああ、バカやっているよなぁ」と思うが、振り返ってみてみると、自分も同じ事をやっていること多し…。
ミラーリングはバックアップにはならない
スラドに聞け:おすすめのOSバックアップソフトは?
バックアップ、してますか?
20TBのデータ、どうやってバックアップをとる?
間違ってデータベースを削除してしまったらどうする?
20年以上デジタルビデオを保存するには?
面倒なバックアップは何でやる?
データ消失対策といえば
クラウドを使ったサービスデータ消失が発生したら、責任は誰が取る?
HDDクラッシュ!そのときアナタは?
レンタルサーバー「ファーストサーバ」で大規模な障害が発生
ファーストサーバ、大規模障害の中間報告を発表
ファーストサーバ、大規模障害の最終報告書を受領・公開
GitLab.comが誤って本番DBを削除、バックアップも取れていなくて大騒ぎに
俺のバックアップを聞け!
俺のバックアップを聞け!2018
日本年金機構からの情報漏洩、ウイルス入り添付ファイルを開いたのは一人だけではなかった
適切な命名規則で操作ミスを防げ
イメージバックアップのファイル整合性チェックは必須
今までにバックアップ、リストアではそれなりに(いや、かなり?)失敗しているので、これは避けろ!という情報を何回か共有いたします。
一番ピンチになった失敗はディスクイメージバックアップで、バックアップが壊れており、戻せなかった件です。(ただ、結果としては運よく助かった)
障害発生に至った状況は次の通りです。前提として、マシン全体のディスクイメージのバックアップを週単位で取っている際に起きています。
障害に至る状況
- 問題を起こしてしまったのは2015年。Windows 7 から Windows 10 への更新を試みるが、使用中ソフトウェアの互換性チェックで一部パスしないものがあるので、Windows 10 への移行を撤回した。
- Windows 7 に戻すが、Windows 7 の Windows Update が動かなくなっている事が判明。*1 Windows Update が動かないのは困るので、バックアップからリストアする事にした。
- リストアをするが、リストアが途中までしか進まずに失敗する。(その状態では当然ながら Windows は起動しない)
- バックアップは当月、前月くらいの分は週単位、それより前のバックアップも月単位であり半年程度さかのぼれたが、いずれのバックアップでもリストアに失敗*2
- 各バックアップを調べると、整合性チェックでエラーが検出され、結果として現実的に戻したい範囲のバックアップファイルはいずれも整合性に問題があり、全滅が確定した。 (;_;)
(何か別の作業で取った)1年くらい前のバックアップはあり、そのバックアップからのリストアは成功したので、マシンが1年くらい前の状態へ戻った状態でしばらく呆然としていたのですが、次の策でたまたま運良く最終的には問題ない状態まで戻せました。
運良く成功した復旧までの流れ
- もう一度、直近のバックアップのリストアを出来るところまで行う(当たり前だが、前回と同じ箇所まで進み最終的には失敗した)
- Windows を起動ディスクで起動し、ユーザーデータがどの程度、復旧できているのか見てみる。(dir コマンドで当該のファイルの日付、日時、サイズを確認)なんとこの検査で、リストアできないと困るファイルが確認出来る範囲では全てリストア出来ている事がわかる。*3
- 外付け HDD を付けて、再度 Windows をシステム修復ディスクで起動する。
- 外付け HDD へユーザーデータをコピー
- マシンへ再度、Windows 7 を再度、インストール、セットアップ
- 必要なアプリケーションもインストール、セットアップ
- 三つ前の手順で外付け HDD にコピーしたユーザーデータを戻して、復旧完了
問題の原因と反省点
リストアに失敗した理由は前述の様にバックアップのファイルが破損していた事です。当時使用していたバックアップソフトでは、バックアップの整合性チェックを行うオプションはあるのですが、これがデフォルトではオフに設定されていました。*4この点を自分は意識する事無くオフのまま運用していたので、いつの頃からか、せっせと破損しているバックアップファイルをこさえていたのでした。
リストアは本記事の作業の前に何度か行っており、いずれも成功していたので、間抜けなことにリストアに失敗する事自体を想定していませんでした。何度のリストア成功体験故に、躊躇無くリストアを行った事自体は責める点ではないと思うが、リストアの手順の見直し、更新がなかったのはまずかった。
アクションアイテム
- バックアップの整合性チェックは必ず行う。バックアップデータのサイズと作業に取れる時間の制約でバックアップ時に整合性チェックを省かざるを得ない場合も後日に必ず行う。
- リストアの前に使用するバックアップの整合性に問題が無い事を確認する
必要不可欠なソフトウェアのインストーラーはディスクで持っておく
本ブログで記事を書こうと思っていたのだが、忙しさにかまけて何もしておらずとなっていました。先日にパソコンを新調し、データの移行を行い、トラブルもあったので、気が向いたら何本か記事にします。
前述した通りにパソコンの新調にともない、新マシンに旧マシンで使っていたソフトウェアの再インストールをしたのですが、ここでの失敗談。
結論: 必要不可欠なソフトウェアのインストーラーはディスクで持っておく
ここ20年以上使っている、自分には重要なソフトウェアがあるのですが、これが既に開発は停止しており、(作業時には自分は知らなかったのだが)ネット上での入手手段もなくなっています。今回のマシン移行ではこのソフトウェア関連でトラブルがあり、(最終的にはソフトウェアのインストールはできたのですが)今回のトラブルの経緯は次の通りです。
- 新マシンへのソフトウェアのインストールを行おうとする。インストーラーのディスクは旧マシンに保存しているので、そこからファイルのコピーを行おうとする。
- 旧マシンの当該のディレクトリを見ると、なんとコピーしたと思っていたインストーラーのファイルがない!
- インストーラーのファイルをネットで探すが、(以前は入手できたのだが)今年に公開が停止された様であり、ネットでの入手手段もない。
- 旧マシンの更に一つ前に使っていたマシンの最終バックアップ(マシンのディスクのイメージバックアップ)でファイルを探す。ここにはファイルがあったので、そこからインストーラーを復旧。
- 復旧したインストーラーを使い新マシンへソフトウェアをインストール。この作業で最終的にはインストールに成功。
2. の旧マシンで目的のファイルが無い点ですが、同ディレクトリは他のソフトウェアのインストーラー、ドライバなどを置いていたが、他にもあるつもりでいたが、実際には無かったファイルがありました。恐らくこのディレクトリの内容自体が更に前のマシンから引き継いでいるので、旧旧マシンから旧マシンへのファイルの引き継ぎの際にコピーに失敗していたのでは?と思います。
最終的には旧旧マシンのバックアップが無事で事なきを得ているが、代替が出来ないファイルは HDD へのバックアップに加え、ディスクにも記録しておいた方が良いですね。
Acronis True Image 2019 の使用を開始
本ブログでは自宅の私物マシンのバックアップに関して書いているのですが、勤務先のマシンに関して更新をおこなったので情報共有までに記入します。
実は最近、勤務先で使っている Windows 10 の調子が悪く、Windows 10 のバージョンを 1809 に更新後に、Windows の標準機能のバックアップを使ってのシステムイメージの作成が失敗する様になっていました。業務機のバックアップは主にシステムイメージを柱に行っているので、早急に対策が必要な状況となっていました。
類似の事象としては次のスレッドにも報告があります。
- After Windows 10 version 1809 update Build 17763.1, my Backup and - Microsoft Community
- Windows10 1709適用後バックアップが出来なくなってしまいました - マイクロソフト コミュニティ
自分のマシンでは OneDrive でオンデマンドでのファイルの設定を外す事でシステムイメージのバックアップが再び動く様になったのですが、以前と比べてバックアップに要する時間が長くなっており、本当に使えるのか疑問であるので*1、思い切ってサードパーティーの専用ソフトの導入を決意。
実は Ture Image 2019 の前に2つ他社のものを試したが、これらがいずれもイメージバックアップの作成に失敗する!
勝手に推測すると、VSS が変になっているような気がします。(ただ、Windows のログで VSS 関係の明らかなエラーが記録されてはいなかった・・・)続いて試した True Image 2019 では問題なく、イメージバックアップの作成に成功。ファイルのリストアもいくつかためした限りでは大丈夫なので、業務期のバックアップの柱は True Image 2019 にする事決定です。
True Image は以前から名前を知ってはいたが、無償版が無かったので、自分は初めて使ったのですが、バックアップが比較的早く終わるのは予想していなかったプラスアルファです。
ディスクスペースを 350 GB 程度使用の業務機のバックアップと検証がフルバックアップでも 40 - 50 分で終わる*2ので、この所要時間が安定的に見込めるならば、フルバックアップは週1度、その他平日は増分バックアップのスケジュールの実行を行い、毎日実行というのも現実的かなと。