Ubuntu Server on KnightLiブログ

2026年の Linux サーバー向けディストリビューション選び：Debian、Rocky Linux、AlmaLinux、Ubuntu Server 比較

Thu, 07 May 2026 21:03:12 +0800

2026年に Linux サーバー向けディストリビューションを選ぶとき、重要なのは「どれが一番良いか」ではなく、「どれが自分たちの運用モデルに合うか」です。

最も安定したコミュニティディストリビューションが必要なら、Debian は今でも有力な第一候補です。RHEL 互換エコシステムが必要だが RHEL を直接購入したくない場合、Rocky Linux と AlmaLinux は CentOS 後の自然な代替です。クラウドイメージ、ドキュメント、素早いデプロイ、新しめのパッケージを重視するなら、Ubuntu Server が今でも最も楽です。

以下では、サーバー用途の実務目線で比較します。

早見表

ディストリビューション	最適な用途	主な利点	注意点
Debian	長期安定、自ホスト、基礎サービス	安定、簡潔、強いコミュニティ、自由ソフトウェアの伝統	標準パッケージは保守的。企業向け商用サポートは RHEL/Ubuntu ほど明確ではない
Rocky Linux	RHEL 互換の本番環境	RHEL に近い運用習慣。CentOS からの企業移行に向く	パッケージ更新は保守的。デスクトップや新技術体験は主目的ではない
AlmaLinux	RHEL 互換本番環境、クラウド、企業向け代替	RHEL 互換、活発なコミュニティ、明確なライフサイクル	RHEL と少し差異があるため release notes の確認が必要
Ubuntu Server	クラウドサーバー、コンテナ、開発デプロイ	クラウド対応が強い、資料が多い、デプロイが速い、LTS が長い	Snap、HWE カーネル、PPA はチーム内ルールが必要

一言で言うと次の通りです。

最も無難な汎用選択：Debian。
企業向け RHEL エコシステム代替：Rocky Linux / AlmaLinux。
クラウドと開発効率優先：Ubuntu Server。

Debian：岩のような安定性

2026年5月時点で、Debian の current stable は Debian 13 trixie です。Debian 12 bookworm は oldstable に移行しており、セキュリティと LTS サポートはありますが、新規サーバー導入では Debian 13 を優先して検討するのがよいでしょう。

Debian の特徴は一貫しています。

標準パッケージ選択は保守的。
システム構造がきれい。
商用ベンダーに強く縛られない。
コミュニティガバナンスが成熟している。
長期稼働する基礎サービスに向く。

次のようなサーバーなら Debian は扱いやすいです。

Nginx / Apache。
PostgreSQL / MariaDB / Redis。
Docker / Podman。
WireGuard / Tailscale。
ファイルサービス、バックアップサービス、監視サービス。
小規模な自ホストアプリ。

Debian の強みは「最新」ではなく「手間が少ない」ことです。多くのサーバーはインストール後、数年間は通常のセキュリティ更新と小さな保守だけで動かせます。

Debian に向いている場面：

システムをなるべく素朴に保ち、ディストリビューションベンダーの戦略に振り回されたくない。
apt、systemd、Debian のファイル構成に慣れている。
ソフトウェアが最新版でなくてもよい。
安定性、セキュリティ更新、予測しやすいアップグレードを重視する。

Debian にあまり向かない場面：

ベンダーが RHEL または Ubuntu だけを認証している。
SLA 付きの企業向け商用サポートが必要。
最新カーネル、最新 GPU スタック、新しいハードウェア対応に依存している。
チームの運用標準が全面的に RHEL 系エコシステムで書かれている。

私の判断では、個人サーバー、自ホスト、軽量 SaaS、小規模チームの基礎サービスでは、Debian は今でも非常に有力です。

Rocky Linux：CentOS 後の堅実な代替

Rocky Linux の位置付けは明確です。RHEL 互換エコシステムを必要とするユーザー向けであり、かつて CentOS Linux が企業本番環境で果たしていた役割を引き継ぎます。

