中小企業向けサーバー構築ガイド

社内のファイル共有と公開予約アプリでは、必要な機器、予算、復旧計画が異なります。サーバーの構築方法を決めるには、まず継続して動かすべき業務を明確にします。一から構築する場合は、互換性のある部品を選んで組み立て、OS をインストールし、実際に使えるサービスを設定します。

社内文書用なら、静かなタワー型を購入するのが合理的な場合があります。インターネット向けアプリなら、レンタルによって機器や設備の作業を省けるかもしれません。どちらの場合も、アクセス、更新、復旧の担当者が必要です。

ハードウェアに触る前に、部品のマニュアル、片付いた作業台、メーカー推奨の静電気対策を用意します。セットアップには、有線ネットワーク、インストール用 USB、手元のキーボードと画面、個別の管理者アカウント、テスト用の別のコンピューターを用意します。ディスク構成を変更する前に、既存データを別の場所へコピーしてください。

ハードウェアを選ぶ前に業務を定義する

請求書を保存する共有フォルダーには容量と安定したファイルアクセスが必要です。公開アプリでは外部接続とアプリケーションのサポートも加わります。CPU やメモリの特売を基準にサーバーを組む前に、業務内容を書き出しましょう。

簡潔な要件シートを使います。

• サービス名と利用するアプリケーションを記載します。バックアップ中に文書を開くなど、同時に行う作業を列挙します。
• 現在のデータ量、想定増加量、保持するバージョンを測定します。業務に必要な使用可能容量と、ドライブのラベル容量の合計を区別します。
• 社内限定か公開かを明記します。アクセスが必要なスキャナー、プリンターなどのローカル機器も含めます。
• 許容できるデータ損失の時間幅である目標復旧時点（RPO）と、サービス復旧までの許容時間である目標復旧時間（RTO）を設定します。
• 管理者と不在時の代行者を決めます。購入予算と継続的な運用予算を記録します。

従業員数だけでは容量は決まりません。代表的なファイル群と同時実行する作業を使う方が、適切な受け入れテストになります。

自作、購入、レンタルを比較する

社内スイッチの近くに置くタワー型なら、ローカルネットワークと電源が生きている限り、インターネット障害中でも社内でファイルを転送できます。レンタルサーバーでは機器が別の場所にあり、社内からのアクセスは WAN 接続に依存します。各方式の責任分担は次のとおりです。

部品選択の自由に価値があり、機器全体を診断できる人がいるなら自作を選びます。単一の販売元による修理手続きに追加費用を払う価値があるなら、サポート付き完成品を選びます。再生品では、支払い前にファームウェアのサポート、ドライブの摩耗、付属のトレイとケーブル、騒音、消費電力、書面の保証を確認してください。

レンタルのVPS と専用ハードウェアの選択は、リソースと分離の判断です。小さなアプリなら VPS で足りる場合がありますが、継続的な要求やハードウェア制御が必要なら専用サーバーが適切かもしれません。物理コアと VPS の vCPU は、交換可能な処理容量の保証ではありません。

自作サーバーに決める前に VPS を検討する

ハードウェアの購入は、実際の負荷の動きを把握する前に資金を投入することを意味します。自作では互換性確認と組み立ても加わります。完成品ならその工程は不要ですが、場所、電源、冷却、故障対策は必要です。社内で動かす必要のないウェブサイト、アプリ、テスト環境なら、レンタルで早く始め、実際の要件を把握できます。

当社の Linux VPS プランは DDR5 メモリ、高速な NVMe ストレージ、ホストの 40 Gbps アップリンクによる接続を提供します。専用 vCPU 容量が必要な負荷には、High Performance プランが仮想サーバー用に容量を確保します。機器を購入したり、社内のインターネット回線で公開サービスを運用したりせずに、十分なインフラを利用できます。

