「Mikeforceサーバ」タグアーカイブ

自宅で自ら構築したMikeforce Serverについて

The Certificate Expiration Notice for the first time in 2 Years.

コメントを残す

先日、二年ぶりに The Let’s Encrypt Team からサーバ証明書の期限切れが近づいている旨のメールを受け取った。証明書の更新を確認して Web サーバのエラーを確認せよ、との事だが、基本的に毎月はじめに Team 提供のスクリプトで証明書は更新しているはず。

Webサーバのログを見てみると確かに更新が失敗していた。Rotated している過去ログを見ると、先月から失敗しているようだった。dry-run モードで実際に実行してみると、ログに記録されているものと同じ結果となった：

IMPORTANT NOTES:
– The following errors were reported by the server:
  Timeout during connect (likely firewall problem)

二年前に遭遇した際も同じログだったので、てっきり Firewall に余計なURLsが追加されて[a]Let’s Encrypt は HTTP のポートにアクセスしてくるので、ここにアクセスしてくるサーバを排除したとか。サーバのNGリストは自動更新しているので、稀に間違ったsource（IPアドレス）を追加してしまうケースあり 😅️。、Access Denied したのかもしれないと思った :/。と云うことで Firewall のログと日付を睨めっこして 、問題発生する前の URLs に戻してから、もう一度 dry-run モードで実行したが、結果は同じだった :|。

ふｍ。HTTP→HTTPSの Redirect も問題ない。問題発生する前から Let’s Encrypt からのアクセスは Redirect しないようにしている。

期限が迫る中、何か簡単には対応できなさそうに思えていた矢先に、こんな記事を発見した：

確かにスクリプト（certbot-auto）を dry-run モードで実行したら、次のようなログが記録されていた：

Your system is not supported by certbot-auto anymore.
certbot-auto and its Certbot installation will no longer receive updates.
You will not receive any bug fixes including those fixing server compatibility
or security problems.
Please visit https://certbot.eff.org/ to check for other alternatives.

どうやら使っているスクリプトは Debian 系プラットフォームではサポートされなくなって久しくなったようだ（もう4年も経過している:O）。

そして代わりに使える方法を教えてくれる https://certbot.eff.org/  にアクセスし、Web サーバの構成を入力して代替方法を得ることができた ;)。そこで提示された手順にしたがって実行していくと証明書の更新が成功した：

$ certbot –version
certbot 2.10.0

ひとまず次の期限切れまで監視はしていく予定だが、なぜに、このような大事なことが事前に連絡されないのだろうか :/。

参照

参照
↑a Let’s Encrypt は HTTP のポートにアクセスしてくるので、ここにアクセスしてくるサーバを排除したとか。サーバのNGリストは自動更新しているので、稀に間違ったsource（IPアドレス）を追加してしまうケースあり 😅️。

A Terrible Copyright Infringement.

2件の返信

先日、ブログを書くのに参考になりそうな資料なんかをインターネット上で探していた際に、城の復元模型を掲載しているホームページにたどり着いた。特に詳しい説明は無かったが、リンクのトップページには「模型で俯瞰する中世城郭」とあり、多分に参考になりそうな情報があるだろうと思い模型一覧のページを見てみた。

案の定、探していた城のページあったのでリンクを開いてみると、推定復元模型なる画像の他に、その城に関連する写真や資料のような画像、そして城の散策をテーマとした Youtube の動画[a]どうやら、ここの作者ではない、他の「城マニア」が作成したものだった 😕️。が掲載されていた。ホームページは手作り感一杯だ。ソースを観てみると HTML エディタで作成したかのうようなコードだった。

この模型の一覧には他にもたくさんの城（模型）のリンクがあり、その昔に自分が実際に攻めて訪問記を書いた城もあったのでリンクを開いて見たのだが、その内容を見て驚いた :0。