2026年時点で、Rocky Linux 9 と Rocky Linux 10 はどちらもサポート期間内です。Rocky Linux 9 はより保守的な本番環境に向き、Rocky Linux 10 は新規プロジェクト、新しいハードウェア、より長い将来期間に向きます。

Rocky Linux に向く場面：

以前 CentOS 7 / CentOS 8 を使っていた企業環境。
RHEL 系のディレクトリ構造、パッケージ名、運用習慣が必要。
dnf、RPM、SELinux、firewalld に依存している。
ソフトウェアベンダーが RHEL-compatible ディストリビューションを明示的にサポートしている。
社内自動化スクリプトが Enterprise Linux 前提で書かれている。

利点は移行の抵抗が小さいことです。多くのチームは CentOS を前提に Ansible playbook、監視ルール、監査スクリプト、セキュリティベースラインを長年積み上げています。Rocky Linux への移行は、Debian や Ubuntu への移行より心理的負担が小さいです。

Rocky Linux の注意点：

パッケージバージョンは保守的です。これは Enterprise Linux の設計目標であり、欠点ではありません。
非常に新しいユーザー空間コンポーネントが必要な場合、EPEL、第三者リポジトリ、またはコンテナに頼ることがあります。
RHEL 互換は、すべての商用ソフトウェアベンダーが自動的に正式サポートするという意味ではありません。認証リストを確認してください。
Rocky Linux 10 はハードウェア基準や第三者エコシステムに新しい要件があります。本番投入前に検証が必要です。

私の判断では、サーバー環境がもともと CentOS / RHEL 系なら、Rocky Linux は非常に自然な代替です。特に安定した本番環境と企業内部サービスに向いています。

AlmaLinux：より能動的な RHEL 互換ルート

AlmaLinux も CentOS 後の重要な代替です。位置付けは同じく、企業向け、長期サポート、RHEL 互換です。

Rocky Linux との共通点は多くあります。

どちらも RHEL 互換エコシステム向け。
どちらもサーバー本番環境に向く。
どちらも 8、9、10 の長期サポート系列を持つ。
どちらも CentOS からの移行に向く。
どちらも多くの Enterprise Linux エコシステムツールを使える。

違いは、AlmaLinux が RHEL 互換を保ちながら、上流との差異をより積極的に記録・処理する点です。たとえば AlmaLinux 10 は古いハードウェア向けに x86-64-v2 アーキテクチャ選択肢を提供し、release notes で RHEL との差異を明確に説明しています。

これは一部のユーザーに有用です。RHEL エコシステムに留まりつつ、ハードウェア対応、パッケージビルド、EPEL 互換性でより柔軟なコミュニティディストリビューションを求める場合です。

AlmaLinux に向く場面：

RHEL 互換が必要だが、RHEL のリリース戦略に完全には縛られたくない。
コミュニティガバナンスと透明な release notes を重視する。
クラウド、コンテナイメージ、企業ワークロードで安定したベースシステムが必要。
CentOS や古い Enterprise Linux から平滑に移行したい。

注意すべき点は、AlmaLinux が「目を閉じれば RHEL と同じ」ではないことです。厳格なコンプライアンス、ベンダー認証、データベース認証、ハードウェア認証が必要な場面では、ソフトウェアベンダーが AlmaLinux を明示的にサポートしているか確認してください。

私の判断では、Rocky Linux と AlmaLinux はどちらも CentOS 代替になります。より保守的で伝統的な CentOS 的ストーリーを好むなら Rocky、コミュニティ透明性と柔軟な互換ルートを重視するなら AlmaLinux です。

Ubuntu Server：クラウド対応とデプロイ効率が最も強い

Ubuntu Server の強みは現実的です。クラウドプラットフォーム、ドキュメント、コミュニティチュートリアル、イメージ、自動化ツール、開発者エコシステムが強いです。

2026年の新規サーバー導入では、主力は引き続き Ubuntu 24.04 LTS です。Ubuntu LTS は通常 5 年の標準サポートを持ち、ESM による延長も可能です。クラウドサーバー、コンテナホスト、開発環境、CI/CD ノードでは、Ubuntu Server が最も早く使える選択になることが多いです。

Ubuntu Server に向く場面：