ソフトウェアの管理権も保持できます。当社の VPS は非マネージドで、SSH 経由の完全な root アクセスを提供します。OS の選択、アプリのインストール、サービスの設定は自分で行います。更新、セキュリティ、バックアップも利用者の責任であり、自社サーバーの運用に必要な管理作業を実地で経験できます。

時間単位の課金なら、小さな割り当てから始められます。PAYG プランでは、要件の変化に応じてダッシュボードからサイズ変更ができ、無料のリソース監視で使用状況を確認できます。新規顧客向けの14 日間返金保証では、2 週間サービスを評価し、合わなければ保証条件に従って返金を申請できます。

レンタルを選んでも、将来の自社所有を妨げません。後から物理 Linux サーバーを構築する場合は、ソフトウェア構成を再インストールし、ファイルとデータベースのエクスポートを移し、設定を調整して、切り替え前にすべてをテストできます。VPS 管理で得た経験は移行にも役立ちます。

構成を負荷に合わせる

社内ファイルと共有文書

有線 Ethernet でローカルアクセスする一般文書が約 2 TB あると仮定します。静かなタワー型に、最近の 4～6 コア CPU、対応する 32 GB メモリ、500 GB の起動用 SSD、Linux ソフトウェア RAID1 のデータミラーを構成する 4 TB HDD 2 台を搭載する案から検討します。ファイルシステムの管理領域と予約領域を引く前の生容量は、4 TB ドライブ約 1 台分です。起動用 SSD は単一障害点のままです。

サーバー、スイッチ、クライアント全体でギガビット Ethernet を使い、対応 UPS を用意します。別途、取り外せる 8 TB のバックアップディスクと、独立して保護する遠隔地のコピーを確保します。バージョンやファイルの増加でディスク容量を超える可能性があるため、変更量と保持バックアップ容量を測定します。この設計は動画編集の転送性能を保証しません。

例示する予算 1,200～1,800 米ドルには、ハードウェア、UPS、ローカルバックアップ機器を含みます。税金、人件費、ライセンス、遠隔地保管の料金は含みません。以下のインストールでは、この社内ファイルのシナリオを実装します。

公開ウェブサイトまたは軽量アプリ

小規模なデータベースと少量のメディアがあり、初期の作業データが 20 GB 未満と仮定します。OS、ログ、成長用の空きを残し、一般的なレンタル構成の 2～4 vCPU、4～8 GB メモリ、80～160 GB SSD を評価します。アプリごとの負荷テストが必要であり、この割り当ては訪問者数の処理能力を示しません。

物理機の代案は、最近の 4～6 コア CPU、16 GB メモリ、500 GB SSD 1 台です。フォーマットと OS 分を引くと、使用可能容量はラベル表示を下回ります。ドライブ冗長性はありません。有線接続、UPS、独立したバックアップ先を含む、仮のハードウェア予算 800～1,400 米ドルを想定し、除外項目は上記と同じとします。

社内から公開ホスティングを行うには、適切な上り帯域、アドレス設定、回線事業者の条件も必要です。パッチ、電源の可用性、アプリのサポートを計画します。これは別の導入判断であり、以下のファイル共有設定では公開ウェブ用ソフトウェア一式はインストールしません。

内部サービスとテスト環境を分離する

複数の分離したサービスの稼働データ合計が 400 GB 未満と仮定します。ホストの例は、最近の 8 コア CPU、対応する 64 GB メモリ、ミラー化した 1 TB SSD で、プラットフォームが求める場合は起動デバイスを別にします。管理領域を引く前の生データ容量は約 1 TB で、各ゲストディスクがこの共有プールを消費します。

ゲストメモリを 8 + 8 + 16 GB、ホストとストレージに 8 GB とすると、割り当て済みは 40 GB、残りは 24 GB です。これは Proxmox の要件にあるホストとゲストの合算方法に従いますが、CPU 性能や対応ゲスト密度を実証するものではありません。VT/AMD-V、ドライバー、ゲストのライセンスを確認します。デバイスパススルーでは IOMMU 対応も関係します。ハードウェア RAID 上で ZFS を使わないでください。

