Archive for 10月, 2021

結構前からSpotifyで少し配信されて居たのを試しに聴いてがっかりしたので全然興味なかったが、今日 発売配信されたのを知って ちょっと試してみたが、やっぱり駄目だった。時間(とお金)の無駄だ。

  •  1枚目のメインのリミックスはオリジナル(1970, 2009リマスター)より音(音質, 音作り)が悪い。あと、アレンジ(ミックス)も悪い。
    • 音の悪さは2曲目の"Dig a pony"から感じた。特に、低音のドラム(バスドラ?)が潰れたような音だ。
    • 音がすっきりしていない、抜けが悪いという点で"Mono masters" (2009)に通じるものがある感じだ。
    • 3曲目の"Across the universe"もひどい音で、イントロから不自然な感じだ。それから、元々大げさな演奏なのに、コーラスが更に不自然になり、オケは更に大げさになってしまった。
    • ここまで聴いたところで嫌になって止めた。
    • 例の世襲プロデューサーのセンスが悪いのだろう。自己満足の改悪は止めて欲しい。
  • 2, 3枚目のセッションだのリハだのジャムは映画"Let it be" (1970)さながらの たるんだ演奏(感想の例: (3枚目)"Get Back - Take 8": 「以前の曲((2枚目)"Don’t Let Me Down - First Rooftop Performance")同様、気の抜けたサイダーもいいとこ・・・」)にがっかりした。(Spotifyの配信で数曲しか聴いてない)
    • がっかりするのも当然で、いい演奏なら当時出していたはずなのだ。出せないレベル(みんなが放り投げた)だったから、今まで残っていたのだ。
  • 4枚目のGlyn Johnsミックス(1969)は海賊盤で持っている(1970年版も)し、そもそも中身が余りおもしろくなかった(「オリジナルよりずっといい」とは言えない)ので、今出ても聴く気が起こらない。
  • 5枚目の"Let it be EP"は何のためにあるか不明で、やっぱり おもしろくなかったが、このセットの中では一番まともな気がする。

結局、僕にとっては、スペクターの労作であるオリジナル版(音質の点では2009リマスター)が一番いい。確かに、アレンジで やり過ぎな面もあるが、上に書いたように そのままでは どうしようもなかった素材を実にうまくまとめ上げたと思う。だから、"Let it be... naked" (2003)の音自体はシンプルでいいけど、やっぱりしっくり来ず、積極的に聴く気になれない。むしろ、-nakedが出てオリジナルの良さを再認識したくらいだ。

 

そして、なぜ、この5枚組にもなるデラックスなアルバムには「ルーフトップ・コンサート」が丸ごと入ってないのだろうか? 僕はこれが一番聴きたい。てっきり、2か3枚目がそうなんだと思って(良く確かめずに)掛けたが、違っていた。 → 映画(ドキュメンタリー)で出すからか。 ← 11/25から公開だそうだから、その前に音を出しちゃったらネタバレみたいになってしまうからか。

そして、そのあとにそのCDなどを(何種類も)売り出して、「二度おいしく」なるのを期待しているのか。もう、立派なビートルズ商法だ。

 

PS. 豆知識(というか知らなかったこと): 「リハーサル」の綴りは"rehearsal"だった。当てずっぽうで"reharsal"と打ち込んだら、スペルチェックで引っ掛かった。"hear"が入っているのは 分かるような気がするが、発音には出ないので妙な感じ。

他に、関係ないけど英単語関連で、同意・承諾(音は「コンセント」)を"concent"と打ったら違っていて、"consent"だった。前者は日本の「コンセント」なのだが、単語としてはあるものの一般的ではないようだ。これを送ったら笑われるところだったw

  •  0
  •  0

いつものように四苦八苦しつつも(そのため、気付いたら前回から10日も過ぎて居た)、昨日、Google Cloud Storage (Archive) (以下、GCS)への初期バックアップが終わった。約一週間掛かりだった。途中で欲が出て、予定していた音楽のファイル以外に古い写真や本など いろいろ追加したため、データ量は予定の2倍の約900GBになった。

というのは、あとにも書くが、滅多にアクセス・変更しないのであれば、現在使っているBackblaze B2(以下、B2)より維持費(アイドル時の料金)がずっと安く済むので、その分、多くのデータを保存できるからだ。