AWS、Azure、Google Cloud、Oracle Cloud、Alibaba Cloud、Tencent Cloud などのクラウドサーバー。
Docker、Kubernetes、GitLab Runner、CI/CD。
AI / GPU / CUDA 開発環境。
大量のチュートリアルとコミュニティ解法が必要なチーム。
開発と本番をできるだけ同じ環境にしたい場合。

Ubuntu の利点：

クラウドイメージの品質が高い。
公式・第三者ドキュメントが多い。
新しいハードウェア対応が比較的積極的。
LTS のリズムが明確。
開発者ツールチェーンを更新しやすい。
多くの商用ソフトウェアが Ubuntu 向け手順を優先して用意する。

Ubuntu の注意点：

サーバーで Snap を好まないチームもあるため、利用方針は事前に決めるべきです。
PPA は便利ですが、本番環境で乱用すると保守リスクが増えます。
HWE カーネル、クラウドカーネル、標準カーネルのどれを使うか明確にする必要があります。
極めてミニマルな安定性を好む人には、Ubuntu の標準構成は Debian より「にぎやか」に感じられます。

私の判断では、クラウドサーバー、コンテナ、開発デプロイ、AI ツールチェーンが中心なら、Ubuntu Server は通常最も効率的です。最も「純粋」なディストリビューションではありませんが、多くの作業で調査とつまずきを減らしてくれます。

四つをどう選ぶか

個人 VPS / 自ホスト

Debian または Ubuntu Server を優先します。

安定、省心、低メンテナンスを求めるなら Debian。チュートリアルに沿って新しいプロジェクトを頻繁にデプロイする、または新しめのソフトウェアスタックが必要なら Ubuntu Server です。

企業本番環境

Rocky Linux、AlmaLinux、または RHEL を優先します。

会社が以前 CentOS を使っていたなら、Rocky / Alma への移行コストが最も低いです。商用データベース、ハードウェア認証、セキュリティコンプライアンス、ベンダーサポートが関わる場合は、認証リストを先に確認してください。

クラウドネイティブとコンテナホスト

Ubuntu Server、Debian、Rocky / Alma はいずれも使えます。

開発効率を重視するチームなら Ubuntu Server。極簡安定を求めるなら Debian。企業標準が RHEL 系なら Rocky / Alma です。

AI / GPU サーバー

まず Ubuntu Server、次に Rocky / Alma を見ます。

理由は単純です。NVIDIA、CUDA、PyTorch、TensorFlow、ドライバ導入手順、コミュニティ経験は Ubuntu が最も多いことが一般的です。企業 GPU クラスターがすでに RHEL エコシステムで構築されている場合は Rocky / Alma も選べますが、ドライバ、CUDA、コンテナランタイム、監視ツールは事前検証が必要です。

伝統的な業務システム

Rocky Linux / AlmaLinux を優先します。

伝統的な Java、データベース、ミドルウェア、商用ソフトウェア、監査、運用標準は RHEL 系に寄りがちです。この場合、Rocky / Alma は Debian / Ubuntu より既存体系に合わせやすいです。

選ぶ前に見るべき指標

ディストリビューション名だけで選ばないことです。サーバー選定では、次の質問で判断するのがよいでしょう。

ライフサイクル：このバージョンは何年まで保守されるか。
アップグレード経路：メジャーバージョンアップは成熟しているか。平滑移行は可能か。
ソフトウェア供給元：第三者リポジトリに依存するか。誰が保守しているか。
セキュリティ更新：セキュリティアドバイザリ、パッチ頻度、CVE 対応は明確か。
ハードウェア対応：CPU、NIC、RAID、GPU、ストレージコントローラは検証済みか。
チーム経験：チームは apt と dnf のどちらに慣れているか。Debian 系か RHEL 系か。
ベンダー認証：業務ソフトウェアはそのディストリビューションを明示的にサポートしているか。
自動化資産：既存の Ansible、Terraform、イメージビルドスクリプトを再利用できるか。

本当のコストはインストール ISO ではありません。今後 5 年のアップグレード、監査、トラブルシュート、引き継ぎです。

