Posts tagged ‘Backblaze B2’

サーバ*のクラウドストレージ(Backblaze B2)へのバックアップに使っているソフト duplicacyが時々エラーを出していた。※ 調べたら4年近く試行錯誤していたが、最後の対処をしてから半年くらい起こっていないので、ようやく直った感じだ。

*デスクトップでも使っている。

※随分前に書いた気がするものの、探しても出て来ないので、対策しつつ様子を見ていたのかも知れない。

(臭いの問題と同様に)原因が はっきり分からないのだが、バックアップ中のメモリ不足かディスクアクセス過多、あるいはその両方ではないかと推測している。: 通常は問題ないが、(サーバのハード(仮想マシン)は貧弱なので)他に大量にメモリを使うか頻繁にディスクアクセスをするプロセスが一緒に動いていると、問題が起こるようだ。

現象

  • クラウドストレージのprune(古い変更履歴の削除)処理時に、いくつかのチャンク(ブロック)が ないというエラーが出る。
    • エラーメッセージの例(発生し始めた頃のもの, 一部改変した)

2019-07-17 03:41:18.960 ERROR CHUNK_DELETE Failed to fossilize
the chunk fdXXXXXX: URL request 'https://YYYY.backblazeb2.com/b2api/v1/b2_hide_file' returned 400 File not present: chunks/fd/XXXXXX

    • そのチャンクを含むリビジョン(履歴)を削除するかexhaustive prune処理を実行すると、エラーは出なくなる。
  • 問題のリビジョンのバックアップ時にはエラーは出ていない。

謎と検討

妙なのは、デスクトップとサーバで同じようにバックアップしているのに、サーバだけでエラーが起こることだ。しかも、サーバ(VPS)のハードが交換された あとから起こるようになった。 ← 実は その前から起こっていた。(記録のために残す)

そのことから、(OSは同様なので、)サーバとデスクトップのハード(リソースや性能)の違いが関係している可能性がある。

対処

半年くらい前(2022/11)に以下のように対処したら、問題が起こらなくなった。

  • duplicacyのバックアップ処理のパラメタを調整し、使用メモリ量を減らすようにした。
    • オプションに -max-in-memory-entries 51200 を指定した。
      • → 使用メモリ量が200MB前後になった。 (無指定時は600MB以上になる場合があった。: 下を参照)
      • 値を減らすと使用メモリ量は減るが、比例は しない(下限がある?)ようで、10240と かなり小さくしても200MBは使うようだ。
  • バックアップ処理と、メモリを大量に使用してディスクアクセスが頻繁なclamscan(ウイルススキャンソフト)が同時に動かないようにした。
    • どちらもcrontabで定期的に起動している(周期や時刻は異なるが、どちらも実行時間が長いので同時に動く可能性がある)ので、起動前に片方が実行中の場合はスキップし、次回まで延期するようにした(片方が終わるまで延々と延期する)。
      • 今気付いたが、微妙なタイミング(例: たまたま2つが同時に起動時刻になった場合)で同時に起動してしまう場合があるかも知れない。 ← プログラム(スレッドやプロセス)でないので、開始時刻(分)を違えておけば大丈夫そうだ。
    • こちらは上より先に実施したが、問題が全く起こらなくなる訳ではなかったようだ。

分かった切っ掛け

対処方法が分かった(問題が起こらないようにできた)切っ掛けは、ある時のduplicacyの更新内容に「使用メモリ量の削減」というものがあったことだ。※ もしかすると、他の方がメモリ不足でのトラブルを報告したのかと思った。

※僕はそれまで、duplicacyがメモリを大量に使用する可能性があるとは全く意識していなかった。想像だが、duplicacyの重複排除処理(重複ブロック(チャンク)の検索?)でメモリを使うのではないか。

なお、更新されたduplicacyのストレージ(スナップショット/リビジョン)は新しいフォーマットになって使用メモリ量が少なくなるというので、全部のスナップショットが入れ替わるまで(変更履歴の保存期間が過ぎるまで)使用メモリ量の変化を見ていたが、余り減らなかった。最初(duplicacyを更新した直後)が一番減った気がする。