以下に、これまでに分かったことや印象・感想などを書く。

  • 信頼性(GCS + duplicacy): なぜか変な問題が起こったが、(おそらくの)原因が分かって再発しなくなった。
    • 現象: チャンク(ファイルを分割したファイル)が1個なくなった。 (→ その後、問題発生時には同時アップロードスレッド数分なくなることが分かった。)
      • バックアップ時にduplicacyやGCSからエラーは出ていなかった。
      • そのチャンクは確かにGCSになかった。
    • いろいろ調べて何とか復旧した。 (→ 参照)
      • 簡単だけど面倒だ。
    • ただ、今まで(ストレージがB2の場合)は起こっていなかったので、どうしてか気になった。相性問題?
      • チャンク約6万個のうちの1個で 低い確率ではあったが、「滅多に起こらない」とは言えない。
      • 現象は異なるが、サーバからB2にバックアップしたもののprune時に たまに「チャンクがない」エラーが起こっていたので、duplicacyに問題があるのかも知れない。
        • この問題は、B2のメンテ中にアップロード(バックアップ)したせいで起こっている(やっぱり、サーバからのエラーがduplicacyに伝わってない?)と想像し、定期メンテ中のアップロードを避けるようにして様子を見ている。
      • → いろいろ調べたら、データをアップロードしているPCの一時IPv6アドレス(temporary IPv6 address)の更新の影響のようだった。
        • 直接の原因は自分で変えた設定が不適切だったことだが、他のプログラムは今まで問題なく動いていたので、そればかりとは言えない。 → 詳細は下記 「一時IPv6アドレスの更新の影響について」を参照のこと
    • → 一回だけでなく再発したので、チャンクサイズをデフォルトにして試したが、効果はなかった(やはり再発した)。
      • アップロード速度が低下したが、バックアップのスレッド数を6に増やしたら、家のVDSLのアップロードの最高速度近くの32Mbps前後まで出るようになった。
    • duplicacyは、このような問題をcheckコマンドで検出できるのがいい。
      • rclone(ファイル単位でバックアップする)だったら おそらく通信エラーになると思うが、(duplicacyと同様に)エラーにならずにファイルの全部または一部がなくなったり、異常になったりする可能性もある。それは(何もしなかったら)バックアップ直後には検出できなので、リストア時に途方に暮れることになる。
        • バックアップ後にチェックするにしても、rcloneは管理情報は持っていないので、自分で、バックアップしたファイルがストレージにあるか調べる必要があり、なかなか面倒だ。まあ、rcloneをdry-runモード(あれば)で動かせば、ファイルの有無とサイズの違いは分かるだろうが、おそらくduplicacyより高く付きそうだ。あと、中身の異常までは分からない(それはduplicacyも同じ)。
    • 上の問題の他は、バックアップしたファイルの抜けや一部をリストアして中身をチェックをしたらOKだったので、(当然のことながら)信頼できそうだ。
      • こんなところで駄目だったら、世界中のユーザーが叩くに違いない。そもそも、そんなのはGoogleでない。
  • 有用性: やっぱり(僕には)バックアップは必要不可欠だった。
    • バックアップのチェック中に誤って本物のファイルに上書きしてしまい、いくつかサイズを0にしたり変な名前のファイルを作ってしまった。
      • 原因: awkの使い方の失敗: 一時ファイル名がおかしくて上書きしたようだ。
        • 変な名前は空白のあるファイル名が分割されてしまった。
    • → でも、早速GCSからリストアして復旧できたので「セーフ」だった^^
      • 手元のバックアップHDDからでも良かったが、試しにやってみた。
  • 料金: GCSとB2を併用した場合、通常(アイドル)時は現状(B2のみ)から4割(100円/月)近く安くなるはず。
    • 連日、コンソールを頻繁にチェックして、更新・集計のタイミングや内訳が分かり、ある程度、料金表に合う額が計算できるようになった。
      • 料金(Report)は1日2回以上更新される。
        • 項目によって更新時期・頻度が異なるようだ。
        • 内訳は金額(円)でしか出ない(データ量などは出ない)ので不便。
      • 操作の回数、送受信データ量などは、モニター(Monitoring)で ほぼリアルタイムに更新される。
        • ただし、全データ量とオブジェクト数が更新されるのは1日1回。
    • 事前の見積もりどおり、1TBのリストアをすると約2.1万円になるだろう。
      • 安くはないが、保険だし、データに値段はないので仕方ないだろう。
      • それに、維持のための料金を払える限り、一度に全部リストアする必要はないので、そうすれは安くなる。
    • 現状(初期バックアップ完了後, 10/14 10時頃)の使用量と料金
      • 使用日数: 約13日間 (約半分は試行錯誤)
      • 格納データ量: 約900GB
      • 削除したデータ量: 約700GB (試行錯誤のため)
      • 操作数: 約28万
        • Class A (主にWriteObject): 約26万
        • Class B (主にGetObjectMetadata, ListObjects): 約2.4万
      • GCSの送信データ量(≒ ダウンロード(リストア)データ量): 約13.5GB
      • GCSの受信データ量(≒ アップロード(バックアップ)データ量): 約1.6TB
      • 料金: 3055円: 以下に内訳
        • Class A操作(書き込み系): 1525円
        • Class B操作(読み出し系): 90円
        • データ取得: 90円
        • データ格納(us-west1): 31円
        • データの早期削除: 1161円
        • データのNW転送(ダウンロード): 158円
        • ※書き込み系操作と早期削除(どちらも試行錯誤を含む)が大半で、通常(アイドル)時はデータ格納以外は掛からない。
      • ※データ量の単位にはGiB, TiB(1024系)とGB, TB(SI系)の2系統があるが、いろいろな箇所・場合・プログラムで異なっていて換算や記載が煩雑なので、ここでは特に区別せず、大まかに"GB"などと書き、特に必要な場合だけ厳密に扱う。
    • 今後の予測・見積もり (USD 1= 112円とした)
      • GCSのアイドル時の予測額(月額): USD 約1.1 (約121円)
        • 格納データ量: 約900GB
      • B2: GCSへのデータの一部移行後の予測額(月額): USD 約0.24 (約27円)
        • 移行後のB2の格納データ量: 約48GB
          • 約412GBをGCSに移行すると見積った。
        • 従来
          • 月額: USD 約2.2 (約246円)
          • 格納データ量: 約460GB
      • 合計の予測額(月額): USD 約1.3 (約150円)
        • 現状の約246円(B2のみ)との差: 約-96円
  • duplicacyの処理・設定: 結構手間が掛かったが、いろいろ分かったことがある。
    • チャンクサイズ
      • 大きくしてみたが、重複排除効率が下がるとのことなので、大きく(平均10MB)しないほうが良かったかも知れない。
        • 効率は大差ないとは思うし、料金も大差なさそうだ。
          • データ取り出しとNW送信が高いので。
        • バックアップしてからのサイズ変更はできない。
      • → その後、上記のチャンク消失問題の原因かも知れないと思って、デフォルト(平均4MB)に戻した(実際には無関係だった)。
      • 平均チャンクサイズと実際のファイルサイズの関係
        • 全データ量: 994,100MB, ファイル数: 332176, チャンク数: 202070
          • 平均ファイルサイズ: 3.0MB
          • 平均チャンクサイズ: 4.9MB
        • → チャンク化によって、ストレージの使用効率が約1.6倍になったと思われる。ただ、ブロック数でなく実サイズで課金されるので、料金には関係しない。
      • 重複排除の効果(実際のデータ量とストレージに保存されたデータ量の関係)
        • バックアップしたデータ量: 993,910MiB, ストレージに保存されたデータ量(チャンクの総データ量): 917,429MiB
          • 差: 約75GiB, 重複排除率: 約7.7%
        • バックアップの経過(duplicacyの出力)を眺めていたら、重複排除が効いている場合もあった(例: アップロードサイズが約1割減)が、全体としては余り効いていないようだ。
      • ※ここでのデータ量はduplicacyの出す値(表示は"MB"だがMiB系のようだ)で、単位系または処理が異なるせいか、他とは一致しない。
    • フィルタ(バックアップ・除外パターン)の設定
      • 強力だが、理解不能な癖みたいなものがあって設定が面倒。
        • 予行(dry-run)機能で試せるので、何度も試しては修正した。
      • ただ、もう少し機能があるといい。
        • 例: 更新日時でバックアップ対象にするかどうか。
    • prune処理について
      • pruneを行って不要になったチャンクを削除すると使用データ量が減って料金が下がるが、GCSの使用データ量の料金は安い反面、早期削除やアクセスの料金が高い(数十倍!)ので割に合わない。使用データ量がそれほど大きくないなら、なるべくpruneしないほうが得策だと思う。
    • 日頃のバックアップの必要性のチェック方法
      • duplicacyのバックアップの予行(dry-run)機能でバックアップ(アップロード)されるファイルが表示されてファイル更新の有無が分かるので、それを定期的(1日に1回)に自動実行し、結果を見て必要だと思ったら手でバックアップすることにした。
        • このチェックにもアクセス料金が掛かるが、今まで見たところでは それほど高くないので、頻繁過ぎなければ大丈夫そうだ。
      • ちなみに、B2へのバックアップは、基本的に上と同様に(dry-runでない)バックアップを定期的(約8時間間隔)に自動実行している。
        • ただ、PCのスリープや再起動に影響されずにバックアップの間隔をなるべく一定にしたいのと、バックアップ後にチェックをするのと、バックアップ以外にprune(2種類)を別な長い間隔(約1日, 約2週間)で行うのと、バックアップが長引いた場合に同時にpruneを実行しない(その逆も)ようにしているので、実際にはちょっと複雑な自作のスクリプトを使っている。
  • その他
    • 光回線でないと(無線では)、こういうバックアップはできなかった(ちょっと する気になれない)。
      • 初期(試行も)バックアップ中のデータ量の変化(グラフの下向きがアップロード)は、以下のように、今までにない すごい傾きだ。普通の4G無線で、一週間くらい こういう通信を安定してできるだろうか?
      • GCSに初期バックアップ中の送受信データ量: 上: 受信, 下: 送信; 左上から右下へ: 日, 週, 月, 年

    • ただ、家はVDSLのためアップロード速度が遅い(最大約35Mbps)のが残念だ。
      • もしアップロードも速かったら、初期バックアップは2-3日で終わっただろう(ただ、僕の準備・処理が間に合わなかったかも)。
    • GCS(Archive)は、アクセス・書き換え・削除などせず、ただファイルを追加していくだけなら安いうえに、他のクラウド アーカイブ ストレージと違って「普通に」使える(ただし高い)から結構いいと思う。
      • 以前書いたように、WORMメディアやテープのイメージで、基本的に書き込んだら放置だけど、ちょっとお金を「はずめば」普通に使えるのがいい。面倒な解凍処理が必要で半日も待たされる他のクラウド アーカイブ ストレージにはない大きなメリットだ。
      • アクセスやNW転送(ダウンロード)の料金が下がれば言うことないが・・・
      • あと、webコンソールを もう少しまともにしてくれれば・・・
        • その他、細かいこといろいろw
      • それから、Googleらしく「止めた」とか値上げとかがないことを祈るw
    • GCS(Archive)の料金は試用クレジットの約3万円に比べて概ね安いので、最初の試行や初期バックアップには充分過ぎるくらいだ(まだ9割くらい残って居る)。やりたくないが、何回でも最初からやり直せるw

 