有線ネットワーク、UPS、独立したゲストバックアップを使います。仮の予算 1,800～3,000 米ドルにはハードウェア、UPS、ローカルバックアップ機器を含み、税金、ライセンス、人件費、遠隔地の料金を除外します。サーバー仮想化はゲスト環境を分離しますが、物理ホスト 1 台は依然として単一障害点です。

互換性のあるサーバー部品を選ぶ

CPU がソケットに収まっても、起動には別バージョンの BIOS が必要な場合があります。正確なマザーボード型番を基準に互換性表を作り、接続するすべての部品をマニュアルで確認します。この確認は前述の構成にも適用されます。検証済みの購入リストではありません。

CPU

アプリに応じて処理能力を選びます。単一の高負荷スレッドに制約される作業と、コア間で仕事を分散できるソフトウェアでは、強化の効果が異なります。ファイル配信はディスクやネットワークにも依存するため、高価な CPU でも元のボトルネックが残ることがあります。

ソケットとチップセットを合わせ、マザーボードの CPU 対応一覧で正確な型番と必要な BIOS を確認します。ASUS の CPU とメモリの互換性確認手順に一覧の場所が示されています。付属 BIOS で選んだ CPU が起動するか販売元に確認します。インストールに内蔵グラフィックスや基板管理用の画面出力が必要かも確認してください。

RAM

OS と同時実行アプリに足り、成長余地のある容量が必要です。対応 DDR 世代、最大容量、スロット数、マニュアルの装着順を確認します。最初のメモリ一式を基板の認定メモリ一覧から選ぶと、自力で解決する組み合わせを減らせます。

UDIMM はアンバッファードメモリ、RDIMM はレジスタードメモリです。異なる種類のモジュールであり、ECC 対応だけでは互換性は決まりません。Supermicro のレジスタードメモリ互換性 FAQでは、該当する X11SCA 系列でレジスタード DIMM を明確に非対応としています。ECC が必要なら、CPU、基板、モジュールすべての対応を確認します。増設時に全モジュールを捨てずに済む拡張方法を残してください。

ストレージ

修理や復旧が分かりやすくなるなら、OS デバイスと業務データを分離します。SSD はストレージ応答に敏感な負荷、HDD は一般文書の容量確保に向きます。どちらも容量だけで決めず、想定用途、保証、耐久性情報、交換品の入手性を確認します。

RAID1 は 2 台にミラーデータを保存し、片方の故障に耐えられます。ただし削除、ランサムウェア、施設の喪失には独立したバックアップが必要です。フォーマット後の容量を確認し、成長用の空きを確保します。SATA または NVMe のインターフェース、ドライブ寸法、ベイ、ケーブルを合わせます。M.2 スロットの使用でデータディスク用 SATA ポートが無効にならないか確認してください。

マザーボード

CPU と BIOS の互換性、メモリの認定ベンダー一覧（QVL）を記録したら、特に新しいプラットフォームでは、オンボードのネットワークとストレージコントローラーの Linux 対応を確認します。

使用する SATA コネクター、M.2 ソケット、PCIe スロット、ファン端子を数えます。レーン共有表を確認してください。SSD や拡張カードの装着で別スロットの接続能力が下がることがあります。基板規格と取り付け穴をケースに合わせます。手元に画面がない機器では遠隔管理が役立ちますが、保護された専用アクセスとファームウェア保守も必要です。

ネットワークインターフェース

高速な NIC でも、遅いスイッチ、クライアント接続、ストレージは速くなりません。購入して増強する前に経路全体を確認します。社内ファイル例のギガビット接続を計画上の候補とし、代表的なファイルの同時コピーをテストします。