なんと俺が作成した城関係の図が掲載されていた。なんかどこかで見た絵だなぁと思って、小さくなっている絵を拡大してみると、やっぱり俺が作成し訪問記に掲載している図だと確信した。なんとなく嫌な予感がして、自分が訪問記を公開している城をかったぱしに開いてみると、予想どおり、かなりの画像がブログから盗用されていた[b]自分の訪問記への直リンクではなく、このレンタルサーバ上に保存されている模様 🤬️。 :|。以下にその詳細を記すが、本稿公開後しばらくして俺の画像などを削除して証拠隠滅を図っていた。従って、HTTP404（コンテンツが見つからない）など、俺が驚いた時点とはその状態が変わっているものがあることを追記しておく：

一部は方位磁針を追加したり、（おそらく）他人の画像と連結するなどの加工跡あって悪質。

そういう目でもう一度見ると、インターネット上で見たことがある、城好きならおなじみの縄張推定図など、他のサイトからも（著作権を明示していない）画像の盗用を見かけた:|。

ちなみに、うちのブログはインターネット公開時から Copyright を明示している：

COPYRIGHTS

このサイトにあるコンテンツは全てクリエイティブ・コモンズでライセンスされています。出典付きでリソースを公開する場合も著作権を行使します。直リンクを含む無断使用を目視またはログ等で確認した際は掲載料として一画像につき2万円（日本円）をアクセス数分請求させていただきます。

ブログ公開時、 CC（Creative Commons）ライセンスはやや緩めの CC BY-NC-SA 2.1 （表示・非営利・継承 2.1）だったが、途中、直リンクを使った「他人の画像を自らの画像に見せるパクリ」行為があったので（上のような「金銭的請求」を追加して）、現在は CC BY-ND 4.0（表示・改変禁止 4.0）に更新している。本当はこんなことはせず共有を許可したかったが、やはり Gateway の外は糞野郎だらけ。インターネット上は安心できないのだ。

いずれにせよ、ここで勘違いすべきではないのは、このライセンス下では、たとえ再利用する場合でも俺が所有する著作権を明示するという条件がある。無断もしくは後日連絡するにしても、この点は重要だ。

それにも関わらず、こいつが悪質なのはライセンスを無視した上に、俺の画像を含むホームページ全体を 

© by Yoji Tabuchi, All rights reserved

と勝手に自らの著作を主張している点である。

このホームページに記載されていた犯罪者の情報を以下のとおり晒しておく：

tabuchi_y@hotmail.com

この悪質な犯罪者はなんだか EXPO なんかに展示するような輩であるようだ。盗作されたブログの Copyright に従って、レンタルサーバ会社に対する法的な処置や、個人的な金銭請求できるかどうかは専門家と相談する予定[c]流石に法外な賠償金は無理だが🤐️。。それまではこんな感じで晒しておき、どこぞの商用ボットに拡散してもらうことにする。

あと、いい機会なんで、以前遭遇した Copyright を無視して俺所有のリソースを無断で使用（直リンク）していた野郎も公開しておく：

  • 某人気映画のロケ地巡りのブログから適当に画像を直リンクしていたサイト[d]直リンクを排除したことにサイト関連の輩が気づいたからから、金銭的請求がおそろしかったのか、俺のブログへのリンクは別のサイトのリンクに変えられていた 😑️。烏山駅は全く関係のない駅の写真だった。まさに阿呆。
  • これもブログ関連で、俺の写真を直リンクしていたサイト[e]このサイトも直リンクは排除した。あたかも自分の写真であるかのような挿絵である。こいつは未だ気づいていないのか、リンク遮断跡が残ったまま。まさに阿呆。

広告収入ない俺のサイトから無断でリソースをパクるなど、まさに他人が所有するリソースを無断使用して広告やアフィリエイトで収入を得ている商用サイトの運営者はもっと痛い目をみるべきだ :/。

俺はお前らに盗用されるためにブログを公開しているのではない。犯罪者どもが。

参照

参照
↑a どうやら、ここの作者ではない、他の「城マニア」が作成したものだった 😕️。
↑b 自分の訪問記への直リンクではなく、このレンタルサーバ上に保存されている模様 🤬️。
↑c 流石に法外な賠償金は無理だが🤐️。
↑d 直リンクを排除したことにサイト関連の輩が気づいたからから、金銭的請求がおそろしかったのか、俺のブログへのリンクは別のサイトのリンクに変えられていた 😑️。烏山駅は全く関係のない駅の写真だった。まさに阿呆。
↑e このサイトも直リンクは排除した。あたかも自分の写真であるかのような挿絵である。こいつは未だ気づいていないのか、リンク遮断跡が残ったまま。まさに阿呆。