という訳で、目論見・見積もりが合っていれば、「保存データ量倍増、料金4割減」(→ コストパフォーマンスは3.3倍?)という うれしいことになるはずだが、果たしてどうなるか。(何もしなければ変わらないだろうが)1-2か月は頻繁に料金をチェックし、大丈夫そうならB2のデータをGCSに移行(実際には、移行するファイルをB2へのバックアップ対象から外す)したい。※

※頻繁に変更するデータをB2に残し、そうでないものをGCSに移す。

移行後はB2の月額が1ドル未満になる予定だが、それはちゃんと請求されるのか、変な心配はあるw

そして、もし移行してから失敗に気付いたとしても大丈夫だ。というのは、duplicacyは履歴を保存するので、設定した期間(僕の場合、約半年)は削除済みのデータが残って居るからだ(そのため、その間は料金は安くならない)。

いざという時に、その残って居る履歴を期限で消さないようにできるのか不明だが、まあできるだろう。少なくとも、pruneしなければ消えない。

残件としては、前回書いたように、「まっさら」な状態からのリストアの手順を検討・試行をすることと、作成または更新年が新しいのでGCSにバックアップしないようにしたファイルを、定期的に(毎年)バックアップ対象に追加する(= B2からの移行)※ことがある。

※きっと、こんな作業を自動的に行う階層的ストレージ管理ソフトはあるのだろうが、エンタープライズ用で「お高い」だろうし、使うのも面倒なんだろうと思うが、実際はどうなんだろう。実はフリーであったりするのか?

 

一時IPv6アドレスの更新の影響について

IPv6のIPアドレスは固有(一応、全世界で1個)のため、プライバシーを保護するために(IPv6 privacy extension)、有効期限付きの一時アドレスというものを短期間(Linuxでは通常は1日)で変えながら使う(そうでない設定も可能)。その期限("temp_prefered_lft" (sic))が切れると、一時アドレスが更新されて変わる。ただ、古いアドレスが即座に無効になると通信が切れて問題があるので、しばらく(Linuxでは通常は6日: 最終的な期限("temp_valid_lft")の7日-上記の1日)は使えるようになっているようだ。(ここは動作からの推測)

Linuxの一時IPv6アドレスの更新処理 (推測)

  1. システム起動時やNW IFの初期化時に、新しい一時アドレスが生成・割り当てられる。
    • そのアドレスは、preferred_lftが0になるまで新しい通信に使われる。
  2. preferred_lftが0になった(deprecated状態)は、valid_lftが0になるまで残る。
    • そのため、通信中にアドレス更新があっても、当面は問題は起こらない。
    • ただ、そのまま延々と通信を続けた場合、valid_lftが0になった時点でアドレスがなくなるので、問題が起こる。 → 通信できなくなる?

なお、preferred_lftやvalid_lftが減るのはLinuxが動いている間だけで、スリープなどで止まっている間は減らない。また、再起動でどうなるかは不明。

当初、僕は そこを理解していなかったため(一時アドレスの設定方法については情報があるが、動作や2つの期限の違いの詳細については見付からなかった)、期限が切れても無効になったアドレスが引き続き残って居るのを見て、ちゃんと動いていないと思い、temp_valid_lftとtemp_prefered_lftを同じ1日(86400秒)にしてしまった。そうすれば、実際に毎日の期限でアドレスがガラッと変わって気持ちが良かったのだが、上記のようにアドレス更新されるとそれまでのアドレスが無効になってしまっていた。

ただ、その瞬間に通信している場面が少なかったのか、あるいは、多くのプログラムが そういう通信エラーにちゃんと対処していたためか、何も問題が起こらなかったが、duplicacy+GCSだけは違っていた。たまたま見ていた時にアドレス更新が起こったら(あとでそうだったと推測した)、しばらく(30秒-1分?)アップロードが停まり(リトライしていた?)、その時にアップロードしていたと思われる(本当にそのものかの確認はできていない)チャンクが消失した。duplicacyはエラーを出していなかったので、通信できなくなる前にGCSから成功が返って来たのか、duplicacyの通信エラー検出・対策に不備がある可能性が考えられる。

この問題をduplicacyの作者に報告したほうがいいが、そもそも設定ミスに起因するのと、再現させるのに手間が掛かるし、GCSとの相性の可能性もある(B2に対しては起こったことがない)ので保留している。

これに対処するには、まずはLinuxの一時アドレスの設定を「ちゃんとする」ことで、デフォルト(temp_valid_lft= 7日, temp_prefered_lft= 1日)に戻したら問題は起こらなくなった。ただ、可能性として、以下の場合は問題が起こるのではないか(待つのに疲れたので、実際には確認していない)。

  1. 一時アドレスの更新(temp_prefered_lft)時刻の少し前にduplicacyでバックアップを開始し、
  2. temp_valid_lftの期限が過ぎてもバックアップが終わらない。

この対処(予防)のために、duplicacyでのバックアップ開始前に、一時アドレスの設定を変更して固定にし(例: use_tempaddrを1にする)、バックアップ終了後に設定を戻すことを考え、そのスクリプトを作るつもりだったのだが、その前に設定をちゃんとして試していたら(バックアップの残量が少なかったため)問題が再発することなく初期バックアップが全部終わってしまったので、スクリプトは作らず仕舞いである。

ただ、今後(忘れた頃に)問題が起こる可能性があるので、バックアップ開始前に一時アドレスの有効期限(temp_valid_lft)を調べて、途中で切れそうだったら(バックアップ量によるが、暫定で1.5日にしている)メッセージを出してエラーにするようにした。

 

こぼれ話 (Azure(日本MS)を大いにディスる)

以上の話とは全く関係ないが、Azure(日本MS)はトライアルの使用状況を聞くために電話(マジで!)を掛けてくるというアフォさ。その連絡メールは、「いつがいいか知らせろ。返事しない場合はテキトーに掛けるよ」(意訳)で、「は????」としか言いようがない。

こっちは、何もしてないのに規約違反のアクティビティを検知したとかでアカウントがロックされたままで使いようがないのに、そういうことを調べもせず ただ電話すればいいという、昭和的馬鹿営業の極み。掛かって来たらブロックするのが楽しみだ。

電話で、ロックの件やAzureが使いにくいとか言うのも可能だろうが、大抵その場の「なるほど」、「検討します」だけで何も変わらず(というのは、そういうのは向こうの期待する回答じゃないため)、こっちが対応する労力が無駄なことが分かっているのでしない。

→ と書いたら、書き終わる前に(上の「いつがいいか」のメールが来た数時間後(同じ日)に)掛けて来た。留守電の声は新人らしいが、本当に非常識なヴァカだった(上司の命令どおりのことをしているだけなのか)。待ってましたとばかりにブロックリストに入れた。ヒヒヒ。って、性格悪いな。

それにしても、そんなことまで入会時に承諾したつもりはないが、(ちゃんと読まなかった)規約に書いてあったのだろうか。ただ、メールに定例の「以後、不要な場合は−」のような文言すらなかったので、日本MSのクソ意識の低さを再確認した。

バカジャネーノ!