私のおすすめ構成

2026年のサーバー選定でデフォルト案を出すなら次の通りです。

場面	推奨
個人 VPS、自ホスト	Debian 13
クラウドサーバー、素早いデプロイ	Ubuntu Server 24.04 LTS
CentOS 移行	Rocky Linux 9 / AlmaLinux 9
新規企業プロジェクト	Rocky Linux 10 / AlmaLinux 10。先にエコシステム検証
AI / GPU 開発	Ubuntu Server 24.04 LTS
強いコンプライアンスが必要な商用本番	RHEL、またはベンダーサポート確認後に Rocky / Alma

短い結論

Debian のキーワードは、安定、簡潔、コミュニティ、自由ソフトウェアの伝統です。長期稼働する基礎サーバーに向きます。

Rocky Linux と AlmaLinux のキーワードは、RHEL 互換、企業本番、CentOS 代替です。既存の Enterprise Linux 運用体系を持つチームに向きます。

Ubuntu Server のキーワードは、クラウド、ドキュメント、開発効率、エコシステムの完全性です。素早いデプロイ、コンテナ、AI/GPU、クラウドサーバーに向きます。

永遠に正しいディストリビューションはありません。チーム、業務、ハードウェア、ライフサイクルに最も合うものが正解です。サーバーで最良の選択は、たいてい一番流行っているものではなく、5 年後も保守する気になれるものです。

HDD 高騰時代、NAS が満杯でもまだ増設しない：200 元 TerraMaster + HC620 のコールドデータ構成

Mon, 04 May 2026 11:46:53 +0800

HDD 価格が大きく上がっている時期に NAS の容量がいっぱいになっても、すぐにディスクを増設する必要はありません。メイン NAS が正常に動いていて、単に容量が足りなくなってきただけなら、まずデータをアクセス頻度で分けるほうが現実的です。よく使うホットデータは元の NAS に残し、あまり使わないコールドデータとバックアップは別のコールドストレージ用ディスクへ移します。

この記事は低コストな構成の記録です。大容量の HC620 をコールドデータ保存用に使い、安価な TerraMaster F2-220、F2-221、または F4 をコピーとマウント用ノードとして使います。高性能を狙う構成ではありません。今は HDD を更新しにくい時期なので、まずメイン NAS の空き容量を確保するのが目的です。

考え方

まずデータをアクセス頻度で分けます。

ホットデータ：写真、作業資料、最近のダウンロード、よく再生する動画。メイン NAS に残す。
コールドデータ：古い動画ライブラリ、アーカイブ資料、長期間動かない大きなファイル。HC620 に移す。
バックアップデータ：定期的に書き込み、たまに読むだけのデータ。これも HC620 に置ける。

HC620 の用途については、サイト内の記事 Western Digital HC620 SMR ディスクの誤解と正しい使い方も参考になります。HC620 は順次書き込み、長期保存、ランダム読み出しには向いていますが、頻繁な削除や繰り返し書き込みの多い用途には向きません。

メイン NAS の空きを確保するだけなら、HDD が高い時期に主 NAS のディスクを一気に交換するのはおすすめしません。まず使用頻度の低いデータを外へ出し、メイン NAS はホットデータを担当し続けるほうが費用対効果は高いです。

古い TerraMaster を使う理由

HC620 の問題は容量ではなく、扱いやすさです。OS、インターフェース、使い方に条件があり、USB HDD ケースへ直接入れる運用にはあまり向いていません。

そこで TerraMaster F2-220、F2-221、または一部の F4 機種を低コストなコールドデータノードとして使います。利点は分かりやすいです。

安い。中古の F2-220 は 200 元以下で見つかることがあります。
小型で場所を取りにくく、消費電力も許容しやすい。
OS を USB メモリに入れられるので、ディスクベイを消費しない。
2 個以上の SATA ベイがあり、HC620 をアーカイブディスクとして載せやすい。

この手の古い機種は性能こそ高くありませんが、コールドデータの移動、CIFS マウント、バックグラウンドコピーには十分です。F2-220 の SATA は古い SATA 3G ですが、実測では HC620 の外周側同士のコピーで約 200MB/s 出ています。コールドデータ移行としては十分で、実際のボトルネックはネットワーク、コピー元ディスクの状態、ファイル数になることが多いです。