Upgrade My Desktop Machine.

コメントを残す

毎年、年末の大掃除では Desktop PC はもちろんサーバも電源を落としてケースの中まで綺麗にする[a]例えばCPUファンの羽に付いている一年分のホコリを落とすなど。のが恒例なのだけど、昨年末はアクシデントが発生。どうやらサーバが完全に shutdown していないうちに Power OFF してしまったようだ :O。その時は「あっ」と思ったけど気にせずにそのまま掃除を続けてから、元通り組み立て直して Power ON したんだけど bios まで進まず。さらに、けたたましいアラームが鳴り出した。「あれっ？」と思いつつ [b]心の中では間違いであって欲しいとかなり焦っていたと記憶する。、何度か Power OFF/ON を繰り返したけど MB の CPU ソケット近にある LED が赤くなってアラームが鳴る状況から好転せず。ここにきて最悪な事態に陥ったことを認めざるを得なかった。

あ〜、年の瀬にサーバが故障してしまった :$。もしかしたら先程の Power OFF ではなく、その年の酷暑が原因だったかもしれない。一年中動かしているから。コロナ渦の年始は溜まっていたブログでも書こうかと思っていたので、かなり凹んでしまった ;(。

半日おいて[c]それまでやや無気力状態だったけど。いろいろ考えた結果、自宅の GW でもあるサーバの復旧がまずは第一だなということに至り、Internet に繋げられないなら Power ON しておいても意味のない My Desktop マシンをサーバに置き換えることにした。Desktop PC がなくてもノートPC やスマフォがあるし[d]画面が小さいのが難儀なんだが。。

ということで大掃除をてっとり早く終わらせて、SSD や HDD を外しては取り付けるなどしてサーバをなんとか復旧することができた。で普段どおりの Internet 生活が戻ったら心に余裕ができたのか、ついつい新しい Desktop マシンを注文してしまったのだった :P。

これまでの My Desktop マシン[e]CPUは Intel i7-5960X (16) @ 3.500GHz、GPUは NVIDIA GeForce GT 710。は六年前に自前でビルドした Ubuntu GNOME 15.04 なもので、かなり時代遅れな感じだったから、新しいマシンで最新版の Ubuntu OS でも入れて時代に追いつくことにした8)。

新年早々に注文したマシンは二週間ほどで到着。今は昔みたいに毎日ビルドするなんて時間はないので高性能を追求するつもりはなかったけど、やはり時代に乗り遅れないような spec ということで、なんと20年ぶりに AMD の CPU を Choice した[f]最後に買ったのは K6-2 だった。。おかげで今までの Intel 製よりは価格がお手頃になったよ：

CPU: AMD Ryzen 9 3950X (32) @ 3.500GHz
GPU: NVIDIA GeForce GTX 1650
Memory: 64239MiB

Linux マシンなら、これで十分。オマケに CPU クーラは水冷。静かである。一ヶ月くらいかけてインストールやカスタマイズして、最近になってやっとブログを書けるような環境にアップグレードすることができた。

今まで古い OS だったから何かと制約があったけど、これからは時代に乗り遅れないようにいろいろ楽しむ予定 :D。

参照

参照
↑a 例えばCPUファンの羽に付いている一年分のホコリを落とすなど。
↑b 心の中では間違いであって欲しいとかなり焦っていたと記憶する。
↑c それまでやや無気力状態だったけど。
↑d 画面が小さいのが難儀なんだが。
↑e CPUは Intel i7-5960X (16) @ 3.500GHz、GPUは NVIDIA GeForce GT 710。
↑f 最後に買ったのは K6-2 だった。

Migrating to the New Photo Gallery.

コメントを残す