もちろん、一応試したけど未だにロックされていてサインインできず退会できないから、試用期間が終わるのを待つしかない。こんなのを ほんのわずか(1μgくらい)にでも使えるかと思って試した僕は、本当のクソだ。

→ (10/15 9:36) 良く考えたら、アカウントを放置したら、試用期間が終わったら残ったデータに課金される可能性があるから、退会した。それがすごく分かりにくく面倒だった。

最初はMicrosoftアカウントを削除するだけでいいと思ったのでそうしたが、アカウントが削除されるまでに待機期間(30または60日)があり、その前に試用期間が終わったら課金されてしまうので、一旦アカウントを復活させてストレージのデータを削除した。更に、MSのページによれば、Azureのサブスクリプションを解除する必要もあるとのことなのでそうした。カード情報の削除は アナログな方法でしか削除できず面倒なので、放置した。さすがに退会すれば使われないだろう。

もう二度と入りたくない!

 

PS. それにしても、データ量1TB、使用料月額約1ドルなんてゴミ誤差みたいなもので、他の大規模ユーザの隙間に生きるような感じだw そういうユーザが居るからこそ、僕のような趣味の者でも安価だけど高い信頼性で使えるのだ。そういう点では、GCSは(小さいほうの)スケーラビリティ(スモーラビリティ??)も高いと言えるのではないか。あるいは、銀行や政府のお金の計算のように、1円(あるいは銭)から兆以上までちゃんと扱えるってことだろう。

「兆」と書くとすごく大きく感じるが、実は1012で、データ量などではTで、実はそれほどでもない。PやEなどを扱うITの世界は、お金の計算を超越しているのだろうか?

そういえば、僕のスマフォの契約も500MB/月と似たような領域だ(爆) こういう技術(かどうか分からないが)も きっと何かに役立つはずだ。

こういう細かいのは米粒に文字を書くとか豆本とかの日本のお家芸みたいで好きじゃないが、それ自体を目的とする訳でなく、遊びとか興味を嵩じさせてやるのなら いいのではないかな?

あと、この場合、豆本に相当するのは、大きなデータをいかに圧縮するかみたいなことだと思う。そういうのは使いにくいし、情報量を落とす(非可逆圧縮)場合もあって本末転倒なので全く興味がない。この類の いい(悪い)例はi-modeだ。

 

(11/15 14:50 重複排除の効果の項を修正, 10/17 18:51 わずかに加筆)

  •  1
  •  0

非常時に備えて、滅多に使わないデータをクラウドのストレージにバックアップ(アーカイブ)する作業をしていて※、アップロードの待ち時間(平気で12時間とか掛かる)に、そのデータが必要になった時にリストアすることを考えたら、前提条件によっては なかなか難しいことに気付いた。

※今までに、約250GBの音楽データをアップロードした。

そのクラウドのバックアップが必要になる最悪の場合は、部屋にあるPCとバックアップHDDが全部駄目になった場合だ。例えば、震災や火災だろう。

なお、いずれの場合でもクラウドサーバは安全(壊れない)と想定する。そこが駄目な時は世界戦争とか地球が終わりなので まあいいかって気がする。

そのあとで(気を取り直して)PCのハードを手に入れてセットアップし、回線を繋げてデータをクラウドから戻そうとする時、クラウドの認証情報(パスワードの類)が必要になる。その時、僕はパスワードは全部ランダムに作り(当然、記憶できないのでパスワードマネージャに入れている)、更に、可能な場合は2要素認証にしている(ほとんどの場合、2要素目はTOTP(最初にQRコードを読ませるもの)である)ので、「パスワードを思い出して接続する」なんてことは全く不可能だ。

では、どうすればいい(しなくてはいけない)かというと、まずは以下だ。

  • パスワードマネージャのデータ(DB)を手に入れる。
    • これのマスターパスワードは覚えている。
  • TOTPのデータ(DB)を手に入れる。
    • これのマスターパスワードも覚えている。

今までは、それらはスマフォやUSBメモリに入れているから何とかなると思って居たが、最悪の場合(身体一つだけになった場合)は それらもなくなるから駄目だ。

上のデータを自分のファイルサーバに入れておくにしたって、サーバの認証も2要素認証だし、サーバにSSHで入って何とかするにしたって、鍵のファイルがないとログインできないようにしているから身体一つだけでは無理だ。

となると、なかなかいい方法が浮かばない。今思い付くのは、せいぜい以下のようなものだ。

  • 自分のファイルサーバに非常用の場所を作り、その認証はパスワードだけにする。
    • そこに上記データを保存しておく。
    • データは暗号化されているとはいえ、脆弱である。
    • 書いたあとで気付いたが、これのパスワードもランダムにしたら覚えられないという問題があるし、覚えやすくするにしても、既に上の2個(+α)があるから無理な気が・・・
  • 自分のファイルサーバでTOTPでない2要素認証をサポートする。
    • 例: 生体認証(指紋)
  • サーバのプロバイダに頼んで、仮想コンソールに入れるようにしてもらい(≒ パスワードの再発行)、そこで何とかして上記データを手に入れる。
    • あらかじめ、サーバに上記データを保存しておく。
  • 2要素認証のバックアップキーを紙に印刷して、肌身離さず持ち歩く。
    • これが可能ならスマフォやUSBメモリだってできるので、余り意味がない。

完璧ではないが手軽で現実的な方法としては、非常用持ち出し袋に予備のUSBメモリまたは(認証可能な)スマフォを入れておくとかだろう。ただ、これは情報の更新や常に充電しておくといった保守が欠かせないから、やっぱり弱い。

→ とりあえず、SDカードに上記データを保存し、財布のカード入れに挿し込んで持ち歩くことにした。さすがに避難する時に財布は持つだろうし、外出中に災害に遭った時も財布は持っているだろう。このSDは、定期的に上記データをバックアップしているUSBメモリと一緒にバックアップすることにする。これで少しは安心だ。

普通の(大きい)SDとmicro SDで迷ったが、microは薄く・小さくて いつの間にか財布から滑り落ちてなくなりそうなので、大きいSDにした。

→ その後、やっぱり小さくて薄いほうがいい気がしたので、クレジットカードサイズの、micro SDを嵌め込んで収納するケースを作った。国保の保険証のビニルケース(ちょっと大きくて使わないうえに、毎年もらえるので余っている)と厚紙を使った。ケース表面の片側が開くようにして、micro SDを出し入れできるようにした。

これなら、micro SDが窪みに収まっているうえに財布に入れている時は表裏両面から押されているので、滑り落ちることはないだろう。また、左右方向に曲げの力が掛かる可能性を考慮し、micro SDの たわみが小さくなることを期待して縦に置いた。 (10/7 9:04)

折角なので、これの前に作ったプロトタイプ(あるいは習作)の写真も載せる。クレジットカード型USBメモリ(→ : このデザイン、OKなの??)にインスパイアされて(実際には、ちょっと欲しかったけど、意外に高かったので)作った。

micro SDが脚(または腕)でケースに繋がったままアダプタに挿せ、脚を折ってmicro SDをケースの窪みに収納できるようにした。想定どおりに使えたが、どうも綺麗でないし、いろいろな部分が弱い感じだし、表面はmicro SDが剥き出しで嫌なので、上の正式版に作り直した。 (10/7 14:59)

まあ、身体だけになるのは まずないことだけど、最悪でそうなった時のための準備をしているので、イザという時に準備したものが使えないのであれば、単なる自己満足になってしまうし、その時に「あーーーー」(いろいろやったけど、無駄だったじゃないか・・・)と呻いて立ち直れないことになる。