それで、duplicacyと一緒にclamscanが動く時にメモリ不足になって、エラーの原因になるのではないかと推測した。ただ、OSのログにはメモリ不足関連のエラーは出ていないので、正確には、実メモリ(RAM)が不足して仮想記憶(ディスク)が使用されて(スワップ)、処理が遅くなってエラーの原因が発生するのではないだろうか。

duplicacyのエラーメッセージから考えて、原因はバックアップ時にチャンクがクラウドストレージに保存されないことがある(ただ、その時にエラーは出ない)というものだろうから、実メモリが不足してスワップが起こると処理が遅くなって、チャンクのクラウドストレージへの送信が失敗するのではないかと推測している。

処理が遅くなって送信が失敗することがあるとは思えないが、例えば通信のタイムアウトやリトライ処理のタイムアウトなどであろうか。前者とすれば、送信するチャンクのデータをメモリにバッファリングせず、ディスクから読み出しながら送っていて、たまに遅くなると送れないことがある? : いずれにしても、duplicacyの処理のロバスト性が今一つなのかも知れない。

そう言えば、以前duplicacyのフォーラムを調べたら、僕と同様に「チャンクがない」というエラーが出る方が問い合わせていたが、結局「再現せず」や本質的でない回答のあとは放置されて、解決していなかった。

そしてその方は怒っていた気がする。: その方のKopiaのフォーラムへの投稿からduplicacyに戻って、上の問題を知った覚えがある。

そこで、試しにduplicacyのバックアップ時の使用メモリ量の表示をさせてみたら※、600MB以上消費する場合があることが分かった。普通は それくらいは問題ないのだが、サーバのメモリ量は1GBと少ないので*、他のソフトも大量に使用するとスワップが起こりそうだ。なお、prune時は使用メモリ量は小さく、100MB以下だった。

※メモリ量削減と一緒に そういう機能が追加された。

*以前、たまにメモリ不足の問題が起こっていたため、仮想記憶(スワップ)を有効にしていた。その問題が何だったか思い出せないが、やっぱりduplicacyだったのかも知れない。

メモリ不足の他には、duplicacyもclamscanもディスクアクセスが頻繁なために処理が遅くなって、上と同様にチャンクのクラウドストレージへの送信が失敗する可能性も考えられる。更に、メモリ不足と頻繁なディスクアクセスが一緒になると、余計処理が遅くなって更にひどいことになりそうだ。

ちなみに、過去1年のサーバの稼働状況を調べたところ、duplicacyの使用メモリ量を制限した頃からスワップ頻度(ページ/s, 下の左のグラフ: 中央辺りから制限した)が減ったようだ。ディスクI/O頻度(回数/s, 同)に関しては変化は少なく、逆に少し増えた感じだ(ただし、なぜか今年4月以降は小さくなっている)。ディスクを複数プロセスで同時に使うと、効率が低下して全体的な性能が低下するためだろうか。

グラフから、duplicacyのメモリ使用量が大きくてスワップが多かったことは確かそうだ。

※なお、同じ期間のメモリの状態(memory usage)、ディスク動作率(utilization)、ディスクの遅延(latency)、NWの通信速度、システム負荷(load average)に目立った変化は なかったので、グラフは省略した。

考察

いずれにしても、送信失敗時にエラーが出るはず・べきだが出ないのはduplicacyの問題(異常時の処理が甘い)か、これらが原因ではないかの どちらかだろう。

今後問題が再発すれば後者だし、逆に、duplicacyの使用メモリ量の制限を止め、常にclamscanと一緒に動かして問題が起これば、僕の推測が正しいことが分かる。が、面倒だし ほとんど無意味(僕が作ったものでないし、サポートが やる気ない: おそらく「環境の問題」で終わり)なのでやる気は しない。

もしduplicacyの問題だとしたら、「バックアップしたつもりなのに(エラーになっていないのに)、できてなかった」という、結構ひどいものだ。が、起こるのは限られた環境のようだし、駄目になるのは一部のファイルだけなので、致命的とまでは言えなさそうだ。でも、これは遊びのソフトじゃないので、重大な信頼性の欠陥だと思う。

補足すると、特定の環境・状況で処理が失敗するのは仕方ない(すべての環境・状況で使えるものは作れない)が、使った時に失敗したことが分からないのが問題だ。