オンボードのギガビット LAN に不満がある場合は、USB 2.5G LAN アダプタを追加する方法もあります。コールドデータノードに複雑な改造は不要です。OS がアダプタを認識し、スイッチとメイン NAS も 2.5G に対応していれば、ネットワークの上限を一段引き上げられます。

画面出力を用意する

機種に HDMI がない場合、OS インストール時に VGA が必要です。F2-220 には内部 VGA ヘッダがあります。マザーボード用の内部 12Pin VGA 変換ケーブルを使い、片側を内部ピンヘッダへ、もう片側を標準 VGA コネクタとしてモニタへ接続します。

VGA 変換ケーブルの仕様と注意点は、TerraMaster F2-220 に fnOS を入れる：VGA 出力を参照してください。検索語としては「12Pin VGA 変換ケーブル」「マザーボード 12 ピン VGA 変換」「2.0mm 12Pin to VGA」などが使えます。購入前にピッチ、向き、ピン配列を確認してください。

Ubuntu Server を USB メモリへインストールする

Ubuntu Server は USB メモリへインストールし、HDD ベイはすべてデータディスク用に残すのがおすすめです。

F2-220 は性能が低めなので、本体で直接インストールするとかなり遅くなります。より楽な方法は、USB メモリを別の速い PC に挿して Ubuntu Server をインストールし、完了後に TerraMaster へ戻して起動することです。起動方式が合っていれば、通常そのまま使えます。

インストール後はネットワーク設定を必ず確認します。ネットワークがつながらないと、起動しても SSH で管理できません。

ネットワーク設定

システムに入ったら、まずネットワークインターフェース名を確認します。

`1`	`lshw -c network`

出力例では logical name を確認できます。

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

この例のインターフェース名は enp2s0 です。次に netplan 設定ファイルを編集します。

`1`	`sudo more /etc/netplan/01-install-config.yaml`

ファイルが存在しない場合は新規作成し、次の内容にします。

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

enp2s0 は実際のインターフェース名に置き換えてください。保存後に実行します。

`1`	`sudo netplan apply`

ネットワークが復旧したら、この TerraMaster に SSH で接続できます。その後はモニタをつなぎっぱなしにする必要はありません。

HC620 を btrfs にフォーマットする

HC620 が新しいディスク、または中のデータが不要だと確認済みなら、先に btrfs にフォーマットします。以下の操作は対象ディスク上のデータを消します。実行前に必ずデバイス名を確認し、メイン NAS の共有ディレクトリやシステム USB メモリを誤ってフォーマットしないようにしてください。

現在のディスクを確認します。

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

より安定したディスクパスも確認できます。

`1`	`ls -l /dev/disk/by-id/`

HC620 に対応するデバイス名を確認したら、既存のマウントを解除します。

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

ディスク全体をそのまま btrfs にする場合は、次を実行します。

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

各パラメータの意味は次の通りです。

-f：ファイルシステム作成を強制し、古い署名で止まるのを避ける。
-O zoned：zoned 機能を有効化する。HC620 のようにゾーン単位の順次書き込みが必要なディスクに向く。
-d single -m single：データとメタデータを単一ディスクモードにする。
-L HC620_01：識別しやすいようにラベルを設定する。

システムやカーネルの zoned btrfs 対応が不安定な場合は、以前の実測記録約 600 元の新品 WD HC620 14T は買う価値があるかも参照してください。この種のディスクは、カーネルバージョン、SATA コントローラ、ファイルシステム対応に影響されます。異常がある状態で本番データを入れないほうが安全です。

フォーマット後、まず一時的にマウントして確認します。

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

正常にマウントできることを確認してから、/etc/fstab に書いて自動マウントします。長期運用では /dev/sda ではなく /dev/disk/by-id/ を使うほうが、再起動後のデバイス名変化を避けられます。

マウントを設定する

このコールドデータノードでは、通常二種類のパスをマウントします。