とりあえずはプロバイダに頼むのが一番可能性が高そうだ。(日本の会社なので、)手間や時間は掛かるが何とかなるだろう。その時に本人確認の情報が要るだろうが、それは他にも必要なので、アナログな方法で何とかするのだろう。よくある、名前、住所、生年月日とかでいいかも知れないし、運転免許証(これも再発行してもらう)の写しが要るかも知れない。

他には、携帯電話回線(番号)に紐付いたストレージをキャリアやプロバイダが提供してくれれば、上記データを保存するのに使えそうだが、そのスマフォ(SIM)がなくなったら難しそうだ。ただ、上と同様にアナログな認証で再発行してもらえばいいのか。

基本的には、キャリアがこういう余計なサービスをするのには反対だが、非常用なら意味があると思う。容量なんて10MBくらいあれば充分だ。

書いたあとで思い出した。Googleなどは携帯電話(SMS)でアカウントを復活できるはずだから、まずスマフォを復活させれば※、ストレージ(例: Googleドライブ)にアクセスできるようになるはずだ。そこから あらかじめ保存しておいた上記データを取得すればいい。ただ、Googleのパスワードもランダムなので、覚えられない。これもリセットできるのだろうか? あと、アカウント名もランダムにしているものがあるので、おいそれとは復活手順にすら進めない。できそうな感じではあるが、なかなか難度が高そうだw

※これにしたって、Androidを最初に使う時にGoogleアカウントを入れる必要があり、そこで つまづきそうだ。 → まずはPCからGoogleのアカウントを復活させ、それでAndroidを初期設定することになるのか。いや、それだとSMSが受け取れない。鶏と卵の問題かな・・・ 電話での復活もできたっけ?

アナログな認証をクラウドにも使えればいいが、Googleなどは融通が効かなそうだし、海外の会社に事情を分かってもらうのは大変そうだし、名前や生年月日とかで信用されたら、いくらでも乗っ取りができてしまう。電話代も高いw

あとは、例えば眼鏡にメモリが内蔵できれば、単体のUSBメモリよりは可能性が高い。それから、身体にNFC対応のメモリを埋め込むとかバックアップキーをタトゥーで彫るのは確実そうだが、ちょっと遠慮したいw

代わりに、バックアップキーを印刷した布をすべての衣類(下着も含む)に縫い付けるほうが、痛くないし更新可能だから まだ良さそうだ。さすがに素っ裸で避難するってことは ないだろうw

 

書いたあとで思い付いたのは、データを文章にして(あるいは、文章に埋め込んで)、マスターキー(これは覚えている)でデータを抽出できる方法(昔のゲームの「呪文」みたいなもの?)だ。他人が読んでもなんでもない(けど、例によって随分長い?w)ブログのエントリ(あるいはサイト全体)だけど、僕だけは分かっていて使えるってのは おもしろそうだな(画像はステガノグラフィが有名だが、テキストでもきっと既にあるだろう。あと、MQAみたいに音のファイルに入れるのもできそうだ)。ただ、AIに見破られる可能性もありそうだw

 

考えれば、他にもいい案が ありそうだ。すぐにできる必要はないが、何か用意する必要はある。「必要」とは書いたが、(今はその事態になっていないので、)「いろいろ考えて楽しんでいる」と言うほうが正しい。ただ、「あーーーー」と呻きたくはないな。

まあ、これらが必要にならずに終わるのが一番だ。

  •  0
  •  0

先日から試している、長期間変更しないデータのGoogle Cloud Storage(以下、GCS)でのアーカイブ保存(バックアップ)。やってみないと分からないことは多いもので、予想していなかったことが いろいろあった。

バックアップ方法 (使用プログラム・設定)

当初はrcloneで始めたのだが、使っているうちに少し不満な点が出た。Sym-linkに対応していないことである。当初は それほど使っていないと思って、(例えばバックアップ時にsym-link一覧も保存し、)リストアする時にでも対処すればいいと思って居たのだが、実は結構使っていた。音楽についてはそうでもないが、写真(当初は予定していなかったが、古いものは対象にしたくなった)では多用していることに気付いた。

書いたあとで思い付いたが、バックアップ時に(一覧でなく)sym-linkだけを格納したtarを一緒に保存すればいいかも知れない。これなら、面倒な作業やスクリプトなどが要らず、コマンド一発で復元できる。ちょっと考えよう。 (17:39)

スクリプトを作れば いくらでも復活できるが、(それにしたって動作確認やデバッグは必要なので、)なるべく手間のないほうがいいと思うので、duplicacy(ファイルをチャンク(数MB程度のブロック)に分割して保存しているので、sym-linkも保存できる)を再検討した。

すると、duplicacyでは、sym-link対応の他にも、ファイルの移動や名前変更の時に再転送が不要になる場合があることが分かり※、なかなかいい感じになった。

※詳細な動作や条件は把握していないが、ファイルをブロックに分割して保存しており、同じブロックが書き込み済みなら再度書き込まない(重複排除, deduplication)ため。実際にバックアップ済みディレクトリを移動してから再度バックアップしたら、アップロードなしで済んだ。

なお、duplicacyで定期的に実行するprune(ファイルの更新・削除のために不要になったブロックを削除する)処理のコストは不明だが、ストレージ自体のコストは安いし、そもそも変更しない前提のファイルをバックアップしているので、pruneしなくてもいいかも知れない。

この辺りは昔のWORM光ディスクでの保存に似ている感じだ。

そして、昨日からduplicacyに切り替えて試していたら、新たに気になることが出た。上に書いたように、ファイルをブロックに分割するので、ブロックが小さいと書き込み・読み出し回数が増えたりストレージ内のファイル(オブジェクト)数が増えて、効率が悪くなったり料金が増えたりするのではないかということだ。試算してみると、当然ながら、ブロックが大きいほうが書き込みのコストは小さかった。

そこで、今朝、デフォルトのチャンクサイズが平均4MB(1..16MB)なのを、8MB(2..64MB)に変更して試して居る。

ただ、バックアップやリストア、それに伴うNW転送に関してはファイル数でなくデータ量に課金されるので、チャンクサイズはトータルのコストには余り効かないようだ。それでも、チャンクの管理(実際にあるかは不明: チャンク一覧やpruneの時か)のための操作数は減るので、その分のコストは下がるはずだ。あと、バックアップ速度は少し速くなった気がする。

運用コスト (料金・費用・手間)

料金をチェックしたら意外に高かった。昨日は72円で、4日目の今朝は85円になっていた。※

※絶対値としては とても安いが、まだデータ量が少ないのに予定している月額(< USD 1)を容易に超えそうな勢いなので、不安になった。

いろいろ試したせいもあるが、それでも なんか高いので調べてみたのだが、GCSは料金の内訳が出ないので、どの処理・操作が主因なか分からなかった。それで、1GBくらいをアップロード(バックアップ)した時の処理数や転送量と料金表で試算してみたが、上の料金には合わなかった。

気になったので、試しにリストア時の費用も試算した。想定している上限の約1TBをリストアする場合を計算したら、思わぬことが分かった。※ NW転送(外向き、"egress")とデータ取り出しのコストがかなり高いのだ。上に書いた、書き込み(リストアでは読み出し)操作よりずっと高い。

※上記のように自分で試算した額と請求額が合わないので、下の試算も合わない可能性があるが、データ取得と転送については合わない理由がないと思う。