選んだ Linux リリース用ドライバーがあるか確認します。増設カードには適切な PCIe スロット、取り付け空間、対応する接続が必要です。スイッチのポートと配線も購入確認に含めてください。サーバー NIC と合わせて転送性能を決める要素です。

電源装置

ケースに収まり、必要なコネクターでマザーボード、CPU、ドライブに給電できる PSU を選びます。起動時の要求と増設予定も負荷見積もりに含めます。部品メーカーの指針に従い適切な余裕を持たせてください。大きなワット数表示だけでは適否は分かりません。

基板の主電源と CPU 電源、ドライブ電源プラグ、ケーブルの長さを確認します。モジュラー PSU では、その正確な型番に付属するか明示的に承認されたケーブルだけを使用します。独自電源のケースでは交換品の入手性も確認してください。

冷却

CPU クーラーをソケット、CPU の電力制限、ケース内の空間に合わせます。背の高いメモリもクーラーに干渉する場合があります。取り付けキットの付属を確認し、熱伝導材と締め付け順は説明書に従ってください。

ドライブ周辺からケース内を通る空気の経路を確保します。風路の詰まりや熱がこもる戸棚は、ファンを増やしても解決しません。マニュアルのファン端子定格と制御設定を確認します。組み立て後、代表的な作業中の温度を調べ、本番運用前に冷却を調整してください。

ケース

別の機器室向けの装置より、静かなタワー型の方が社内に置きやすいでしょう。基板サイズ、クーラー高、ドライブベイ、拡張カード長を確認します。起動デバイス、初期データディスク、現実的な交換・増設計画に必要なベイを数えます。

ドライブトレイ、ねじ、ケーブルの付属を確認します。機器全体を分解せずにディスク交換できる空間を残します。掃除と保守ができ、通気口がふさがらず、偶発的な衝撃やケーブル抜けから守れるように設置してください。

UPS

UPS は停電時にサーバーを正常終了する時間を確保します。予想負荷、メーカーの稼働時間情報、Linux 対応のシャットダウン通信を基準に選びます。定格ワット数とバッテリー稼働時間は別々の指標です。

停電中もローカル接続を保つ要件があるなら、ネットワークスイッチも含めます。電池交換を計画し、メーカーの手順で正常終了をテストします。長時間の停電でも社内業務を続けられるとは考えないでください。特定アプリが要求しない限り、ここで挙げた負荷に GPU は不要です。

発注前に、予定部品の横へ根拠を記録します。

ハードウェアを組み立てて確認する

誤った位置のスペーサーは基板裏面に触れ、損傷を招く場合があります。電源を切った状態で型番別のマニュアルに従います。以下は一般的な組み立て順であり、マニュアルの図の代わりではありません。

1. 部品と工具を確認します。ソケットを開く前に、CPU 対応と BIOS の確認を済ませます。保証申請に備え、梱包材と製造番号の記録を保管します。
2. ケースを準備します。基板の穴に合うスペーサーだけを付け、余分なものは外します。ASUS のマザーボード取り付け手順に、余分なスペーサーが危険な理由が示されています。必要なら別体の I/O シールドを取り付けます。
3. CPU を位置合わせマークに従って、力をかけずに装着します。ソケットのラッチ手順に従ってください。メーカーの CPU 取り付け手順は、最初にシステムの電源コードを抜くよう求めています。指定の熱伝導材と方法でクーラーを付け、CPU ファンを接続します。
4. マニュアル指定の最初のスロットにメモリを差し、保持機構が正しく固定されるまで装着します。手が届きにくくなる前に M.2 デバイスを取り付けます。
5. マザーボードと PSU を固定します。起動ドライブとデータドライブを取り付け、データと電源のケーブルを接続します。必要な NIC を取り付けます。
6. マニュアルに従い、基板と CPU の電源、ケースファン、前面パネル配線を接続します。ケーブルをファンから離します。通電前に、緩んだねじ、固定されていないケーブル、差し込み不足のコネクターがないか確認します。