メイン NAS の共有ディレクトリ。移行対象データを読むために使う。
ローカルの HC620 データディスク。コールドデータとバックアップを保存するために使う。

まずマウントディレクトリを作成します。

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

CIFS/SMB 共有をマウントする場合はツールをインストールします。

1
2

sudo apt update
sudo apt install cifs-utils

次に /etc/fstab を編集し、次のような内容を追加します。

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

1 行目はメイン NAS の共有ディレクトリをマウントします。後ろの 2 行はローカルディスクをマウントします。

実運用では、データディスクには /dev/disk/by-id/ のような安定したパスを使うことをおすすめします。再起動後に /dev/sda と /dev/sdb の順番が変わることを避けるためです。HC620 のフォーマットとマウントの注意点は、以前の記録約 600 元の新品 WD HC620 14T は買う価値があるかも参考になります。

編集後はマウントをテストします。

1
2

sudo mount -a
df -h

メイン NAS の共有ディレクトリとローカルデータディスクが表示されることを確認してから、データ移行を始めます。

バックグラウンドでファイルをコピーする

大量データの移行では、SSH の前景で普通の cp を直接実行するのはおすすめしません。ここでは screen + mc を優先します。screen は SSH が切れてもタスクを残すため、mc は見やすい 2 ペインのファイル管理画面を使うためです。

mc はコールドデータを手作業で整理する用途に向いています。左側にメイン NAS のマウントディレクトリ、右側に HC620 のデータディスクを開き、ファイルを選んで F5 を押すだけでコピーできます。コピー中は現在のファイル進捗と全体進捗が表示されるため、大量ファイルの移動では単なるコマンド出力より分かりやすいです。

上の画像はファイルコピー時の進捗ウィンドウのイメージです。Midnight Commander 公式マニュアルでも、コピー、移動、削除操作は verbose モードでファイル操作ダイアログを表示し、現在ファイルと全体の進捗を表示できると説明されています。

ツールをインストールします。

`1`	`sudo apt install screen mc rsync`

バックグラウンドセッションを開始します。

`1`	`screen -S cold-data`

screen の中で mc を起動します。

mc

基本的な使い方は、左右のペインでコピー元とコピー先を開き、ショートカットで操作する形です。

Tab：左右ペインを切り替える。
Insert：複数のファイルやディレクトリを選択する。
F5：反対側のペインへコピーする。
F6：移動またはリネームする。
F8：削除。慎重に使う。

スクリプト化しやすく、繰り返し実行できる同期が必要な場合は rsync を使います。

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

コピー中に SSH が切れても、screen セッションは残ります。再接続後に次を実行します。

`1`	`screen -r cold-data`

元のコピー作業へ戻れます。

使用上のおすすめ

この構成はコールドデータとバックアップ向けです。HC620 を高頻度書き込みディスクとして使うのは避けます。おすすめの使い方は次の通りです。

メイン NAS はホットデータと日常サービスを担当する。
HC620 には長期保存の大きなファイル、動画ライブラリ、アーカイブ資料を置く。
データ移行は順次書き込みを中心にし、頻繁な削除や小ファイルの反復書き込みを避ける。
重要データは少なくとも 2 コピー残す。唯一のコピーを 1 台のディスクだけに置かない。
移行後はファイルをサンプル確認し、ディレクトリ数とファイル数が自然か確認する。

今後 HDD 価格が下がれば、メイン NAS アレイの更新を検討しても遅くありません。現時点では、低コストノードで容量圧力を逃がすほうが、リスクと費用の両面で扱いやすいです。

まとめ

NAS の空き容量がなくなっても、すぐに新しいディスクを買って増設する必要はありません。メイン NAS をホットデータ用、HC620 をコールドデータとバックアップ用に分け、安価な TerraMaster F2-220、F2-221、または F4 をマウントとコピー用ノードとして使う構成は、投入コストが低く、実用性の高い一時対応です。

重要なのは性能ではなく役割分担です。メイン NAS は日常利用の快適さを維持し、コールドデータは別に保存する。これにより空き容量を確保しつつ、HDD 高騰期の大きな出費を避けられます。