以下に約1TBをリストアする場合の料金の試算結果を示す。 (USD → JPYは今は約111円のようだが、とりあえず120円とした。)

  • データ要求操作(get= Class B(USD 0.50/10000 reqs)とする)
    • duplicacyのチャンクサイズが平均10MBの場合
      - 1024 * 1024 (MB) / 10 (MB) = 104858 チャンク → 104858 /10000 * 0.50= USD 5.2
  • データ取得(アーカイブからの取り出し) (USD 0.05/GB): チャンクサイズには関係ない)
    • 1024 (GB) * 0.05= USD 51.2
  • データ転送 (Egress to Asia: USD 0.12/GB): チャンクサイズには関係ない)
    • 1024 (GB) * 0.12= USD 123
  • 合計: USD 179 → 約2.1万円

合計額もそうだが、データ転送コストの高さに驚いた(ボッタクリ??)。他社(Azure, S3)はこの数分の一(Azureは書いてなかったので無料なのかも知れないが、不明)なので、Googleは ここらでコストを回収しているのだろうか?

データ転送料金はArchiveだけでなく全クラスに共通なので、普通に使っている人は かなり高くついていそうだ。だから、実はGCSのユーザーは少ないのだろうか? そして、Googleの多くの過去のサービスのように消滅してしまう?? あるいは、電気代のように逆従量制(?)なので、大規模ユーザーが多いのか?

なお、ブロック分割しないrcloneでも同様に試算したが、データ要求操作のコストは安いものの他より1桁小さいので、合計はUSD 3程度しか安くならなかった。

それで、またAzureやS3に目が移りかけたのだが、当然ながら いいことばかりではない。次が主要な判断事項となった。

どちらがいいか?

  • リストアすることは まずないので、リストア関連料金は高くてもいい? (平常時(保存だけ)の運用コストがBackblaze B2より安ければいい?)
    • 候補: GCS
      • 即座にリストアできる。
      • duplicacyが使える。
  • リストアに手間や時間(解凍時間)が掛かってもいいから、特にリストア時の料金が安いほうがいい?
    • 候補: S3かAzure
      • リストアできるようになるまで(「解凍」)、10時間以上掛かる。
      • duplicacyは使えない。(バックアップ時にストレージに保存されたconfigが取得できないし、(あるかは不明だが)チャンクが読めないので) → configだけクラスを変えればいいかも知れない。
      • rcloneでもファイルの属性が読めるか不明。: 実体でないから おそらくできる。
    • AzureはデフォルトのクラスをArchiveにできないので(CoolかHot)、バックアップ後に変更しなくてはならず、使いにくい。S3は不明。
    • S3やAzureでリストア時に解凍すると、クラスが上がって保存料金が高くなる(約10倍)可能性がある。
      • 短期間なら問題ないが、リストア後にクラスを戻す手間が増える。

滅多に使わないのだから、まず起こらない場合の手間を惜しまずに運用費を安くすべきなのか、そうは言ってもたまに間違いを起こして(僕は これが結構あるw)使う可能性はあるから、手軽に・間違いなく使えるほうがいいのか。  (当然ながら、今の考えは後者である。) − 悩ましいところだが、GCSの試用期間・額はたっぷりあるので、試行錯誤しながら考えたい。

余談だが、GCSの試用額(この額・枠のことを"credit"というのだろうか?)約3万円が無期限で使えれば、僕が使う予定の十年分以上になるから即座に決めるが、そんな うまい話はないwww

書いたあとで、掲示板のまとめのマイナンバーカードに関するスレッドを読んで、上の2つの選択肢はマイナンバーカードと運転免許証の関係に似ていると思った。マイナンバーカードは無料だけど、随分手間が掛かる(そもそも、さほど便利でない)。一方で運転免許証は、取る時も維持にも多少お金が掛かるけど、面倒さは少なく、手軽に幅広く便利に使える。

「どっちがいい?」と聞かれれば(聞く人すら居ないだろうが)、間違いなく後者に決まっている。

細かいこと

GCSを使っていて、(やっぱり)気になること・不満なことが出て来た。

  • 料金の詳細(内訳)が分からないのが不便。Web(コンソール)では見られない。 → コンソールのBillingのReportsの右側のフィルタを設定すると項目ごとの料金を表示できる。が、円なので使用量は分からない。逆算するにしても、正確には分からない。 (10/5 7:41)
    • B2では分かる。予測額も出る。
    • 月の料金請求時(確定時)まで分からない?
    • 料金(当日までの合計額)が出るのが遅い。: 10時頃更新?: 毎日の0:00 UTCから集計するとしたら、仕方ないか。
  • データ量などが更新されるのが1日1回なのも不便。
    • リアルタイムに出ず、更新は料金より遅い(午後3時頃?)。 (→ : 最下部の"Total bytes"と"Total ojects"が実際より小さい。: 前者は、少なくとも、右下の"Rec bytes"(≒ 書き込んだデータ量)程度はあるはずだし、実際に求めても そのとおり。)
    • B2では月1回なので、仕方ない?
  • Web(コンソール)の監視系、料金系が 今ひとつうまく動かなかったり、使いにくい場合がある(要するに、出来が悪い・詰めが甘い)。
    • Googleらしい? ここら辺はAzureのほうが良さそうな気がする。
    • B2はずっと良い(というか当たり前に使える)ので、すごい落差を感じる。

 

GCSのwebのモニタ画面 (苦労して見やすくした。)

 

希望・期待・・・

まあ、個人的に一番好ましいのは、Backblaze B2がアーカイブクラスのサービスを出してくれることだが、難しいのではないか。まず、今時テープとかありえないし(彼らも慣れてないし)クソ使いにくいので、HDDやSSDを使うとしたら、どうやって料金を下げるのだろうか。それが無理なので、今のように単一サービスで通しているのだろう。

が、何か引き換え(アーカイブは滅多にアクセス・変更しないことからの何か)があれば、実現できそうな気がする。とりあえずは、GoogleのようにNW転送料金を高くする??

通常時はストレージの電源を切っておいて、アクセス時だけonにすることも考えられる(それなら何時間も掛からない)が、信頼性が下がる可能性があるので(HDDは何年間も動かさないと固まってしまう)、余りメリットがなさそうだ。「それでもいい」という代わりに安くするのはありかも知れないが、本当に駄目になっていたらバックアップの意味がないし(それを避けるために、冗長化するとか たまに動かす?)、制御が面倒で(停めて浮いた電気代より)高く付く気もする。

 

なお、現実的な解はGCSかAzureだろう。MSは大10嫌いだが、GCS(RCP)のwebコンソールや料金(アカウンティング)関係のいい加減さには ものすごく呆れたし、みすみすぼったくられるのも嫌なので、コスト次第ではAzureも充分ある。あと、AWSはもっと試用できるようにして欲しい。まあ、そもそも彼らは僕みたいな「最大1TB」とか「月1ドル未満」なんていう超小物じゃなく、PBオーダーの人たちを相手にしているのだろうから、仕方ないとは思う。 (18:49)

ちょっと試そうとAzureにサインインしようとしたら、何も規約違反をしていないのに、なぜかアカウントがロックされていたので、Azureの検討はしない。やっぱりMSは最低だ。わずかにでも期待したのが馬鹿だった。 (19:21)

 

結局、

上記のように、Azureは「やる気あるの?」レベル(調べたら、何もしてないのにアカウントがロックされるのは良く起こるようで、Officeなどが使えなくなって困る人が多いようだ)だしS3は「一見さんお断り」なので、(他に選択肢がなくて)GCSを使うことにした。その関係で、バックアッププログラムをrcloneにする理由がほとんどなくなったので、duplicacyを使うことにした。今日から少しずつ音楽などのファイルをバックアップして、様子(特に料金)をみていく。 (10/5 10:58)

 

おまけ: duplicacyでちょっと引っ掛かったこと。

GCSのアクセストークンのファイル(例: gcs-token.json)を、ストレージの初期化時(duplicacy init実行時)に指定した場所から移動したら、エラーでアクセスできなくなってしまった。