初回起動では電源投入時自己診断（POST）の完了を待ちます。UEFI を開き、検出 CPU、メモリ総量、各ドライブ、ファン動作、温度を確認します。部品が見えない、温度が異常などの問題はソフト導入前に解決します。ファームウェア更新が必要なら、安定した電源で基板メーカーの正確な手順に従います。

メーカーが提供するハードウェア診断と、そのプラットフォームに適したメモリテストを実行します。導入後は代表的な文書群をコピーし、通常の同時作業を試します。エラー、温度、完了時間を自分の受け入れ根拠として記録します。何も動かしていない機器のベンチマークでは、社内業務が成立するかは分かりません。

Ubuntu を導入してファイル共有を稼働させる

社内ファイル構成では、LAN 上に business という認証付き共有を 1 つ公開します。対応ハードウェアに Ubuntu Server 24.04 LTS amd64 を使います。リリースノートには 2029 年 5 月までの保守が記載されています。ネットワーク変更中は手元のコンソールを利用できるようにしてください。

OS を導入しデータストレージをマウントする

Ubuntu から現在の 24.04 サーバーインストールイメージをダウンロードし、USB を作る前に Canonical の署名付きイメージ検証手順に従います。イメージのチェックサムだけでなく、チェックサムの署名も検証します。無関係なダウンロードのハッシュをコピーしないでください。

独立したバックアップディスクは外したままにします。インストーラーを起動し、型番、製造番号、容量で内蔵ディスクを識別します。カスタムストレージで EFI 起動パーティションと OS のルートファイルシステムを起動用 SSD に置きます。空のデータ HDD 2 台でソフトウェア MD RAID1 を作り、ext4 にフォーマットして /srv/business にマウントします。Canonical のストレージ設定手順は MD デバイスの作成とマウントを説明しています。

消去を確定する前に最終構成を確認します。起動 SSD に OS、ミラー化したデータデバイスに /srv/business があり、バックアップディスクは表示されない状態にします。インストール中に個別の管理者を作成します。再起動後に構成を確認します。

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
findmnt --mountpoint /srv/business
cat /proc/mdstat

/srv/business が目的の MD デバイス上の ext4 としてマウントされ、両方のミラー構成員が存在し正常か確認します。初期同期が終わってから受け入れテストを始めます。マウントがなければ停止してください。そのままそのパスにディレクトリを作ると、業務ファイルが起動ファイルシステム上に置かれます。

管理とネットワークアクセスを制限する

ルーターの DHCP 設定でサーバーのアドレスを予約します。例ではサーバーが 192.168.10.10、社内サブネットが 192.168.10.0/24、管理用クライアントが 192.168.10.20 です。実際の値に置き換えます。ルーターの LAN 設定とクライアントのアドレス、ネットマスクを確認してください。/24 はこの例の範囲で、すべての社内ネットワークに当てはまりません。ローカルファイルアクセスに公開 IP や有料 DNS は不要です。

更新を適用し、パッケージをインストールします。

sudo apt update
sudo apt upgrade
sudo apt install samba smbclient restic ufw

遠隔管理が必要なら openssh-server を導入し、管理者の SSH 鍵を設定して別セッションで動作を確認します。最初のログインは開いたままにします。Canonical の OpenSSH 手順には鍵設定と構成チェックが含まれます。SSH 設定を変更するたびに sudo sshd -t を実行し、代わりの鍵ログインが成功するまでパスワード接続を残します。

SSH を使う場合、UFW を有効にする前に最初の許可規則のアドレスと実際の SSH ポートを置き換えます。コンソールだけで管理する場合は、その規則を省きます。Canonical のファイアウォール手順で送信元を限定した接続を説明しています。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 192.168.10.20 to any port 22
sudo ufw allow proto tcp from 192.168.10.0/24 to any port 445
sudo ufw enable
sudo ufw status verbose

