タグ: ホームサーバ

  • GooglePhotoからNextCloudへの完全移行で少し焦った話

    先日書いた記事で、WindowsからLinuxに移行したと書きました。また、既に自宅のネットワーク内には、ミニPCやシンクライアントをホームサーバ化して、NextCloudやNASを設置しており、Googleなどの巨大IT企業によるクラウドサービスからも少しずつ離脱しつつあります。

    そんな中で、ブログやnoteの記事のネタや下書き、書いた文章の保管に使っていたGoogle Keepは、NextCloudのノート機能に移行できました。

    GoogleTakeOutのサービスから、Google Keepの中身をダウンロードして、NextCloudのドライブに放り込んで無事に取り込めました。

    ただ、このときに元ネタのKeepの1つ1つのメモファイルの更新日時が、GoogleTakeoutでの出力日時になってしまっていて、NextCloudのノート上では全部同じ日時になってしまい、時系列がわからなくなってしまいました。Keepでのラベルをノートのカテゴリに設定できたので、まるっきりメチャクチャになったわけではないですが、一覧性が落ちてしまったことは残念です。

    そして、Google PhotoからNextCloudに移行するに当たっては、同じ轍を踏まないようにします。GoogleTakeoutからダウンロードした写真・動画はやはりEXIFの更新日時が出力日時に設定されてしまっています。

    ということで、ダウンロード時に同じ名前で同梱されていたJSONファイルを利用して、写真・動画の更新日時を修正するスクリプトをChatGPTに書いてもらい、それを使って一気に変換しました。

    ファイル数や保存先ドライブの読み書き速度にもよりますが、私の場合はGooglePhoto上で13GBほどだったのが、GoogleTakeoutで出してみると60GBあり、それを解凍してから上記のスクリプトで変換するのに1時間位かかりました。ほったらかしにしていたらいつの間にか終わっていたので、実際は数十分だったかもしれません。

    さて、晴れてこのファイルたちをNextCloudに突っ込めば終わりだー!と思っていたのも束の間、突っ込んだら途中で止まってしまい、調べてみると、NextCloudの外部ストレージとしてNASに設定していたフォルダを利用せずに、Proxmoxのノードとして作ったNextCloud本体のストレージにコピーしてしまっていました。

    当然ながらProxmoxのVMとして60GB超の余裕なんか設けておらず、完全に隙間がなくなってしまいました。

    アップロードしたファイルを消したら終わりかと思っていたところ、消しても何故か空き容量が増えず、ずっとルートディスクが満杯のままです。MariaDBもなんかおかしくなり、ChatGPTにエラーメッセージを見せて解決策を指示されるがままに実行しても解決できず。

    こんなんどうすんねーん!と悩んでいましたが、ふと思い出しました。Proxmox Backup Serverには、NextCloudのノードのバックアップがあることを。そこから、キレイなNextCloudのノードをリストアすればいいだけです。

    今のグチャグチャになったノードを停止して削除してから、PBSのバックアップから復旧させると、当然ですが大量コピーでおかしくなる前のNextCloudが復活しました。

    そして、改めて外部ストレージとして設定しているフォルダに、GooglePhotoの60GBの写真・動画をコピーして終わりです。特に何も問題は起きません。ProxmoxのノードにOpenMediaVaultを使って設定しているNASの保存用ストレージはUSB接続の2.5インチHDD(5台をMergerDS+SnapRaidで使用)ですので、速度的には速くないですが、保存が目的で閲覧はそんなにしないのでこれでも十分です。そのうちImmichに乗り換えるかもしれませんが。

    かくして、GooglePhotoからNextCloudへの乗り換えも完了しました。次はGoogleカレンダーですかね。

  • Proxmoxをアップグレードしてみた

    Debian 13が正式に公開されましたが、DebianベースのProxmoxは一足先に新バージョンである9.0が公開されていました。そんなんいいんですかね。

    自宅のネットワークでは、ProxmoxのクラスターをミニPC3台で構築していますので、アップグレードする対象も3つになります。元のバージョンは8.4.9で、すでにapt update済です。

    アップグレードのレポートは、Linuxやサーバに詳しい諸兄が、すでにQiitaやZennやnoteで書かれていますので、それらも参考にしましたが、ちょくちょくややこしいこともあるみたいですので、具体的な方法は、Google AI StudioにてGemini 2.5 Proさんにお聞きしました。

    人それぞれ異なる環境によって、アップグレード前の準備と実際の手順は多少異なるはずですが、概ね
    ・バージョン8.4.*までアップデートする
    ・VMやLXC及びホストのバックアップを取る
    ・VMとLXCをシャットダウンもしくはマイグレーションで移動する
    ・pbs8to9 –full で事前にチェックして、エラーと警告の項目に対応する
    ・APTリポジトリをtrixieに変更する
    ・apt dist-upgrade でアップグレードする
    ・再起動する
    ・アップグレード後にVMとLXCを復帰させる
    といった流れです。CephやHAについては使っていないので分かりません。使っている人ならご自身で調べてなんとかするでしょうけれど。

    多分、面倒なのは事前チェックで出てきたエラー・警告への対応でしょう。私の場合は、3つのホストで以下のような表示が出てきました(1つのホストでしか出ていないものと、重複しているものがあります)。

    WARN: systemd-boot meta-package installed but the system does not seem to use it for booting. … Consider removing ‘systemd-boot’
    WARN: The matching CPU microcode package ‘intel-microcode’ could not be found! … apt install intel-microcode
    WARN: dkms modules found, this might cause issues during upgrade.
    WARN: Deprecated config ‘/etc/sysctl.conf’ contains settings – move them to a dedicated file in ‘/etc/sysctl.d/’.
    WARN: The matching CPU microcode package ‘amd64-microcode’ could not be found! … apt install amd64-microcode

    どれくらい個人差があるか分かりませんが、intelやAMDのmicrocodeの問題ってここで初めて対応することになるのが、「なんでやねん」という感じもしますけれど。

    なんやかんやエラーとかありましたけれど、その都度Geminiに聞きながらなんとかホスト3つともアップグレードに成功し、9.0.3になりました。

    Proxmoxだけ利用しているのであればここで終了なのですが、私の場合は別PCでProxmox Backup Serverも動かしていますので、こちらもアップグレードしないといけません。PVEを9にアップしたら、PBSも4にしないと不具合が起きるらしいです。

    ということで、PBSのアップグレード方法をGeminiに聞きつつ実行していきます。ちなみにPBSでの事前チェックコマンドは
    pbs3to4 –full
    です。

    こちらもほとんどやることはPVEのときと変わりませんが、事前準備でデータストアのドライブは、オプションからメンテナンスモード(リードオンリー)にしておくべきなんだそうです。アップグレード中にバックアップデータをいじったらヤバそうなのは素人目にも分かります。

    PBSのアップグレードもなんだかんだエラーとかありましたが、ここでもその都度Geminiに聞いていくと全部解決して無事、アップグレードできました。現時点での最新バージョンは4.0.12ですね。

    Proxmoxは2年毎のバージョンアップグレードが行われるようですが、移行猶予期間みたいなものとして1年プラスされるので、今回のPVE9とPBS4はおそらく2028年8月までサポートされるはずです。まあ、次のバージョンが出たら出たですぐに飛びついてしまうとは思いますけど。

  • Mergerfs&Snapraid導入、いくつかのサービス停止、k3sクラスターなど、サーバ構成を色々変更しました

    Proxmox3台+ゲートウェイPCという構成でしたが、これにバックアップ用のシンクライアントを購入したと前のエントリで書きました。Proxmox3台の中でも、USB接続HDDを各サーバ(NextCloudやJellyfinなど)にそれぞれ接続していましたが、それらの外部ストレージをOpenMediaVaultに一括してまとめ、Mergerfs&Snapraidを使って、擬似的に1つのストレージにして、かつ擬似的なRAID構成にして、NextCloudやJellyfinがそれにアクセスするような形にしました。

    また、ほとんど使っていなかった、
    Memos
    ChangeDetection
    ArchiveBox
    も停止しました。LXCコンテナの削除までは行っていませんので、また使いたくなったら有効にします。

    あと、サーバ監視として、少し前はWindowsで動かせるPRTGのフリー版を使っていて、その後、UptimeKumaをコンテナに入れて運用していましたけれど、結局のところ手の届くところにあるサーバで、ゲートウェイPC以外はProxmoxの管理画面で確認出来るのだから、サーバ監視サービスも要らないと言えば要らないですね。こちらも停止させてました。

    合計で4つのコンテナを使わなくなったことで、かなりリソースに余裕が出てきました。こうなると逆に貧乏性のためか、余っているのがもったいなく感じてきます。

    ということで、興味はあったけれど全く理解出来ないKubernetesに手を出してみることにしました。今のハードウェア的なリソースでは、フル環境のK8sはかなり重めになってしまい、他のサーバを停止させかねないので、軽量なK3sを導入してみます。

    K3sは1つのノードからでも実行出来ますが、せっかくなので各Proxmoxのホストに分けて、マスターノードとワーカーノード2つを構築しました。

    ということで、結局のところ、今の動かしているサーバ構成は以下のようになりました。

    ゲートウェイ(Zimaboard)
    CPU:Intel Celeron N3450(4コア4スレッド)
    メモリ:2GB
    ストレージ:eMMC 32GB
    OS:Ubuntuserver24.04
    サーバ内容:ファイアウォール(UFW)、VPN(WireGuard)、広告ブロック(Pi-hole)

    バックアップサーバ(T520)
    CPU:AMD/GX-212JC
    メモリ:4GB
    ストレージ:M.2 SATA SSD 16GB
    OS:Proxmox Backup Server
    サーバ内容:Proxmox Backup Server

    PVE(Wyse5070)
    CPU:Intel CeleronJ4105(4コア4スレッド)
    メモリ:DDR4 16GB
    ストレージ:SATA接続SSD 480GB
    OS:ProxmoxVE
    サーバ内容:
    RSSリーダーのLXCコンテナ(CPU1コア、メモリ1GB、スワップ1GB、ストレージ10GB)、
    Apt-cacher-ngのLXCコンテナ(CPU1コア、メモリ2GB、スワップ512MB、ストレージ100GB)、
    OpenMediaVaultのVM(CPU2コア、メモリ4GB、ストレージ10GB、USB接続HDD2TBx2台、USB接続HDD1TBx3台)
    K3sのワーカーノードのVM(CPU2コア、メモリ2GB、ストレージ20GB)

    PVE2(N100)
    CPU:Intel N100(4コア4スレッド)
    メモリ:DDR4 16GB
    ストレージ:SATA接続SSD 240GB
    OS:ProxmoxVE
    サーバ内容:
    JellyfinのVM(CPU2コア、メモリ4GB、ストレージ32GB)、
    K3sのワーカーノードのVM(CPU2コア、メモリ2GB、ストレージ20GB)

    PVE3(3550H)
    CPU:AMD Ryzen5 3550H(4コア8スレッド)
    メモリ:DDR4 16GB
    SSD:NVMe接続SSD 512GB
    OS:ProxmoxVE
    サーバ内容:
    WordPressのLXCコンテナ(CPU2コア、メモリ4GB、スワップ1GB、ストレージ10GB)、
    Nginx Proxy ManagerのLXCコンテナ(CPU1コア、メモリ1GB、スワップ1GB、ストレージ8GB)、
    NextCloudのVM(CPU4コア、メモリ8GB、ストレージ50GB)
    K3sマスターノードのVM(CPU2コア、メモリ4GB、ストレージ20GB)

    K3sの各ノードは、上記にあるようなスペックよりも少な目でも動くようですけれど、せっかくなので多目にリソースを配分しています。

    ただ、Kubernetesのクラスターを作ったは良いものの、ここからの勉強が大変ですね。
    ゆくゆくは、現在コンテナやVM内のDockerで構築している各サーバを、K3s上に移行させたいですが、学びつつやっていくのは時間がかかりそう・・・。