Storage Server を自分のウェブサイトで使う:画像、ダウンロード、アーカイブ
ウェブサーバーの容量は高価ですが、Storage Server の容量はそうではありません。本記事では、何を外へ出せるのか、ウェブサーバーからどのプロトコルが使えるのか、そしてファイルを安全に訪問者へ届ける方法を解説します。
ウェブサーバーでは、ディスク容量が最も高価な資源です。データベースと PHP のために作られた高速な NVMe SSD 上に置かれており、1 ギガバイト増えるごとに目に見えて高くなります。その一方で、そこにはこの速度をまったく必要としないものが載っています。写真のオリジナル、動画ファイル、ダウンロード用のアーカイブ、古いバックアップです。
Storage Server の費用はその数分の一で、まさにこの負担を引き受けます。本記事では、何を外へ出すのが理にかなっているか、ウェブサーバーからどのプロトコルが機能するか、ファイルを安全に訪問者へ届ける方法、そしてどこに限界があるかを解説します。
外へ出す価値があるもの、ないもの
| ストレージに置くもの | ウェブサーバーに残すもの |
|---|---|
| 画像と動画のオリジナル | サムネイルと切り出し済みのバージョン |
| ダウンロード用アーカイブ、ISO ファイル、PDF のまとまり | CSS、JavaScript、フォント |
| 生データ、エクスポート、ログのアーカイブ | データベース |
| ウェブサイトのバックアップ | ページを表示するたびに必要になるものすべて |
線引きは単純です。読まれる頻度が低く、一度に大きく転送されるものはストレージへ。ページを表示するたびに一緒に読み込まれるものは、速い場所に残します。
Storage Server とは何か、そして何ではないか
Storage Server は、ユーザーアカウントを備えたネットワークストレージです。認証情報で接続し、ファイルを読み書きします。公開アドレスを持つオブジェクトストレージではなく、CDN でもありません。
実際にどういうことかというと、サイトの中で画像をストレージへ直接リンクすることはできません。すべてのアクセスに認証が必要だからです。ウェブサーバーがファイルを取得して中継するか、自分で有効期限付きのダウンロードリンクを生成します。これをきれいに行う方法は、後ほど説明します。
制約のように聞こえますが、利点もあります。アドレスを推測したりリンクを転送したりして、誰かがあなたのファイルを持ち出すことはできません。アクセスは常にあなたのアプリケーション、つまりあなたのルールを通ります。
実際にうまくいく型
手順は 3 つだけです。
- オリジナルはストレージに置きます。一度アップロードしたら、その後はほとんど触りません。
- 派生したバージョンは一度だけ生成し、ウェブサーバーに置きます。サムネイル、切り出した変種、圧縮したバージョンのことです。これらは小さく、しかもページを表示するたびに必要になります。
- ダウンロードはあなたのアプリケーションを通します。小さなスクリプトが権限を確認し、ストレージからファイルを取得して出力します。
これを逆にして、サムネイルをアクセスごとにストレージから取り直すと、遅いウェブサイトができあがります。ファイルごとのネットワーク待ち時間が積み上がり、40 枚の画像があるギャラリーは 40 回待つことになります。
どの用途にどのプロトコルか
| プロトコル | ポート | 向いている用途 | 必要なもの |
|---|---|---|---|
| SMB / CIFS | 445 | ディレクトリとしてのマウント | サーバー上の root 権限 |
| SSHFS | 23 | ディレクトリとしてのマウント、暗号化あり | サーバー上の root 権限 |
| SFTP | 23 | PHP からのアクセス、スクリプト、転送 | 外向きのポート 23 |
| HTTPS 経由の WebDAV | 443 | 共用ホスティング、制限のある環境 | HTTPS だけ |
| rsync | 23 | 大きなディレクトリの同期 | 外向きのポート 23 |
| BorgBackup | 23 | 重複排除付きのバックアップ | 外向きのポート 23 |
最も重要な判断は好みではなく、持っている権限で決まります。自前のサーバーではストレージをディレクトリとしてマウントすれば、どのアプリケーションもそれを意識せずに使えます。その手順は Storage Server をネットワークドライブとしてマウントする で解説しています。
共用ホスティングではroot 権限がないため、マウントは選択肢から外れます。そこではアプリケーションの中から WebDAV か SFTP を使う道になり、ポート 443 が塞がれていることはまずないという理由から、たいていは WebDAV のほうが抵抗が少なくなります。
PHP からのアクセスを設定する
SFTP には純粋な PHP ライブラリで十分で、サーバー側の拡張モジュールは必要ありません。
composer require phpseclib/phpseclib:~3.0
use phpseclib3\Net\SFTP;
$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
throw new RuntimeException('認証に失敗しました');
}
// ファイルをアップロードする
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);
// ファイルを読み込む
$inhalt = $sftp->get('/bilder/2026/original.jpg');
WebDAV なら、組み込みの curl 拡張モジュールだけで足ります。
$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_USERPWD => 'u123456-sub1:' . $passwort,
CURLOPT_TIMEOUT => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);
どちらの例もメインアカウントではなくサブアカウントを使っています。その理由は次の節で説明します。
用途ごとに専用のサブアカウントを
どの Storage Server でも最大 100 個のサブアカウントを作成でき、しかもどのプランでも同じです。それぞれに次のものが付きます。
- そこから外に出られない、専用のホームディレクトリ
- 専用のパスワード
- 専用のプロトコル許可、たとえば SFTP だけを許可して Samba は許可しない、といった設定
ウェブサイトの場合はこうなります。ウェブサーバー用に、SFTP だけが使えて /web しか見えないサブアカウントを 1 つ、バックアップ用に /backup しか見えないものをもう 1 つ。ウェブサーバーが乗っ取られても、攻撃者はバックアップに届きません。そのアカウントはバックアップの存在すら知らないからです。
限界が 1 つあります。サブアカウントには専用の容量枠が付きません。自分のディレクトリの中にとどまりますが、その中でプランの容量をすべて埋めることができます。個々のユーザーを本当に制限したいなら、その役割を引き受けるアプリケーションを前に置く必要があります。Nextcloud と Storage Server を連携する では、まさにこの構成を解説しています。
ダウンロードを安全に配信する
最もよくある間違いは、ユーザー名とパスワードを含むリンクなどで、認証情報をブラウザーに渡してしまうことです。正しいのは、あなたのサーバーが接続を確立してファイルを中継する形です。
<?php
// 何かが起きる前に権限を確認する
if (!nutzer_darf_datei($_GET['id'])) {
http_response_code(403);
exit;
}
$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;
非常に大きなファイルでは、すべてをメモリーに読み込むのではなくブロック単位で読むほうが安全です。そうしないと PHP のメモリー上限に達します。そのためには ob_end_flush() を使い、ファイルを少しずつ出力します。
同時ダウンロードが多く見込まれる場合は、実行中のダウンロードがそれぞれ PHP プロセスを 1 つ占有することも考えておくべきです。一定の規模を超えたら、こうした処理は共用ホスティングの後ろではなく自前のサーバーの後ろに置くものです。
ウェブサイトをストレージにバックアップする
これが最も簡単な入り口で、しかもすぐに効果があります。rsync を使えば変更分だけを転送できます。
rsync -az --delete -e "ssh -p 23" \
/var/www/example.com/ \
u123456-sub2@u123456.storage.kernelhost.net:/backup/web/
重複排除と暗号化を伴うバックアップには BorgBackup のほうが向いており、ストレージ側にネイティブで用意されています。さらにストレージ自体のスナップショットが 2 段目の層として加わります。プランに応じて手動スナップショットが 10、20、30、40 個、加えて同じ数の自動スナップショットが日次、週次、月次の周期で作られます。
同じサーバー上へのバックアップとの違いが、決定的な点です。削除されたり暗号化されたりしたディスクは、ローカルのバックアップも一緒に失わせますが、分離したストレージ上のバックアップは失われません。
始める前に:2 つのスイッチ
カスタマーエリアの Storage Server には「アクセス設定」というボタンがあります。そこで 2 つのことが合っている必要があります。
- 「外部からの到達可能性」がオンになっていること。そうでないと、ウェブサーバーはインターネット経由でストレージに届きません。
- 使いたいプロトコルが許可されていること。SMB なら「Samba」、SFTP と rsync なら「SSH」、HTTPS 経由なら「WebDAV」です。
新しく注文したサーバーでは、これらはすべて有効になっています。セキュリティのために使わないものをオフにする場合は、まさにそれが後になって「もう動かない」の最もよくある原因になることを覚えておいてください。
どのプランが合うか
| プラン | 容量 | サブアカウント | スナップショット | 料金 |
|---|---|---|---|---|
| Storage-1 | 1 TB | 100 | 10 と自動 10 | 9.99 EUR |
| Storage-2 | 5 TB | 100 | 20 と自動 20 | 29.99 EUR |
| Storage-3 | 10 TB | 100 | 30 と自動 30 | 39.99 EUR |
| Storage-4 | 20 TB | 100 | 40 と自動 40 | 69.99 EUR |
すべての Storage Server はドイツに設置されており、FTP、FTPS、SFTP、SCP、Samba、WebDAV、WebDAVs に対応し、rsync と BorgBackup をネイティブで備え、IPv4 と IPv6 を持ちます。初期費用はなく、プリペイド方式で最低契約期間もありません。つまり 1 TB で始めて、後から引っ越しなしで大きくできます。
試算してみましょう。ウェブサーバーで 1 TB の容量を追加すると、事業者によっては月額 9.99 ユーロの何倍もかかり、しかもウェブサイトと同じマシン上に置かれます。隣に用意するストレージは、安いだけでなく分離されています。
よくあるご質問
Storage Server から画像を直接ウェブサイトに埋め込めますか?
ウェブサーバーからはどのプロトコルを使うべきですか?
Storage Server は CDN の代わりになりますか?
サブアカウントはいくつ作成できますか?
サブアカウントごとに専用の容量を割り当てられますか?
アクセスはどのくらい速いですか?
認証情報はブラウザーから見えてしまいますか?
これでウェブサイトのバックアップもできますか?
そのために自前のサーバーは必要ですか?
料金はいくらですか?
2026 KernelHost GmbH。無断複写・転載を禁じます。本ガイドは著作権により保護されております。他のウェブサイトへの掲載は、一部のみの場合や編集を加えた場合であっても、当社の書面による同意なしには認められません。出典の明記とリンクを添えた引用は歓迎いたします。