管理者の接続を再テストします。ポート 445 はこの SMB ファイルアクセス用です。インターネットルーターで転送しないでください。ゲスト Wi-Fi は社内サービスに到達できない別ネットワークにします。サブネット許可規則だけでは、同じサブネット内の信頼する従業員とゲストを区別できません。

認証付きファイル共有を作る

各従業員に Linux の ID と個別の Samba 認証情報を用意します。Ubuntu の Samba アクセス制御手順では、登録前に Linux アカウントが必要です。ファイル専用の新規従業員アカウント alex なら、次を実行します。

sudo addgroup officefiles
sudo adduser --disabled-password --shell /usr/sbin/nologin alex
sudo adduser alex officefiles
sudo smbpasswd -a alex
sudo mkdir -p /srv/business/team
sudo chown root:officefiles /srv/business/team
sudo chmod 2770 /srv/business/team
sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.before-business
sudoedit /etc/samba/smb.conf

求められたら Alex の Samba パスワードを入力します。無効化した Linux パスワードと nologin シェルで管理者ログインと分離します。sudo には追加しません。従業員ごとにアカウント、グループ所属、Samba 登録を繰り返し、officefiles の作成は 1 回だけ行います。

モード 2770 は所有者とグループにアクセスを許し、他者を拒否します。また setgid ビットにより、新規項目がディレクトリのグループを継承します。Samba の規則と Linux のファイル権限の両方が操作を許可する必要があります。全体設定を残し、この共有を 1 つ追加します。

[business]

    path = /srv/business/team

    browseable = yes

    guest ok = no

    read only = no

    valid users = @officefiles

    force group = officefiles

    create mask = 0660

    force create mode = 0660

    directory mask = 2770

    force directory mode = 2770

@officefiles はグループ構成員にアクセスを限定し、force group は共有操作をそのグループで行います。マスクは新規ファイルとディレクトリの権限を制限します。詳しくは Ubuntu の Samba 設定リファレンスを参照してください。サービスを確認して起動します。

sudo testparm -s
sudo systemctl restart smbd
sudo systemctl status smbd --no-pager

再起動前に設定エラーを解消します。構文検査は Samba が設定を読み込めることを示し、次のクライアントテストがサービスを実際に使えることを示します。

クライアントから検証する

許可された LAN 上の別の Windows PC で、エクスプローラーから \\192.168.10.10\business を開きます。alex と Samba パスワードで認証します。acceptance.txt を作り、短い文を書き、閉じて開き直します。別の従業員を登録し、その認証情報でもチームのテストファイルを編集できるか確認します。

smbclient を導入した Linux クライアントからは、次の方法で接続できます。

smbclient //192.168.10.10/business -U alex

プロンプトでパスワードを入力します。誤った認証情報と未認証ゲストで試し、どちらも読み取りやファイル作成ができないことを確認します。Windows では拒否される ID を試す前に既存共有を切断し、キャッシュされた認証情報を消します。そうしないと、成功したセッションを使い続けている可能性があります。

タイムアウトならサーバーのアドレスと LAN 経路、UFW の送信元とポート規則、smbd の状態を確認します。認証や書き込みが失敗するなら、Samba 登録、id alex、ls -ld /srv/business/team を調べます。グループ所属とディレクトリの所有者を確認してください。ゲストアクセスは無効のままにし、問題解決の近道として誰でも書き込める権限にしないでください。

所有とレンタルの予算を立てる

所有の初期費用を、サーバー 1,500 ドル、UPS 200 ドル、ローカルバックアップ機器 300 ドルと仮定します。これは独立したモデル入力で、前述の例の予算内訳ではありません。コンセントでの平均消費電力を 100 W、電気代を 0.15 ドル/kWh とします。

100 / 1000 × 24 × 365 × 3 × 0.15 = $394.20

消費電力も料金も実測値ではありません。自己管理の両方式に、月 2 時間、時給 25 ドルの管理作業と、独立した遠隔地バックアップの月額 10 ドルを計上します。