ヘルプやドキュメントには変更の仕方が載っていなくて、また初期化が必要かと がっかりしたが、設定ファイルやPC内にはそれが格納されている気配がなく、当然、クラウド側には保存されていない(トークンがないとアクセスできない)から、どうにかしているはずだと思ってソースを見たら、分かった。

  • 初期化時に設定したパスは、LinuxではGnome keyringに格納されている。 (使っているとは思いもよらなかった。見付からないのも当然である。)
    • seahorseコマンドで変更可能。: Default keyringの"gcs_token - duplicacy"
  • また、設定ファイル(.duplicacy/profile)中の"keys"ブロックに"gcs_token"のキーでパスを書けば変更できる(duplicacy set -key X -value Yでも設定できるはずだが、試していない)。
"keys": {
  "gcs_token": "/home/user/GCS/gcs-token.json"
}
  • また、環境変数DUPLICACY_GCS_TOKEN, DUPLICACY_PASSWORDでも指定できるはず(試しては居ない)。
  •  0
  •  0

以前から、手持ちの音楽のファイル全部を(ローカルなHDD以外に)クラウドストレージにもバックアップしたいと思って居たが※、データ量が大きくて(800GB近い)料金がかさむので、貴重なものだけ(約130GB)に絞っていた。

※実は、そもそも その必要性には疑問がある。CDなどを買えば再び手に入るものをバックアップすることに意味があるかだ。ただ、仮に全部消失した場合、再び買って揃えるにはお金も手間も掛かるし、CDだったらPCに復旧(リッピング)させるには相当な手間が要り、その気力は起こらないだろうから、それが不要になる点では意味がある。

ただ、全部消失するような事態になったら、バックアップがあったとしても復旧させる気が起こるかは疑問だ。だから、ストレージの料金をなるべく安くし、無駄だったとしても「保険」として割り切れるようにしたい。

あるいは、「いかにも」だが、仮にバックアップする意味は全くなかったとしても、こういう技術の知識・経験が得られる価値はある。

それから、音楽以外にビデオのファイルもバックアップできればいいが、さすがにデータ量が桁違いに大きい(約3TB)から料金がかさむだろうし、随分前から そういうビデオを観る(観た)ことがないので、「消失したら諦める」で良いと考えている。

その後、変更やダウンロードが高く付くなど使い方に制限はあるものの料金の安い、archive(またはnear line) storageというカテゴリ(貯金で言えば、利率は高いものの、ATM手数料が高く、最短解約期間制限のある定期のようなもの。国債のほうが近いかも)があることを知り、それを試してみようと思って居た。面倒だったのと別件がいろいろあったので延期していたが、昨日から試し始めた。

まず、料金の安い いくつかのサービスの料金を比較した。

  • Microsoft Azure Blob Storage (以下、Azure(クラスはArchive)。他も同)
    • Archiveの料金: USD 0.00099/GB/月〜 (サーバの場所によって異なる。Googleも同じ)
      • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月 (アクセス関連の料金は含まない。以下同)
    • データ取得時間: 最大15時間
  • Google Cloud Storage (以下、GCS)
    • Archiveの料金: USD 0.0012/GB/月〜
      • 例: 500GBの場合、USD 0.60/月, 800GBの場合、約USD 0.96/月
    • データ取得時間: 1秒未満 ("sub-second")
  • Amazon S3 (以下、S3)
    • Glacier Deep Archiveの料金: USD 0.00099/GB/月〜
      • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月
    • データ取得時間: 12時間以内
  • [比較] Backblaze B2 Cloud Storage (archiveではない。以下、B2)
    • 料金: USD 0.005/GB/月
      • 例: 500GBの場合、USD 2.5/月, 800GBの場合、USD 4.0/月

※データ取得時間は下の「補足・訂正」の記載時に追加した。

それらのうち、バックアップに使う予定のソフト(rclone)が対応していて最安と思われる、AzureとGCSを試すことにした。

なお、S3の料金は、以前調べた時(高い地域を見たようだ)はUSD 0.002/GB/月だったので却下したのだが、今調べると(例えばオレゴンは)Azure並みなので、追って再検討したい。

同じく、以前は気付かなかったS3のIntelligent-Tiering(アクセス頻度で自動でストレージのクラス(→ コスト)を変える)が なかなか良さそうで、理想的に働けば(そうは問屋が許さなそうだが)、B2から全部移行しても料金を節約できるかも知れない。

一方、すぐに分かったS3の欠点は、AzureやGCSのような無料試用額・期間(例: GCSは約3万円, 90日)がないことだ。これは結構大きく、料金システムが複雑で簡単には見積もれないことと相まって、気軽には試せない。やっぱりAmazonはセコいのかね。

→ 下の「補足・訂正」に書いたように、S3はAzure同様データ取得時間が長いのと、他と異なって無料で気軽に試用できないため、見送ることにした。 (17:53)

上記のように、現在使っているB2に比べて料金が1/5前後と かなり安いから、うまく使えれば行けそうだ。また、Azure(S3も)はGCSより2割近く安く、(さまざまな疑念はあるがw)もし良ければ使うのも悪くはない。それに、Googleだって好きじゃないw

結論を先に書くと、Azureは全く論外だった。一番のポイントはストレージ内でファイル・ディレクトリの移動ができないことだ。(補足・訂正あり。下記参照) 例えば、ストレージに保存(バックアップ)する時に場所を間違えてしまったら直せないのだ。それから、保存後に気が変わっても移動できない。もちろん、コピーするか再度保存(アップロード)すればいいが、時間もお金も掛かる。

SMBならできるという情報もあったが、インターネットで使うものなのか?? TCP版があるのだろうか?

馬鹿馬鹿しい・面倒以前に、こういうファイルシステムの基本機能がなかったら使いものにならない。「安けりゃ いいってもんじゃない」の典型ではなかろうか。良く使う人が居るものだ。Azureに決める人(お偉いさんや客?)は そういうこと分からず、現場が苦しんでいるのかも知れない。もちろん、ストレージ以外に すごくいいことがあるのかも知れないが、どうだろうね・・・

一方、GCSはもちろんファイル・ディレクトリの移動ができる。当たり前のことだ。書くまでもないけど一応書いた。 (← 実は違っていた。下記参照)

ところが、書いたあとで別件(できればsym-linkもバックアップしたい)を思い出し、それに対応するためには別のバックアッププログラム duplicacyを使うことになり、それならファイルの移動は関係ないので、安いAzureが いいかも知れないので、まとまり次第、更新・追加する。 (11:29)

補足・訂正

その後、GCSもファイル・ディレクトリの移動はできないことが分かった。ディレクトリの移動はできず、ファイルの移動はサーバ内でのコピーと削除で実現されるので、Azureと同様だ。ただ、GCSは、Archiveでも高速にファイルにアクセス(取得)できるという大きなメリットがあることが分かった。Azureでは解凍(rehydrate)にものすごく時間が掛かる(30分どころではなく、「最大15時間」である)。S3は「12 時間以内」だ。まさに、待ってたら日が暮れる。

目的は保険的なバックアップなので、必ずしも高速に取得できる必要はないが、いつ使えるようになるのか分からないのでは不便だ。なので、GCSは少し高いけどその価値がありそうだ。

それにしても、GCSの高速性はどのように実現しているのだろうか。単に全部同じストレージ(HDD?)を使い、料金や最小保持期間でコストを回収しているのだろうか?

 

→ 結局、Azureは やっぱり使えないことが分かり、GCSが良さそうだという結論は変わらない。 (16:42)