そう言えば、作者は こういうエラーメッセージ関係の重要性を軽視しているようで、以前、「エラーメッセージ(か終了コード)が誤解する・分かりにくいから変更して欲しい」という要求を拒否していた。

これは単なる表示・見た目の問題ではない。ちゃんと作る(起こり得る すべての失敗を想定・想像する)のは大変だが、製品には必要だ。

試行錯誤

対処方法が分かるまでに以下を試したが、ほとんど効果がなかった。若干良くなるように見えたが、問題は起こった。

  • バックアップ時の送信スレッド数を減らす。: デフォルト: 4個 → 1個 (-threads 1)
  • バックアップ時の送信速度を下げる。: 約250kB/s (-limit-rate 250)など
  • B2のメンテナンス時間帯(毎週1回)のバックアップを避ける。

これより、問題の原因はduplicacy単体ではない可能性が高いことが推察される。 ← 上も動作環境(NWやB2)が関係していることを推測して行ったので、これは言えない。 (22:11)

 

余談

何度か この件をduplicacyに問い合わせようと思ったが、ハードが関係していそうだし、上述のようにサポートが余り親切・適切でなさそうで解決する見込みがないので、止めていた。そして、もし僕の推測した原因が正しかったら、問い合わせても全く解決せず、(いつものように)ただイライラするだけだっただろう。

duplicacyは通常時は問題なく動作しているのだが、上に書いたように異常対応やロバスト性が心許ない気がしているし、サポートの態度にも問題がある。あと、バックアップの対象・除外設定と動作が複雑で頭が狂ってしまう。

そこで、以前書いたKopiaなど新しいバックアップソフトを検討したいが なかなか面倒だし、そっちが良い保証もない。他に やることが溜まっているので、検討するとしても来年と考えている。

 

PS. 書く前は手短かに終わらせようと思って居たが、長くなったし熱くなった(ムカついた)。調べたら長年苦労して来たし、作者がテキトーなのを思い出したせいだ。それにしても、国内・国外関係なく、いい加減なソフト屋が多い。ハードも同様だ(以前も同じことを書いた)。

  •  0
  •  0
Keys: , , , , , ,

数日前に、Backblaze B2(以下、B2)中の もう更新しない(であろう)データをGoole Cloud Storage (Archive) (以下、GCS)に移動する設定を追加して、10日くらい前からほぼ「定常運用」をして居る。以下のグラフを見て分かるように、操作数・データ量などや料金は落ち着いている。

保存しているだけで何もしないなら、毎日、保存データ量分の料金(現状は4円)だけが増える。更新チェック(約3回で1円, 1日1回実施している)や追加バックアップ(量と回数による。: 下を参照)をすると、その分が追加される。