レンタル側では別のローカルバックアップ機器を想定していません。独立した遠隔地バックアップは両方式に個別項目があります。

バックアップ、復元、サービスの引き継ぎ

業務ファイルを使い始める前に acceptance.txt と Samba 設定を復元します。既存のファイルシステムと十分な空きがある外付けディスクを個別にマウントし、独立して保護する遠隔地コピーも残します。以下のコマンドはディスクの準備や消去を行いません。

バックアップディスクを /media/business-backup にマウントします。findmnt と lsblk で、サーバー内蔵ストレージのディレクトリではなく、意図した外付けデバイスであることを確認します。restic が共有と設定を読めるよう、特権シェルを開始します。

sudo -i
findmnt --mountpoint /media/business-backup
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS

デバイスを確認後、初期化とバックアップを行います。&& の連結は、マウントがない場合を含め、どこかの処理が失敗すると停止します。

findmnt --mountpoint /media/business-backup &&
restic -r /media/business-backup/restic init &&
restic -r /media/business-backup/restic backup /srv/business /etc/samba &&
restic -r /media/business-backup/restic snapshots &&
restic -r /media/business-backup/restic check

新しいリポジトリの初期化は 1 回だけ行います。Restic が求めるリポジトリパスワードは、社内の認証情報保管場所に別途保存します。Restic のクイックスタート手順はこれらの操作を説明しています。マウント確認に失敗したら停止し、ホストのディスクにリポジトリが作られないようにします。

訓練中はテスト文書を変更しません。同じ root シェルで、そのファイルと Samba 設定だけを新しく空の /srv/restore-check ディレクトリに復元します。選んだ項目に十分な空き容量を確保します。

mkdir /srv/restore-check &&
restic -r /media/business-backup/restic restore latest --target /srv/restore-check --include /srv/business/team/acceptance.txt --include /etc/samba &&
cmp /srv/business/team/acceptance.txt /srv/restore-check/srv/business/team/acceptance.txt &&
cat /srv/restore-check/srv/business/team/acceptance.txt &&
testparm -s /srv/restore-check/etc/samba/smb.conf

exit

Restic の復元手順は復元先と上書き動作を説明しています。cmp で差異がなく、復元した文書が読め、testparm が復元設定を受け入れることを確認します。これはファイルと設定の復旧確認であり、完全な災害復旧ではありません。

ファイルを閉じた後の毎晩のバックアップ、日次 7 世代と週次 4 世代のスナップショット保持、週次のリポジトリ検査、月次の復元訓練を割り当てます。毎晩のバックアップでは約 1 日分の変更が失われ得ます。訓練で復旧時間を測定してください。Restic の保持手順では forget --keep-daily 7 --keep-weekly 4 --dry-run で削除内容を事前確認できます。forget はスナップショット参照を削除し、prune は不要なバックアップデータを削除します。いずれも実行前に試行結果を確認します。保持されたスナップショットは、実行漏れのジョブが動いた証拠にはなりません。

自動化では、root だけが読めるパスワードファイルや認証情報ストアで秘密情報を守り、ジョブ内でマウントを確認し、失敗時は責任者に通知します。ローテーションではジョブ前に正しいディスクを接続し、終了後に外して、遠隔地コピーは独立して維持します。

アカウントとグループの ID、従業員登録の手順を記録します。代替ホストでは Linux と Samba の ID を再作成し、所有権を保持または修正し、ファイルと設定を復元して再度クライアントテストを行います。/etc/samba のバックアップだけでは、別管理の Samba 認証状態は復元できません。

責任者と代行者、更新と再起動の時間帯、UPS の終了手順、空き容量、ミラーの健全性、サービスログ、バックアップ結果の確認事項を引き継ぎます。サービスを受け入れる前に、成功したファイル復元と所要時間を引き継ぎ記録に残します。