メインコンテンツへスキップ
見出し画像

【悲報】SSDが壊れました…

    こんにちはRcatです。
    今回はとてもしょうもないですが、悲しくてしょうがないので書かせてください。SSDが壊れました…。

    次回 監視を自動化

    交換できました


    はじめに

    利用規約

    情報や作品の活用時は事前に利用規約をご確認ください。

    https://note.com/rcat999/n/nb6a601a36ef5

    コメントについて

    利用規約のガイドラインを確認の上コメントしてください


    状況

    対象

    今回は以下のPCの話となります。
    増設しているデータ用SSDが壊れました。

    状況

    バックアップ(Linuxへ書き込み)放置してたら、いろんなBOTが落ちたり再起動を繰り返してて、バックアップサーバーも落ちてた。

    面倒なので再起動かけたら一向に立ち上がらない…

    ディスプレイを接続すると、以下のメッセージが

    Welcome to emergency mode! After logging in, type "journalctl -xb" to view
    system logs, "systemctl reboot" to reboot, "systemctl default" to try aga into boot into default mode.
    Give root password for maintenance
    (or type Control-D to continue):

    emergencyとか恐ろしすぎるんですけど。
    とりあえずこんな画面になっていたので立ち上がらなかったようだ。

    分析

    こんなことは初めてなのでチャッピーに色々聞くと、SSDが悪さをしてるっぽい。

    言われた通りのコマンドを実行して、結果を画像認識のテキストで投げるだけで分析してくれるってありがたいですね。

    画像

    つまりLinuxは無事だけど、マウントしないといけないファイルシステムが無いから起動できなかったよということらしい。

    対策

    マウントできないから起動できないだけなので、マウントの設定を消しました。

    #/etc/fstab

    一番下をさよなら

    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device; this may be used with UUID= as a more robust way to name devices
    # that works even if disks are added and removed. See fstab(5).
    #
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    # / was on /dev/nvme0n1p5 during installation
    UUID=4344a6a1-ca75-4b5a-8a53-fb0962fae053 /               ext4    errors=remount-ro 0       1
    # /boot/efi was on /dev/nvme0n1p1 during installation
    UUID=D288-7E29  /boot/efi       vfat    umask=0077      0       1
    /swapfile                                 none            swap    sw              0       0
    #UUID=6842d5c4-598b-445b-b172-6f6e223679fa /SSD ext4 defaults 0 0

    無事起動しました

    影響

    データ用に分けていたもので、OSとは切り離していたのでサーバー自体にはほぼ影響がないですが、外部依存が全部死にました。

    Dify

    作業フォルダを基本外部ストレージでやっていた関係で、Difyがこっちに入ってました。
    よって今まで作っていたLLMチャットボットが全滅。いくつかのAIシステムが軒並みダウンしました。

    救いだったのは、データ配布用にデータをエクスポートしてあるものがあったこと。
    これによりいくつかはすぐ復旧できましたが、プライベートで使っているものはプロンプト情報が失われました。

    今後の対策
    そもそもDifyのワークフローに頼ることがほぼなく、AIのAPIの踏み台賭してしか使っていなかったので、今後はすべてプロンプトはプログラムの方に書き、Difyは空のBOTとします。
    それでも、更新が激しいAIの分野ではモデルを切り替えるのが大変なので、Difyでモデルを簡単にチェンジできることを考えると使用は継続です。

    画像

    空っぽ。右上のモデルをチェンジするだけの利用とする。

    画像生成AI

    別アカウントでやってる画像生成の方が生成データ含め全損。
    noteに出す分はDLしてあったので無事ですが、最近サボってた数千枚はロスト確定。

    Stable Diffusion本体とAPI用のBOTプログラムなども全部入ってたのでこれもロスト。
    BOTは手元にあるが、ちょこちょこサーバーの方のを書き換えてた覚えがあるのでほんとうに最新かは不明。

    一旦区切りとしてやめて、やりたくなったらリニューアルかな…。

    バックアップ

    こちらでやっているバックアップアプリのバックアップ先がこのSSDでした。
    バックアップが消えたからと言って特に問題は無いですが、このタイミングでバックアップ元にも障害が発生すると本気でまずい。

    今後の対策
    相互バックアップに変更します。
    GUIで動かす前提なので、クライアントは少し変えないといけませんが、サーバーはWindowsでも動くので、WIndowsでも実行し、LinuxからもデータをWindowsPCに随時転送するようにしようと思います。

    思ったより影響大きくない?

    まぁそうですね。日曜が完全につぶれましたが。
    そもそもLinuxサーバーはメインのPCではないので、データが飛んだところで精神に異常をきたすレベルの損失はありません。
    もちろん、Linux前提でいろいろ動いているものがあるので、止まると厄介ではありますが。

    Rcatのデータ損失対策

    今回は大した対策してないディスクがいかれてしまいましたが、メインのデータは結構頑丈に守ってます

    • メインのPC

      • RAID1
        2枚のディスクに同時に書き込み、どちらかが壊れても大丈夫というものです。
        CドライブではないのでCには大事なものは置かない。

      • Googleドライブ
        ごく一部の重要なデータはクラウドにもおいています。


    壊れたSSD紹介

    最後に壊れた製品の紹介です

    こちらが壊れたSSDになります

    画像

    購入は2年前。24Hサーバーなので大体18000時間くらいかな。
    ※壊れているので確認できない。電源投入回数は少ないかも。

    1TB 5千円台に飛びついてしまったのが悪かったのか、意外と持たなかった。商品名みると3年保証って書いてあるので、自信あるんだろうと踏んだのがいけなかったのか。
    とりあえず保証期間であることだけ主張してみようと思う。

    画像

    本来であれば株価分析の話をするはずだったのですが、パーになりました…。それではまたお会いしましょう

     
     
    モノづくりが趣味。 "売ってないなら自分で作ればいいじゃない"をコンセプトに、機械/電気/AI/プログラム/ネットワーク 全部やります。 記事執筆はAI不使用。 ご連絡や利用規約はプロフィール記事参照。

    あなたへのおすすめ