今までに分かったことなどを書く。

  • データ移動(B2→GCS)関係
    • バックアップ対象設定の変更で、B2のデータがGCSに移動するか(B2の保存データ量が減るか)? → Yes.: duplicacy check -statusで各リビジョン(履歴)のデータ量が分かり、将来のprune(不要データの削除処理)で減ることが分かった。
    • 一度に大量に(全部)減らすとpruneに時間が掛かるのと、失敗した場合に大変なので2回に分けて減らすことにした。今のB2のデータ量は約270GBで、来月にもう一度、約270GB分を減らす設定をする。
      • 上を合わせるとB2の残りが0になってしまうが、集計の誤差や重複排除の影響があるため、そうはならない。ただ、残りは かなり少なくなるはずである。
  • GCSのコスト関係
    • ストレージだけの料金の見積もり: 1651円(USD 14.8)/年, 138円(USD 1.23)/月
      • データ量を1TBとし、USD 1= 112円とした。
      • 単価: 0.134円(USD 0.0012)/GB・月
    • バックアップ対象ファイルのチェック(更新チェック)の料金の概算: 3回で1円くらい。 → 約10円/月
    • バックアップ(アップロード)の料金: 推定: 約5円/回(ストレージのチェック) + 約1円/GB
    • 定期更新チェック(1回/日)と追加バックアップ分を含めた年間料金・単価の試算
      • 既存1TB, 追加バックアップなし
        • 支払い額: ストレージ: 1651円 + 更新チェック: 120(30/3*12)円= 1771円(USD 15.8)/年
        • 総合単価: 0.144円 (USD 0.00129)/GB・月
      • 既存1TB + 追加100GB/年 (1回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 105(5+100*1)円= 2038円(USD 18.2)/年
        • 総合単価: 0.151円 (USD 0.00135)/GB・月
      • 既存1TB + 追加100GB/年 (10回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 155(5*10+100)円= 2088円(USD 18.6)/年
        • 総合単価: 0.155円 (USD 0.00138)/GB・月
      • 既存1TB + 追加500GB/年 (1回で追加)
        • 支払い額: ストレージ: 2458円 + 更新チェック: 120円 + バックアップ: 505(5+500*1)円= 3083 (USD 27.5)円/年
        • 総合単価: 0.251円 (USD 0.00224)/GB・月
      • 上より、追加料金はバックアップのデータ量が効くので、回数が多過ぎなければ(例: 月に1回以下)小まめにしても良さそうだ。ただ、「100MBを10回」のように細かいものは割に合わない。例えば、1回10GB以上がいいのではないか。
    • 料金はUSD建てのため、実際の支払額は為替相場に影響される。円が大幅に安くなると困るが、さすがに2倍にはならないだろう・・・
      • Googleのレートは毎日変わっている訳ではないので、毎月更新のようだ。
  • 運用関係
    • B2→GCSの移動対象ファイル・ディレクトリの追加の仕方: 以下のようにすることで、毎年GCSに移すものが増えても、バックアップ対象の設定(duplicacyではfilters)を変えなくて済むようにした。
      1. 移動対象を同じディレクトリに作成した"Archived"ディレクトリに移動する。
        • B2: パターン「Archivedという名前のディレクトリ」をバックアップ対象外にしておく。
          • パターンの例: e:(.+/)?Archived/
            • 注: 設定ファイル内での他のパターンとの順序関係で有効性が変わる。下も同じ。
        • GCS: 同Archivedをバックアップ対象にしておく。
          • パターンの例: i:(.+/)?Archived/
      2. 移動したものを書き込み不可にする。(意図せず変更しないようにするため)
      3. 元のディレクトリにArchivedからのsym-linkを作成する。
    • 数日前に、ストレージに保存されているduplicacyの設定ファイル(config)のストレージクラスをStandardにしてみた。
      • 更新チェックやバックアップのたびにストレージからダウンロードされるので、Archiveクラスだと ストレージ操作やデータ取得の単価が高く(約10倍)、わずかに料金がかさむため。
      • configのサイズはとても小さい(< 1KB)ので、Standardクラスの料金は毎月の無料枠(5GB・月)内に収まる。
      • これにより、更新チェックの料金(現状は約10円/月)が更に下がることが期待できる。
    • 問題など
      • バックアップ先がB2とGCSの2箇所になるので、リストアが面倒(どちらにあるか・どちらからリストアすべきかを考える必要がある)。
        • まずB2で試し、なかったりArchivedに入っていたらGCSからリストアする。
      • バックアップ対象設定を誤る(例: 設定が非対称)と両方にバックアップされず、いざという時にリストアできない可能性があるので、注意・確認が必要。
      • B2とGCSでバックアップのトップディレクトリが異なるので、間違えやすい。
      • バックアップ(HDD)を整理しようとして本物を削除してしまい、B2のバックアップからリストアして復旧できた。
  •  0
  •  0
Keys: , , , , , , ,

Duplicacy(ソフト)+Backblaze B2(ストレージ)でのオンラインバックアップを始めてから、約1か月経った。全般的には期待どおりに問題なく動いており、処理も通信も高速で気持ちがいい。まあ、動作に関しては、自分で作った部分(定期的なバックアップ・prune(不要な履歴の削除)処理やバックアップ条件など)があるので、期待・希望どおりにするまでには結構時間や手間が掛かった。

ちなみに、処理時間を書くと、通常の差分バックアップは、大量のデータを追加しない限り、5分以内で終わる(現在の圧縮後の全データ量: 約420GB、毎回の差分データ量: 約200MB)。また、prune処理は、大量のデータを更新していない限り、20分程度で終わる。

それに引き換え、CrashPlanは全然良くなかった。例えば、CPU負荷が高いと思って調べたら、CrashPlanのバックアッププロセスが延々と(数時間)動いていることが多かった。更新ファイルのスキャンが遅いのか、転送速度が遅くて延々と送信しているのだろう。プログラムがJAVAで書かれているから重いのかも知れない。しかも、GUIがあるのに、その時に何をしているか、何のファイルをバックアップしているかが全く分からず、バックアップしているかどうかしか分からない(ある時から改悪されてしまった)。そんなんだったら、GUIの意味がない。

それで、馬鹿馬鹿しいからCrashPlanを使うのを止めてアンインストールした。そうしたら、(以前からなのだが、)「バックアップがしばらく行われていない」という警告と「バックアップの状態は問題ない」というのが互い違いに(別の仕組みで送っているのだろう)来るようになったので、呆れた。更に頭に来るのは、通知を解除したのに、他にも隠れた設定があるようで、ずっと「問題ない」メールが来続けていることだ。鬱陶しいので、今月半ばの期限前に退会しようと思ったのだが、その方法さえ不明だった(ボタンなどなし)。CrashPlan(Code42)のwebには大手企業のロゴが多く出ていたが、こんないい加減なサービスを本当に使っているのかと思う。

(9/16 10:26追記) CrashPlanからの退会は、なんと、サポートに連絡しないとできないようだ。自動支払いの停止や会員資格の無効化(こういう状態がある意味は不明)はwebで可能だが、退会はできない(退会しないとクレジットカード情報が消せないので、どうしても退会したい)。しかも、サポートは夜間や週末は休みというありさまだった。更に、昨日サポートに連絡して回答がなかったが今朝はログインできなくなっていたので、回答せずに削除したようだ。本当にいい加減で信用できない会社で、入ったのは全く失敗だった。

(9/17 21:13追記) 上記の件、サポート担当は何もしておらず、期限切れで自動的にアカウントが削除されたようだ。というのは、今頃一次回答(「問い合わせが多いので、順次処理しています」みたいなもの)が来たので。まったく冷笑するしかない。 ← (9/18 5:28追記) ログインの手違いだったようで、アカウントはまだ残っていた。本物の回答が来ていたので、再度削除依頼を出した。

カスの話はこれくらいにしてDuplicacyに戻ると、普通のデータ圧縮はもちろん、重複排除がかなり効いている感じだ。例えば、VirtualBoxのWindows 7の馬鹿でかい仮想ディスク(サイズ: 約44GB)が更新されても、バックアップデータの増分は4GB程度で済む。CrashPlanだと延々とバックアップが続くパターンだったと思う。ただ、Duplicacyでも、その4GBのprune処理にかなり時間が掛かってしまう(30分以上)ので、今は、仮想ディスクをコピーして2個(1個は保存用)にし、使う方はバックアップの対象外にしている。とにかく、Windowsはリソースを無駄に消費するから大嫌いだ(スキャンにしか使ってないのに、44GBだって足りなくなって来ている)。一日も早く、完全に脱却したい。

バックアップの頻度や変更履歴の保存数をどうするか迷っていろいろ試していたが、結局、バックアップは8時間ごと(概ね1日3回)にし、履歴は過去1か月分だけ毎週の分を残すことにした(その後は最後のものだけ残す)。なお、prune処理を溜めると処理時間が長くなるようなので、毎日実行している。

今、Backblazeのページを見て気付いたのだが、変更履歴を保存しておくと、ランサムウェア(要は「ウイルス」)対策になるようだ。感染前の履歴(状態)が残っていれば、感染に気付いた時に、そこに戻せるのだ。そういう意味では、1か月もあれば感染に気付きそうだから、現状で良さそうだ。が、保存数や間隔を調整する余地はあるかも知れない。もちろん、ウイルスがB2のストレージを初期化するようなものだったら、「おじゃん」だがw

料金については、先日支払った最初の1か月分が約US$2だったので、年額にすれば2600円程度となる。実際にはもう少し増えて3200円程度になるだろうが、それでも期待どおり安い。CrashPlanの個人用は6千円を超えていたから、約1/2になりそうだ。なお、料金は、保存データ量以外にダウンロードデータ量と特定APIの実行回数でも加算されるのだが、通常時はどれもほとんど無料か数セント程度なので、問題なさそうだ。

ただ、気になっているのは、保存データ量が増え続けることだ。最初は350GB程度だったのが、(その後、貴重な音楽ファイルなどを追加したこともあり、)今は約420GBになっている。ログを見ると、バックアップごとに200MBくらい増えているが、prune処理で200-400MB程度減るから発散はしなさそうだ。が、日々、メールや写真などのデータは増える一方なので、いくらストレージの料金が安いとはいえ、「最後」はどうなるのか心配だ。

実際には、メールや写真だけなら、とんでもない料金になるほど急増することはないので(実際、写真は16GBのSDカードを3年も使っているが、まだ3500枚も撮れるようだ)、当面は問題ないだろうが、その他のデータが増えるかも知れないので、しばらく様子を見ることにする。そのうち、(テープを使用するなどして、速度は遅いけど)もっと安いところや無制限のところが出てくるかも知れないし。Backblazeがそういうサービスを出してくれるとありがたいのだが・・・

(9/10 11:27追記) 昨日のprune処理でデータ量が一気に41GBも減って、約378GBになった。開始から約1か月経過したので、変更履歴が大幅に整理されたのだろう(おそらく、その大半はVirtualBoxの仮想ディスクではないか)。そのため、prune処理が随分長かったが、これで、当面はデータ量に心配する必要はなさそうだw

あと、安いストレージ業者がいくつか見つかった。C14とOVHだ。ただ、どちらにも難点・不明点があり、即座に乗り換えられる訳ではない。前者は操作性や課金方法に癖があって、本当に安くなるかは分からず、後者(Cloud Archive Storage)は課金方法に癖があるのと、うたい文句はすばらしいのだが、関連会社のサービス(hubiC)が悪評高く、しかも、先日からその新規加入を中止しているので、会社としての信頼性には疑問がある。その点でも、prune処理でデータ量が大幅に減ったのはありがたい。

 

(タネが大分減った)

 

(2023/8/3 6:51 関連ページのアクセスが増えているので、期限切れで非公開にならないようにする。)

  •  0
  •  0
Keys: , , , , , ,

ようやく、オンラインバックアップの構成が落ち着いた感じだ。自分でも予想していなかったのだが(でも、いつものことだw)、いろいろな問題が起こって二転三転して、想定外の結論になった。予想外に時間が掛かったし、今後も何かあるかも知れないので、早目に着手して良かった。それにしても、いつものことながら、予想外に疲れた。

結局、僕にはDuplicacyというオンラインストレージ対応のバックアップソフトとBackblazeのオンラインストレージB2 Cloud Storageを組み合わせるのが費用対効果で最適となった。バックアップするデータ量を減らして350GB程度(ストレージでのデータ量)にしたので※、少し余裕を見ても、月額US$2(年間2600円)程度になる見込みだ。(去年終了した)CrashPlanの個人プランは(いくらだったか忘れたが、調べたら)月額US$5だったので、従来の半分以下に(年間4千円程度も)減らせそうだし、後継のビジネスプランは月額US$10なので、来年継続するよりも大幅に安い。

※減らしたのは音楽データである。そのほとんどはCDを取り込んだもので、基本的には、データがなくなっても再度取り込めばいい。ところが、実際問題として、全部なくなった時に再度数百枚のCDを取り込む気にはなれない。が、今はSpotifyがあるから、そこにあるものはそれで聴けばいいだろうと考えた。

すると、バックアップが必要なのは、(ほんのわずかにある)自分の演奏や昔のカセット・LPなどからの曲やダウンロード購入したものや、手持ちやレンタルしたCDのうちSpotifyにないものだけとなるので、そういう曲を選別した。選別は、スクリプトを作って自動判別しようと思ったが、作るのが面倒だったので、手でアーティストごとに検索した。つもりだったが、実際には手持ちのCDについては調べてなかった。それは大変だ。。。やっぱり、お金に任せて全部バックアップするのがいいのかも知れない。

良く考えると、オンラインバックアップからしかリストアできない場合というのは、災害などでPC本体はおろか外付けHDDもなくなってしまった状態だろうから、そんな時はCDだってないだろうから、取り込み直すことはできない。また、Spotifyのレパートリーかどうかで分類すると、別のサービスに乗り換えたら再度分類する必要が出て煩雑だ(これはベンダーロックインのようなものだ)。そうすると、全部バックアップするか、全然しないか、特別なもの(例: 再入手不可能なもの)だけするかになる。全部はいかにも無駄なので、特別なものだけバックアップするのが良さそうだ。そういうものは果たして何枚あるだろうか? (調べるのはおもしろそうだ) → 結構な数になった。めぼしいもの112アルバム(約19GB)を追加バックアップしたら、B2の総データ量は410GBになった。 (8/12 4:14記)

なお、ストレージでのデータ量は圧縮されているため、元のデータ量はもっと多い。今の構成にする時に計算し直さなかったのだが、500GB程度はあるはずで、それが350GB程度までに減ったのはどうも信じられない。Duplicacyの性能がいいのかも知れないが、バックアップ対象設定の誤りで抜けがないか心配なので、追って確認したい。 → バックアップされたファイル一覧で確認したら、問題なかった。今回の構成にする時に更にデータ量を減らしていた。 (8/12 4:14記)

仮に従来と同じデータ量(1TB程度)をバックアップすることにした場合でも、月額US$5.1(年間6800円)程度となり、今までのCrashPlan(個人プラン)と同等になるから、しばらくは実際に掛かった料金を見ながら検討したい。

なお、Duplicacyはファイル変更の履歴を保存できるため、データ量が想定以上に増えないかやAPI実行回数が異常に増えないかの監視が必要だ(どちらも料金が増える原因のため)。

それにしても、バックアップソフトにDuplicacy, Duplicati, Duplicityと、似たような名前のものがいくつもあって、大変紛らわしい。"De-duplication"(重複排除)から来ているのだろうが、最初はどれだったのか気になる。どうでもいいことだが。

それはともかく、試したほとんどのソフトが(機能・性能・安定性の点で)まともに使えなかったのは全く嘆かわしい。Linuxで使うのにシンボリックリンクに対応していないもの、変更のスキャンや転送やリストアや変更履歴の整理(prune)が遅過ぎるもの、スリープ(からの復帰)に対応していないもの、処理を中断すると管理データが壊れるなど堅牢性や安定性に欠けるものなどがあった。僕の環境や使い方が特殊だとは思えないので、細かいことをちゃんと考えて作っていないのだろうか。バックアップソフトでそれは困るのだが・・・

そういう点で、Duplicacyは信じられないほど期待通りの機能・性能(「まとも」)なので感心している。転送速度が安定して高速(おそらくCrashPlanの10倍以上)なのはいいし、初回のバックアップは別として、その後のスキャンもpruneも高速かつ負荷が低い(おそらくCrashPlanの1/5以下)ので、定期実行するにはとても良い。いつものことだが、しつこく探してダメ元で試して良かったw そして、コマンドライン版が無料なのは大変ありがたい。コマンドの使い方が独特なので、GUIの方が楽だったとは思うが、設定が確定した後はGUIの価値はないので、毎年お金を払うよりはいいと思う。

運用の話を書くと、バックアップは6時間ごとに自動で行わせている。バックアップ間隔を短くする価値があるのか良く分からない(今は趣味だけなので、おそらくない?)ので、しばらく状況をみて調整したい。変更履歴は、1週間までは毎日1個、1か月(30日)までは1週間に1個、1年(360日)までは30日に1個残すことにした。これも、どういう設定がいいのか良く分からない。ただ、今まで、履歴を使ったことや欲しかったことがほとんどない(そもそも、オンラインからリストアしたことがほとんどない)ので、多くを保存する必要はない気はする。変更履歴の整理(prune)間隔は1日に1回とした。

バックアップの履歴の必要性について個人的な考えを書くと、おそらく、履歴は要らない。プログラムなどの開発の時に使う、gitなどのバージョン管理システムの方がずっといい。というのは、定期バックアップはいつ実行されるか不明なので、残っているものが必ずしも有用なもの(「欲しかったもの」)とは限らないからだ。手動で実施するにしても、忘れたり間隔が長くなり過ぎる可能性がある。それなら、キリのいい時に自分で(gitなどに)コミット(保存)した方がずっといい。コミット時にコメントも付けられるから、それがどういうものかも分かる。そして、そのリポジトリをバックアップしておけば、安心だろう。

あと、プログラムじゃないもの(例: システムの設定ファイル)については、「あ、やっちゃった!」と思ったら、そのファイル内にコメントとして残しておいたオリジナルに戻すか、記憶で戻すか、あらかじめ保存しておいたファイル(例: *.orig)に戻すか、すぐにバックアップ(もしあれば)から戻すか、再度作り直すかするかwするので、やっぱり履歴は要らない気がする。この場合は、バックアップ自体が役に立たないことが結構ある。

まあ、履歴に慣れ親しんだ人だと効果的に使えるのだろうけど、履歴に頼り過ぎてしまうと、過酷な環境では生きて行けなくなってしまうからw、余り良くないと思う。 (8/12 17:04)

少し話が逸れるが、運用に関連しているので書くと、このブログサーバのバックアップも、最終的にはB2にするようにした。今までは、週一回、PCの外付けHDDにバックアップするだけだったが、今回から、週一回のバックアップをPCの内蔵HDDに行い、そこを外付けHDDとDuplicacyのバックアップ対象にしておき、その後の定期バックアップでB2に送るようにした。実は、サーバにもDuplicacyを入れれば直接B2にバックアップすることが可能だが、サーバにB2のアカウント情報を入れるのは不安なので、このように間接的なことをしている。

実装の話になるが、バックアップなどを定期的に実行するのにはcrontabを使っている。crontabを使う際の問題として、スリープからの復帰後に、スリープ中に行われるべきだったスケジュールが実行されないために※、スリープ中にスケジュールがあると、最長6時間、バックアップが遅れる。そのため、バックアップコマンド(スクリプト)を2時間ごとに起動して、最長(6時間でなく)2時間の遅れで、スリープ中に行われるべきだったバックアップが行えるようにした。そして、そのコマンドの中で、前回からのバックアップやpruneからの経過時間が最小間隔(例: 6時間、1日)より短い場合には何もしないようにして、バックアップ間隔を維持するようにした。なお、コマンド起動間隔の2時間は1時間でも30分でもいいが、そこまで厳密でなくていいので、長目にした。

※実際の動作を見たら、スリープ中に行われるべきだったスケジュールは必ずしも実行されない訳ではなく、スリープからの復帰後に実行される場合がある(例: スリープ中だった14:04のスケジュールが復帰後の15:08に実行された)。ただ、実行されない場合もあったので、その違いが良く分からない。スリープが長時間で、複数回のスケジュールが飛んだ場合は実行を諦めるのだろうか。あるいは、復帰した時刻と実行すべきだった時刻の差で判断しているのか。あるいは、僕の思い違いで、最後に飛ばされた1回は必ず実行されるのか。マニュアルに書いてあるのかも知れないが、無精なので調べていない。 (8/12 16:10)

それから、仮にバックアップ処理が6時間以上に長引いた場合や間違って実行した時に複数のバックアップ処理が同時に実行されるのは良くないので、既に実行中の場合に後から実行したものは何もしないで終わるようにした。こういうのはGUIだと何も考えずに対処されるのだろうが、Linux版がないので仕方ない・・・

余談だが、光回線が予想以上に優秀で、上下同時に使ってもどちらも80Mbps以上出たので感心した。あと、今は基本的に転送データ量での速度制限はしない(以前、「混雑した時に制限するポリシーに変更した」という連絡があった)ようで、数日間、断続的に80Mbps前後でアップロードし続けていても大丈夫だった(いつ警告が来るか心配ではあったがw)。

光回線を上下同時に使っても80Mbps以上出た(左の「金 06」の上の上下に大きく振れているところ)。

(8/12 16:36 若干、加筆・修正; 2023/8/3 6:40 関連ページにアクセスが増えているので、期限切れで非公開にならないようにした。)

  •  0
  •  0
Keys: , , , , , ,