また、rcloneとduplicacyの使い勝手や予想コストなどを比較し、sym-linkなどは当初は諦めてrcloneを使い、必要な時に対処することにした。 (17:48)

 

以下に、それぞれを試してのメモ・感想・気付いたことを示す。

Azure

  • 初期設定で いろいろ難しい単語・概念が出て来て複雑。
    • ストレージなのに仮想ネットとか言われてもねえ・・・
  • コンソール(web)が使いにくい・分かりにくい。
    • 日本語訳で更に悪くなっている。 → 少ししてから英語に切り替えて、ちょっとマシになった。
    • 機能が少な過ぎる。
      • ファイルの移動やコピーすらできない。
    • → StorageExplorer(Linux版)を試そうとするが、.NETのライブラリが要るようで、動かなかった。
      • 調べたら、それでもファイル・ディレクトリの移動はできないようだ。
    • ただし、Metrics(使用状況のグラフ表示)はGCSよりずっと使いやすい。
  • ファイルシステムの基本機能が不足している。
    • ファイル・ディレクトリの移動ができない。 ← 実装としてはGCSも同様だった。
    • ルートのファイル名に小文字しか使えない。 ← どうやら、これはGCSでの「バケット名」だったようで、GCSも同じだった。
  • 地域は、料金の安い westus2 (US西部)にした。
  • アップロード速度は悪くない。: 30Mbps以上出ていた。
  • ファイルの取得にものすごく時間が掛かる(仕様では最大15時間)。
  • 料金の更新は即時ではない。翌日? (当然か)
    • GCSも同じ。
  • 全般的に料金は安いが、Read操作が異常に高い(USD 5/10000ops)のが気になる。
    • これが いつどのくらい効くのか、今ひとつ分からない。

GCS

  • 初期設定は概ね分かりやすかった。
    • ただ、分からないので無設定(デフォルト)にした項目も結構あった。
  • コンソール(web)はAzureよりずっと使いやすい。
    • Azureよりずっと分かりやすく、使いやすかった。
      • ただし、他のGoocle Cloudのサービスで懲りているので、英語版で使った。
    • 機能は概ね充分だが、以下が不便だった。
      • (バケットなどの)ストレージのデータ使用量が分からないのは不便。。。
        • → rclone sizeで分かる。
      • プロジェクトの名前が変えられない? → 随分探してできた。
    • わずかに面倒なところがある。
      • 例: Monitoringのストレージの地域が最初は必ずデフォルトになり、設定してもリロードするとリセットされてしまう。
  • ファイルシステムの機能は普通・常識的で問題ない。
    • ディレクトリの移動はできない。
    • ファイルの移動は内部的にはコピーと削除になる。
  • 地域は、料金の安い us-west1 (オレゴン)にした。
    • 土地勘がないため、オレゴンは遅そうなイメージだったが、下記のように速度は問題なかった。
  • 全般的に料金は安いが、最小保存期間が365日と かなり長いのが気になる。
    • 大量のデータを短期間で消すと高く付きそうだ。
    • Azureは180日。
  • アップロード速度は悪くない。: 30Mbps以上出ていた。Azureより少し速かった。
  • ファイルの取得は高速。普通のストレージと同じ感覚で使える。
  • その他
    • 無料試用分(USD 300)を得るため、現在のGoogleのアカウントとは完全に別に作った。
      • 混同・誤用・クッキーなどのmixを避けるため、ブラウザも別にした。
      • アカウント登録時に電話番号が要る(SMSでの認証がある)ので困ったが、そろそろ解約かと思っていた楽天モバイルが使えた。
    • アクセスのための認証情報(パスワード)がなく、rcloneの設定でをどうするのか分からなかったが、最後にブラウザで認証・許可できることが分かった。
      • 先進的でちょっと感動したがw、rcloneのマニュアルに書いておいて欲しかった。
    • rcloneでのファイル・ディレクトリの移動に癖があるが、大きな問題はない。
      • サブコマンドmoveとmotvetoの違いなのだろう。

というわけで、無料試用分・期間(90日)一杯はGCSを試してみて、料金や使い勝手が問題なければ本格的に使うつもりだ。

 

PS. 予想もしていなかったのだが、「面倒で使えない奴」と烙印を押した楽天モバイルのSIMが、上記のようにGCSの認証に役に立った。今後も何かに使えそうなので、このまま残すのも悪くない気がしている。

PS2. 完全に個人的な意見なのだが、下に出ているページのアイコンを見るだけで、AzureとGCSは どちらも同じような色遣いなのに、いかにMicorsoftにセンス・美意識がないかを強く感じる。なんで四角、しかも正方形なんだろうかと思う。「1000%ない」と思う。

それだけじゃ見た目だけになるから追加すると、ページの説明にしたって、Azureは"Blob storage"(しかも、そのあとに「テキストデータ」と出て来る・・・)だが、GCSは"Object storage"と、明らかにGCSが正確で分かりやすい。

こういうところから、「MSはクソ過ぎて大っ嫌い、Googleは好きじゃない」という感想になるw

 

(19:27 修正・補足)

  •  1
  •  0

今日の昼近くから、突然、LinuxのJoplin(デスクトップ版)が同期エラーになった。エラーメッセージは"certificate has expired"(サーバの(SSL)証明書が期限切れ)だった。いやいやいや、証明書はちゃんと定期更新されているし、ブラウザもカレンダーもAndroid版Joplinも問題ないのだが・・・

それで、試しにJoplinの設定で証明書エラーを無視するようにしたら ちゃんと同期するので、それで(何かわからないが、悪いところが)直るまでしのごうかと思ったが、気分が悪いので調べてみた。すると、思わぬところに原因があった。

Joplinのフォーラムでは、例によって「Joplinは証明書は使っているだけだから知らねーよ他が悪い」みたいな回答があったが、更に調べると、Joplinを動かしているElectronの問題で、他にも困っている人が多そうだった。Electronはメモリを食う(しかも、まず解放しない)から大嫌いなので原因までは調べなかったが、大方、証明書の格納領域が小さい(僕が使っているサーバの証明書は、Let's Encryptのものなので3段階になっている)とかなのだろうと想像している。

ただ、なぜ今になって急に出たのかは謎だ。もしかしたら、昨日Joplinを更新したのが関係あるのか(だったら、Joplinにも何か原因があるはずだ)。

それで、暫定対処方法が分かり、どうにか、上記の証明書エラーを無視する設定を解除してもエラーが出なくなった。こういう分かりにくいところが駄目になると探すのが大変で、まったく疲れる・・・

参考までに、関連するページを僕が参照した順に載せる(()内は投稿時期(JST))。

対処のポイントは、上に書いたように、証明書が3段階になっているのが悪いから減らすことのようで、証明書を作成・更新する時に中間の(あるいは余分な)証明書を削ればいいようだ。※ 中間のものは必要だから入っているはずなのに、どうして削っても問題ないのか まで考えるつもりはないが、確かにちゃんと動いている。中間の(あるいは余分な)証明書を削っても、削ったものが最後(「最初」のほうが正しいかも)の証明書に含まれているようなので、それでいいのかも知れない。

※例えば、(僕は使っていないが、)certbotには以下のように指定する(webサーバにnginxを使っている場合)。太字部分の指定で中間の(あるいは余分な)証明書を削るようだ。

sudo certbot certonly --nginx -d <domain> --preferred-chain "ISRG Root X1"

他に、試してはいないが、webサーバの証明書ファイル(例: "fullchain.crt")の中の2番目のブロック("-----BEGIN CERTIFICATE-----"と"-----END CERTIFICATE-----"に挟まれた部分)を削ればいいのではないかと想像している。

 

(10/2 5:04 わずかに修正)

  •  1
  •  0