5年前の最後の自宅サーバ構築以来、本サイトで現在使用中のフォト・ギャラリーは、今から15年も前に GNOME プロジェクトでアート系のマテリアル作成を担当していた Jakub ‘Jimmac’ Steiner 氏が開発・公開した O.r.i.g.i.n.a.l. というフォト・オーガナイザーをベースに、日本語化向上やPHP7に対応させたもの。このオーガナイザーは重量級の DB や Javascripts を多用せずに PHP 主体で、アルバム整理や閲覧、コメント投稿、テーマの変更といった機能を実現したシンプルで使いやすいシステムであった。

そういうことで現代風の User Experiences に対しては今ひとつな感じはするが、特に致命的な問題はなく利用してきたのだが、趣味で城跡攻めするようになってからデジタル画像の数が膨大になり手間が気になりだしてきた。さらにキーボードでの操作ができない実装で、常にマウスを使って閲覧するのが少し苦痛でもあった。その中で最も大きな欠点はやはりモバイル対応。基本的にデスクトップ規模のウェブブラウザが前提の実装なのでスマフォから閲覧するのはかなり辛い :|。

と云うことでフォト・オーガナイザーのフレームワークをアップグレードしようといろいろ調べた結果、Piwigo というオープンソースのウェブ向けフォト・ギャラリーソフトウェアを見つけた。というかフリーで利用できるのはこれくらいしか無かったのが本当のところだが :X。

現在運用しているサーバのリソースを大きく変更することがなくインストールに必要な要件もクリアしていたのが導入の大きな理由でもある。インストールは簡単で、ソースをダウンロードして Apache と MySQL の設定[a]Apache2.0では PHP-7.0 のメモリ上限を変更し、MySQLでは Piwigo 専用ユーザとデータベースを追加して権限をセットするだけだった。を追加・更新してから PIwigo のインストール画面にウェブからアクセスして設定するだけ。ただし「日本語」の翻訳がイマイチだったので全て見なおして翻訳を更新・修正することにした。

あとは旧ギャラリーから PIwigo に写真やコメントを移行することになるが、残念ながらこの作業は一つ一つ手作業にせざるを得なかった。なるべく前の状態を維持したかったので。写真の数が多いので仕方がないのだが :$。

ということで今後は古いフォト・ギャラリーを更新せず、未だ移行は完了していないが新しいフォト・オーガナイザーの運用と公開を開始した。プラグインやテーマも充実している他、iOS 向けの専用アプリもあるようだ 8)。但し、アルバム毎に OpenStreetMap を表示するプラグインを導入しているがこれが使用するブラウザによっては閲覧に時間がかかる場合があるようだ。今後の検討課題である。

See AlsoMikeforce::Photo Gallery （只今、旧ギャラリーから移行中）

参照

参照
↑a Apache2.0では PHP-7.0 のメモリ上限を変更し、MySQLでは Piwigo 専用ユーザとデータベースを追加して権限をセットするだけだった。

Mikeforce server downed again.

2件の返信

今月初めは平成30（2018）年9月1日に発生したサーバ障害は、その週明けにはなんとか復旧できたのだけれど、残念ながら未だ「致命的な問題」が残っていたようで再びダウンしてしまった。正確にはHDD故障で重要なパーティションをマウントできなくなり、ウェブサービスは勿論、システムサービスの類が軒並み停止してしまったという次第 :$。

最初の障害でサーバが強制Shutdownした際、HDD内のLVMである /var パーティションで何か処理していたのだろうか。リモートからサーバにログインできないことに気づいた時はなんとなく嫌な予感がしたが :|。
で帰宅して調べてみると、案の定、朝まで動いていたサーバは最後にアクセスしてから数時間後に突然、次のようなHDD読み取りエラーが発生していた：

