memo.

タグ: Acronis

  • Acronis 12.5のデフォルトDBはSQLite

    Acronis 12.5をインストールしたときに、バックアップ情報を保存する先のDBは、SQLite。ファイルサイズに上限はないが、サイズが増えれば増えるほど、性能には難あり。

    Acronis12.5は、バックアップの情報がよく管理サーバ上で記録されていなかったりする。バックアップのタスクが増えれば増えるほど、不安定なことがあるので、SQLiteがボトルネックになっている可能性が高い。大規模導入なら、他DBMSを選んだほうがよい。

    参考：　https://kb.acronis.com/node/60767

  • 「データをトランザクション ログにフラッシュできませんでした」とWindowsのイベントログに記録される

    Windows Server 2008 R2のイベントログを見ていたところ、「データをトランザクション ログにフラッシュできませんでした。障害が発生する可能性があります。」と記録されていた。

    イベントID: 57
警告: データをトランザクション ログにフラッシュできませんでした。障害が発生する可能性があります。

    該当する時間帯の前後のログを見てみると、Acronis 12で、vSphere6.0のESXi上の仮想マシンのバックアップを取得いる時間であることが判明。つまり、ESXi上の仮想マシンのスナップショットを取得中に発生しており、スナップショットの取得で、一時的に複数のディスクを所有しているように認識されたことにより、発生しているようだ。

    特にサービスにも影響なく、バックアップの時間にだけしか出ていないため、対応する必要なし。

    • 環境
      • vSphere 6.0
      • Windows Server 2008 R2（MSFC環境）
      • Acronis 12(VMware側)

  • Acronis 11.5でバックアップ結果が管理画面で「なし」で表示される

    Acronis 11.5でバックアップの実行結果が管理画面で「なし」で表示される。個別に実行結果を確認すると、バックアップ自体は、動作しており、正常終了している。

    これは、Acronis 11.5と11.7の製品不具合とのこと。

    管理コンソール、エージェント、管理サーバー間のデータの保持構造に問題があるのが原因とのことで、11系では修正されず、Acronis 12以降では修正済みとのこと。

    Acronisは、ちょいちょい不具合がある。クリティカルなものは少ないけど、微妙なあたりが多い。

  • Acronisは、大量ファイルのバックアップが苦手

    何故だ？と思っていたのだが、10万（100,000）を超えるファイルのあるフォルダをバックアップする場合、エージェントが”Itzam”フォルダーを作り、そこにファイルリストを作成し、バックアップするとのこと。この動作により、動作が遅くなる、そしてファイル数が増えれば増えるほど、一時的にとはいえ”Itzam”フォルダーの容量が増える。こういう仕組みなので、Acronisで大量のファイルをバックアップするときは時間もかかるし、ハングアップもしやすくなる。

    Acronisは、ドライブ丸ごとの「イメージバックアップ」は得意なので、大量のファイルをバックアップするときは、フォルダやファイルでのバックアップではなくて、不経済かもしれなくてもドライブごとのイメージバックアップを取得した方が速いし、確実に行える。

    Acronis Backup: “Itzam” フォルダー
    https://kb.acronis.com/node/49682

  • RegOpenKeyExW ～がイベントに記録される

    Acronis Backup でバックアップを実行した際に、以下のエラーがイベントログに出力される。

    ボリューム シャドウ コピー サービス エラー: ルーチン RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...)
の呼び出し中に予期しないエラーが発生しました。hr = 0x80070005, アクセスが拒否されました。  。   
操作:    バックアップを初期化します

    原因は、DHCPサーバの機能が追加されており、DHCPサービスのアカウントが
    追加されていると SYSTEM\CurrentControlSet\Services\VSS\Diag以下の
    レジストリキーを上書きされている。
    そのため、アクセス許可が無いためにエラーが記録されるとのこと。

    参考

    https://support.microsoft.com/ja-jp/kb/2298620

  • Acronis Backup & Recovery 11.5で、バックアップタスクの所有者が変更されないバグ

    何かと不具合の多いAcronis Backup & Recovery 11.5。
    バックアップタスクの所有者の変更についての不具合がある。

    本来であれば、バックアップタスクは最終更新者が、そのタスクの所有者になる。
    この不具合では、最終更新者が更新しても、バックアップタスクの所有者が更新されない。
    ちなみに、バックアップ計画（タスク）作成時のアカウントがバックアップをできる権限を
    もっているアカウントであれば、所有者が変わっても問題なくバックアップは行えるとのこと。

    不具合として、Acronisが認識しているようで、いつかはわからないが、 不具合は修正されるとのこと。

    そもそも、最終更新者が所有者になるという仕様もいけてない。
    さらにいけてないのは、不具合で所有者をあるべきユーザにすら戻せないということ。
    しかもバックアップ計画の作成時のユーザで認識されてバックアップが行われる、
    というのであれば、そもそも所有者の意味はなんだ？

  • Acronis Backupで大容量のバックアップが取れない

    Acronis Backup で大容量のバックアップが取れない、という問題が発生している。

    事象としては、大容量のデータがあるファイルサーバのバックアップを行うと、
    1回目は正常に終了するが、2回目以降のバックアップで、バックアップが開始されたまま
    バックアップ進まず（進行状況が0%のまま）に、そのまま止まってしまう。

    確認されている環境は、Acronis Backup 11.5、バックアップ対象がWindows Server 2012 。
    バックアップデータが1.2TBを超えると、AcronisのバックアップDBが処理を行えずに
    ハングアップするというバグとのこと。
    現行では、修正プログラムを開発中で、Update6でリリースされる予定とのこと。
    （本当にUpdate6に入るかどうかは不明）

    回避策としては、バックアップ後の管理DBのサイズが1TBを超えないように、
    小さい単位でバックアップ設定を行っていくこと。

    バックアップ製品なのに、大容量のバックアップができないなんて、最低。

    追記（2014/10/29）

    フォルダ単位でバックアップの設定をし、1TBにならないようにしたが、
    結局、状況は改善せず。
    サイズ的には200GB程度までしぼった。
    ファイル数が多いのが原因だろうか。