[711805.660457] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711805.660465] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711805.660468] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711805.660471] sd 25:0:0:0: [sdh] CDB: 
[711805.660473] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711805.660484] blk_update_request: I/O error, dev sdh, sector 262761232
[711822.460908] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711822.460916] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711822.460919] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711822.460922] sd 25:0:0:0: [sdh] CDB: 
[711822.460924] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711822.460936] blk_update_request: I/O error, dev sdh, sector 262761232
[711822.460982] XFS (dm-0): metadata I/O error: block 0xfa1bb10 ("xlog_recover_do..(read#2)") error 5 numblks 16
[711822.478620] XFS (dm-0): log mount/recovery failed: error -5
[711822.478680] XFS (dm-0): log mount failed
[711827.723684] XFS (dm-0): Mounting V4 Filesystem
[711827.866409] XFS (dm-0): Starting recovery (logdev: internal)
[711830.994951] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711830.994959] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711830.994962] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711830.994965] sd 25:0:0:0: [sdh] CDB: 
[711830.994967] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711830.994979] blk_update_request: I/O error, dev sdh, sector 262761232
[711847.817378] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711847.817386] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711847.817390] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711847.817393] sd 25:0:0:0: [sdh] CDB: 
[711847.817395] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711847.817406] blk_update_request: I/O error, dev sdh, sector 262761232
[711847.817480] XFS (dm-0): metadata I/O error: block 0xfa1bb10 ("xlog_recover_do..(read#2)") error 5 numblks 16
[711847.839055] XFS (dm-0): log mount/recovery failed: error -5
[711847.839111] XFS (dm-0): log mount

このI/OエラーによってLVMの /var パーティションが読み込めなくなった。このパーティションが読み込めなくなるのはシステムとして致命的である :$。例えばゲートウェイ+ルータ機能、ブログなどのＤＢシステム、SSHなどランタイムサービスの他、apt パッケージシステムが動かない等、かなり厳しい状況だった。
特にHDD内にあるブログやウェブのデータが逝ってしまったことで、最初は心が折れそうになってしまった ;(。

1日ほど塞ぎこんでしまったが、ゲートウェイ機能を復旧させないと、いつまでたってもインターネットに接続できないので、ひとまずHDDを新調してシステムの全復旧を行うことにした。それに、かなり古いけどブログのDBのバックアップが残っていた ;) ので、時間はかかるけどブログの方は再び書いていけば、いつか元に戻るであろうと前向きに考えることにした :D。

ということで、まずは新規のSSD（120GB）とHDD（3TB）を注文、到着するまでの間は既存のHDDからデータの吸い上げ。この時、I/OエラーがでていたHDDについては重要なデータがストアされており、色々試すことで結局は負荷をかけてハードウェアの寿命が縮んでしまいそうなので、GNU Ddrescue なるツールでddイメージを安全かつ堅実に抜き出すことにした。これは本当に素晴らしいツール：

  • 不良セクタをスキップして、良好データをまず先に復旧する
  • これによりHDDに不必要な負荷をかけることがないため、最終的に復旧できるデータ量が大きい
  • 不良セクタはログに記録できる
  • 別ツールであるddrescureviewを使うとGTK+ベースの GUI 上にセクタのマップを表示することができる

I/OエラーがでたパーティションはLVMボリュームで容量は 500GB であったが、Ddrescue は特に問題なかった。このサイズのrawイメージを保存できる空きHDDを用意して、玄人志向のHDDスタンド経由でDdrescureを実行した：

$ sudo ddrescue -n -v /dev/mikeforce-vg/vgroup-var_lv ./back-vgroup-var_lv.img back-vgroup-var_lv.log 
GNU ddrescue 1.19
About to copy 536870 MBytes from /dev/mikeforce-vg/vgroup-var_lv to ./back-vgroup-var_lv.img.
 Starting positions: infile = 0 B, outfile = 0 B
 Copy block size: 128 sectors Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued: 536870 MB, errsize: 12288 B, current rate: 1686 B/s
 ipos: 268691 MB, errors: 3, average rate: 16525 kB/s
 opos: 268691 MB, run time: 9.02 h, successful read: 0 s ago
Finished

500GBのrawイメージを9時間ほどかけて取得、不良セクタは12KBと予想外に少なかった ;)。この後、XFSのfschkであるxfs_repairでファイルシステムを補修してからloopbackでマウントしてみたら、見事にパーティションを読み込むことができた：

$ sudo xfs_repair -L -f /opt/back-vgroup-var_lv.img
Phase 1 - find and verify superblock...
Cannot get host filesystem geometry.
Repair may fail if there is a sector size mismatch between
the image and the host filesystem.
Phase 2 - using internal log
 - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
 - scan filesystem freespace and inode maps...
out-of-order bno btree record 46 (98638 1) block 1/4
block (1,98638-98638) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 47 (225432 1) block 1/4
block (1,225432-225432) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 48 (292435 2) block 1/4
block (1,292435-292435) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 174 (324055 3) block 1/4
block (1,324055-324055) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 175 (324059 2) block 1/4
block (1,324059-324059) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 176 (324096 5) block 1/4
block (1,324096-324096) multiply claimed by bno space tree, state - 1
agf_freeblks 27730912, counted 27730884 in ag 1
agf_freeblks 28437926, counted 28437911 in ag 3
block (2,5220537-5220537) multiply claimed by cnt space tree, state - 2
agf_freeblks 26476336, counted 26476369 in ag 2
agi_freecount 51, counted 52 in ag 3
agi_freecount 64, counted 65 in ag 2
agi_freecount 139, counted 142 in ag 0
sb_ifree 368, counted 335
sb_fdblocks 106740156, counted 106773627
 - found root inode chunk
Phase 3 - for each AG...
 - scan and clear agi unlinked lists...
 - process known inodes and perform inode discovery...
 - agno = 0
data fork in ino 137948 claims free block 4822
data fork in ino 137948 claims free block 4823
correcting nblocks for inode 10686304, was 1 - counted 0
 - agno = 1
Metadata corruption detected at block 0xfa1bb10/0x2000
(...)
Metadata corruption detected at block 0xfa1bb10/0x2000
Metadata corruption detected at block 0xfa1bb10/0x2000
data fork in ino 536882165 claims free block 33555077
Metadata corruption detected at block 0xfa03108/0x1000
corrupt block 0 in directory inode 536896076
 will junk block
no . entry for directory 536896076
no .. entry for directory 536896076
problem with directory contents in inode 536896076
cleared inode 536896076
bad magic number 0x0 on inode 537097760
bad version number 0x0 on inode 537097760
(...)
Phase 4 - check for duplicate blocks...
 - setting up duplicate extent list...
 - check for inodes claiming duplicate blocks...
 - agno = 0
 - agno = 1
 - agno = 2
 - agno = 3
(...)
Phase 5 - rebuild AG headers and trees...
 - reset superblock...
Phase 6 - check inode connectivity...
 - resetting contents of realtime bitmap and summary inodes
 - traversing filesystem ...
(...)
Phase 7 - verify and correct link counts...
resetting inode 61515 nlinks from 20 to 19
resetting inode 512221 nlinks from 16 to 15
Metadata corruption detected at block 0x8058/0x1000
libxfs_writebufr: write verifer failed on bno 0x8058/0x1000
Metadata corruption detected at block 0x3fe90/0x1000
libxfs_writebufr: write verifer failed on bno 0x3fe90/0x1000
Metadata corruption detected at block 0x3fe90/0x1000
libxfs_writebufr: write verifer failed on bno 0x3fe90/0x1000
Metadata corruption detected at block 0x8058/0x1000
libxfs_writebufr: write verifer failed on bno 0x8058/0x1000
done
$ sudo mount -o loop /opt/back-vgroup-var_lv.img ./mnt
$

こちらがddrescueviewで表示させたもの。赤色が不良セクタ：

ddrescueviewの結果

不良セクタのサイズが少なかったことが不幸中の幸いだった。これらのセクタはMySQLのデータであったけどブログには影響が無くて安心した 0:)。

思えば、今夏の酷暑がHDDに与えていた影響は少なくない[a]加えて、筐体も普通のPCのタワー型だし。として、HDD間の配置を変更し、RootfsはSSDにして発熱を抑えることにした。そして、今さらながらHDDの寿命と故障率について身にしみたのでバックアップを励行することにした。

ということで、全復旧までお金と一週間ほどの時間を要したけど、素晴らしいツールと教訓を得ることができて良しとする。

この後は、自動バックアップシステムを構築し、S.M.A.R.Tで温度を監視しつつサーバを運用することにする。

参照

参照
↑a 加えて、筐体も普通のPCのタワー型だし。