これらの条件について説明します：

年1回程度のアクセス頻度を想定

これは、保存したデータを読み取ったり、ダウンロードしたりする頻度が年に1回程度という意味です。

例えば：

• 年度末の決算資料のバックアップ
• 年1回の監査で必要になる過去のログデータ
• 法令で保管が義務付けられているが、めったに参照しない文書
• 思い出の写真や動画で、年に1度見返すかどうかというもの

このような「保管はしておきたいが、ほとんどアクセスしない」データに適したストレージクラスです。

最低保存期間365日

これは一度アップロードしたデータを、最低365日間は保存し続けなければならないという制約です。

重要な点：

• 365日以内に削除すると、早期削除ペナルティが発生します
• ペナルティは通常、残り期間分の保存料金を一括で請求されます
• 例：30日で削除した場合、残り335日分の料金を支払う必要がある

なぜこのような制約があるのか

アーカイブストレージは：

• データを長期保存用に最適化している
• 頻繁なデータの出し入れを想定していない
• そのため料金を安く設定できる

つまり、本当に長期保存が必要なデータのみをアーカイブストレージに保存すべきで、頻繁に変更や削除が発生するデータには向いていません。

世代管理の仕組みと容量計算について詳しく説明します。

Hyper Backupの世代管理の仕組み

バックアップの種類

1. 初回フルバックアップ: 1.4TB（圧縮後）
2. 増分バックアップ: 変更・追加されたデータのみ（週10GB）

世代管理ルール（週次4世代、月次2世代）

時系列イメージ:
週1 週2 週3 週4 週5 週6 週7 週8 週9...
[W] [W] [W] [W] [M] [W] [W] [W] [M]...

W: 週次バックアップ（最新4つを保持）
M: 月次バックアップ（最新2つを保持）

容量計算の具体例

2ヶ月間の推移

1ヶ月目:

• 初回: 1.4TB（ベース）
• 週1: +10GB
• 週2: +10GB
• 週3: +10GB
• 週4: +10GB → 月次として保持
• 月末容量: 1.44TB

2ヶ月目:

• 週5: +10GB（週1分を削除）
• 週6: +10GB（週2分を削除）
• 週7: +10GB（週3分を削除）
• 週8: +10GB（週4は月次なので残る）→ 新月次
• 2ヶ月末容量: 1.48TB

定常状態での容量

ベースバックアップ: 1.4TB
週次4世代: 40GB（10GB × 4）
月次2世代: 80GB（40GB × 2）
---
合計: 約1.52TB

重要なポイント

1. 増分の重複について

• 同じファイルが複数回更新された場合、各世代で差分保存
• 例: 100MBのファイルを毎週更新 → 各世代で100MB必要

2. 削除されたファイルの扱い

• 削除情報も世代管理される
• 古い世代では「存在」、新しい世代では「削除済み」として記録

3. 実際の容量変動要因

容量が増える場合:
- 大きなファイルの頻繁な更新
- 多数のファイルの追加と削除の繰り返し

容量が増えにくい場合:
- 新規ファイルの追加が中心
- 既存ファイルの変更が少ない

より効率的な設定案

もし容量を更に抑えたい場合：

オプション1: 世代数削減

週次: 3世代
月次: 1世代
→ 定常容量: 約1.47TB（50GB削減）

オプション2: Smart Recycle

Hyper Backupの「Smart Recycle」機能:
- 古い世代を自動的に間引き
- 直近は密、過去は疎に保持
例: 7日分→4週分→2ヶ月分

コスト影響（Archive利用時）

1.52TB保存時:
- 月額: $1.82
- 年額: $21.84

全復旧時:
- 取得料金: $76（1.52TB × $0.05/GB）

週10GBの増加ペースなら、この世代管理設定で十分な保護レベルを保ちながら、容量増加を最小限に抑えられます。

その通りです！重要な指摘をありがとうございます。

GCS Archiveクラスの制約

最低保存期間365日の制約により、以下の問題が発生します：

早期削除ペナルティ

• 365日以内に削除/上書きすると、365日分の料金が課金される
• 例: 30日で削除しても365日分の料金を支払う必要がある

Hyper Backupとの相性問題

実際の動作:
週1: +10GB → 365日間削除不可
週2: +10GB → 365日間削除不可
週3: +10GB → 365日間削除不可
...
週5: +10GB → 週1を削除したいが、ペナルティ発生！

容量増加の実態

1年後の実際の容量:

初回バックアップ: 1.4TB
週次増分（52週分）: 520GB (10GB × 52)
---
合計: 約1.92TB（世代管理が効かない）

代替案の提案

1. Nearlineクラスの利用（推奨）

• 最低保存期間: 30日
• 世代管理が正常に機能
• 料金比較:

  Archive（世代管理不可）: 1.92TB × $0.0012 = $2.30/月
  Nearline（世代管理可）: 1.52TB × $0.01 = $15.20/月
  

2. バックアップ戦略の変更

Archiveを使う場合の最適化:
- 月次フルバックアップのみ（12世代/年）
- 日次の変更はNAS内で別途保護
- 年間容量: 約1.5TB程度に抑制可能

3. ハイブリッド構成

Nearline: 直近3ヶ月分（頻繁な世代管理）
Archive: 3ヶ月以上前の月次バックアップ
→ Lifecycle管理で自動移行

改訂版おすすめ構成

Nearline + Hyper Backup を推奨します：

理由

1. 世代管理が正常に機能（30日後に削除可能）
2. 総容量を1.52TBに抑制可能
3. 年額コスト: 約$183（Archive使用時の$276より安い）
4. 復旧も高速（Archive比）

設定

Hyper Backup設定:
- ストレージクラス: Nearline
- 週次: 4世代
- 月次: 2世代
- 圧縮: 有効

Archiveの365日制約は、増分バックアップには不向きで、結果的にNearlineの方がコスト効率が良くなります。

世代数を超えたら何が起こるか

設定例：週次4世代の場合

週1: 世代1作成
週2: 世代2作成
週3: 世代3作成
週4: 世代4作成
週5: 世代5作成 → 世代1を自動削除（最古を削除）

保持される世代: 2, 3, 4, 5（常に最新4つ）

削除時の詳細動作

世代1削除時:
1. 世代1のメタデータ（スナップショット情報）削除
2. 世代1でのみ使用されているチャンクを特定
3. それらのチャンクを削除
4. 他の世代でも使用中のチャンクは保持

重要: データの実体（チャンク）は、どこかの世代で
使われている限り削除されない

まさにその通りです！これがHyper Backupの重要なポイントです。

チャンクとスナップショットの関係

2層構造の理解

【データ層】チャンクプール
├── チャンクA（report.docxの初版）
├── チャンクB（report.docxの2版）
├── チャンクC（image.jpgのデータ）
├── チャンクD（movie.mp4の一部）
└── ... 実際のデータの断片

【メタデータ層】スナップショット（世代）
├── 世代1: 「AとCとDを組み合わせるとこの時点の状態」
├── 世代2: 「BとCとDを組み合わせるとこの時点の状態」
└── 世代3: 「BとCとEを組み合わせるとこの時点の状態」

具体的なイメージ

レゴブロックに例えると：

チャンクプール = レゴブロックの箱
- 赤いブロック、青いブロック、黄色いブロック...

スナップショット = 組み立て説明書
- 世代1の説明書: 「赤3個と青2個で車を作る」
- 世代2の説明書: 「赤2個と青3個と黄1個で飛行機を作る」

世代1を削除 = 説明書1を捨てる
→ でも、赤と青のブロックは世代2でも使うので残す

この仕組みのメリット

1. ストレージ効率

10個のファイルのうち1個だけ変更した場合：
- 従来: 10個全部を再保存（10倍の容量）
- Hyper Backup: 変更した1個分のチャンクのみ追加

2. 高速バックアップ

増分バックアップ時：
- 変更されたファイルを検出
- 新しいチャンクのみアップロード
- スナップショット（メタデータ）を更新
→ 転送量最小限

3. 柔軟な世代管理

世代削除時：
- スナップショット削除: 瞬時（メタデータのみ）
- チャンク削除: 参照カウント0のもののみ
- 他の世代に影響なし

GCSでの実際の保存

GCS上の構造：
/hyperbackup-task/
├── chunks/          # 実データ（重い）
│   ├── 00/
│   │   ├── 00a3f2... (実際のデータ片)
│   │   └── 00b5c8...
│   └── ff/
├── metadata/        # スナップショット（軽い）
│   ├── 2025-01-01/  # どのチャンクをどう組み合わせるか
│   ├── 2025-01-08/
│   └── 2025-01-15/

だからArchiveが問題になる理由

Nearlineの場合：
1. 世代1のスナップショット削除 → OK（メタデータは小さい）
2. 不要チャンク削除 → 30日後ならOK

Archiveの場合：
1. 世代1のスナップショット削除 → OK
2. 不要チャンク削除 → 365日制約でNG！
→ チャンクが削除できず蓄積

この2層構造の理解により、なぜNearlineが推奨されるかがより明確になりましたね。スナップショット（世代）の管理とチャンクの管理が分離されているからこそ、効率的なバックアップが可能になっているわけです。

素晴らしい観察です！家族写真という用途を考えると、確かに違った見方ができますね。

メタデータのサイズ

実際の容量

メタデータの構成：
- ファイルパス、名前、属性
- チャンク参照リスト
- タイムスタンプ、権限情報

サイズ目安：
- 1ファイルあたり: 数KB〜数十KB
- 10万ファイルでも: 数GB程度
- 全体の0.1〜0.5%程度

家族写真バックアップの特性

データの特徴

追加パターン：
- 新規写真の追加: 99%
- 写真の削除: ほぼなし
- 写真の更新: なし（写真は変更しない）

チャンクの動き：
- 新規チャンク: 追加のみ
- 既存チャンク: 削除されない
- 重複排除: 同じ写真をコピーした場合のみ

Archiveクラス再評価

あなたの指摘通りの利点

写真バックアップでのArchive：

1. チャンク削除がほぼ発生しない
   → 365日制約の影響なし

2. メタデータは小さい
   → 削除時のペナルティも小さい（数円程度）

3. コスト試算（2TB、年520GB増加）：
   Archive: 
   - 保存: $2.88/月（2.4TB）
   - ペナルティ: ほぼゼロ
   
   Nearline:
   - 保存: $24/月（2.4TB）

推奨構成の見直し

家族写真用：Archive + Hyper Backup

設定：

ストレージ: GCS Archive
バックアップ設定:
- 月次: 12世代（1年分）
- 週次: なし（写真なら月次で十分）
- 圧縮: 無効（JPEGは圧縮済み）

メリット：

• 年額コスト: 約$35（Nearlineの1/5）
• 世代管理のペナルティ: 無視できるレベル
• 長期保存に最適

注意点：

復旧時：
- 取得料金: $0.05/GB
- 全復旧（2TB）: $100
- 部分復旧なら影響小

用途別の最適解

1. 家族写真（追加型データ）

推奨: Archive
理由: 削除がなく、アクセス頻度低い
年額: $35程度

2. 一般的なNASデータ（更新型データ）

推奨: Nearline  
理由: ファイル更新で古いチャンク削除発生
年額: $183程度

3. 作業ファイル（頻繁な更新）

推奨: Standard
理由: 頻繁なアクセスと更新
年額: $480程度

結論

家族写真のバックアップならArchiveが最適です！

あなたの分析は正確で、私の最初の推奨は一般的なケースを想定しすぎていました。写真という「追加のみ」のデータ特性を考慮すると、Archiveの365日制約はほとんど問題になりません。

年額$35で2TBの写真を安全に保護できるのは、非常にコスト効率の良い選択です。

NAS復旧の必要性：統計データに基づく分析

NASハードウェアの故障率

メーカー別の信頼性

「Synologyの故障率はおそらく最も低い」との評価がある一方で、実際の故障事例も報告されています：

• Synology: 一般的に高い信頼性で知られるが、DS916+モデルで問題報告あり
• QNAP: TS-328モデルで「極めて高い故障率」が報告され、2ヶ月で故障した事例も
• HDD故障率: WD Redで8年間で約30%の故障率が報告されている

災害発生確率（日本）

住宅火災

• 年間発生件数: 2022年に約10,780件の住宅火災（放火除く）
• 全火災件数: 2022年に約36,300件の火災
• 発生確率: 日本の世帯数（約5,300万）から計算すると、年間約0.02%（5,000世帯に1件）

地震（東京）

• 首都直下地震の30年以内発生確率：約70%
• ただし、個別住宅への被害確率はさらに低い

落雷

• 年間落雷数：約100万回（日本全体）
• 住宅への直撃確率：極めて低い（0.001%未満）

総合的なNAS復旧リスク評価

復旧シナリオ別の確率

30年間での復旧必要性

1. ハードウェア故障による復旧: 60-80%（ほぼ確実）
2. 災害による完全復旧: 5-15%（可能性あり）
3. 複数回の復旧: 20-30%（HDD交換など）

結論：バックアップ戦略への影響

統計データが示す重要な示唆：

1. ハードウェア故障が最大のリスク

   • 30年で2-3回のHDD交換が必要
   • NAS本体も1回は故障する可能性大

2. 災害リスクは低いが影響大

   • 火災・地震の確率は低い（年0.1%程度）
   • しかし発生時は全データ喪失

3. クラウドバックアップの必要性

   • ハードウェア故障：RAID構成で対応可能
   • 災害対策：オフサイトバックアップが必須

アイオワArchiveの合理性：

• 災害による完全復旧は「30年で1-2回」程度
• 復旧時の転送料（$360）を考慮しても十分安価
• 月額$3.60は「究極の保険」として妥当

この統計分析により、災害対策としてのクラウドバックアップは必須であり、頻度の低さを考慮すればアイオワArchiveの選択は極めて合理的です。

以下では DSM 7.2 + Hyper Backup 4.1（2025年7月時点の最新版） を前提に、いただいた3つの論点を整理します。各価格はすべて USD／GB‑month で、7 月 20 日現在の公式ページを引用しています。

1. Hyper Backup は GCS に「正式対応」しているか

■ 結論

• Hyper Backup に “Google Cloud Storage” という専用プロファイルはありません が、メニューの
  「S3 Storage → Custom Server」 を使えば S3 互換API（XML API）経由で問題なく動作 します。(Synology, SynoForum)
• フォーラムでも AWS・Storj と並んで GCP で稼働中 の報告が多数あります（同エラーが Scaleway で再現した事例では「バケット名を変えたら解決した」との記載）。(SynoForum)

■ 安定接続のチェックリスト

回避策が見つからない場合

1. rclone Container での同期、2) Synology C2 Storage、3) AWS へ移行――の順に検討すると運用実績が多いです。

2. Cloud Sync と Hyper Backup の比較 ― 写真アーカイブ用途なら？

● 写真（追記のみ）に必要な最低限

• 誤削除の伝搬を防ぐ → Cloud Sync を使うなら「一方向（NAS→クラウド）」「ローカル削除をクラウドへ反映しない」を必ず選択。
• 世代管理 は「破損検出」や「ランサム対策」に有効だが、JPEG/HEIF のみで編集しない運用なら必須ではありません。
• プライバシー を重視しファイル名も隠したいなら Hyper Backup が有利。

結論

• 「最安・シンプル」を優先 → Cloud Sync（アップロードのみ）
• 「長期でフォルダ構造と世代も守りたい」 → Hyper Backup を推奨。

3. AWS S3 Glacier Deep Archive vs GCS Archive の最新コスト比較（3 TB を 30 年保存）

差額は月額 ~$1.3、30 年で ~$450。
“人生で 1–2 回しか復旧しない”前提なら AWS がトータル最安。ただし

• 復旧を「すぐ見たい・選んで1枚だけ取り出したい」なら GCS の即時性が大きなメリット。
• 既に 2 TB アップロード済み＆運用が回っているなら、再アップロードの手間と通信コスト も無視できません。

まとめと推奨シナリオ

1. まず Hyper Backup + GCS で再挑戦

   • 上記チェックリスト通り新規バケット＋HMACキーで“バックアップタスク > S3 Storage”を設定。
   • 成功すれば「世代管理 + 圧縮 + 即時取出し」を兼ねたまま、月 4 ドル強で運用可能。

2. 失敗した場合の分岐

   • プライバシー＜コスト → AWS Glacier Deep Archive (+ Hyper Backup) へ移行。
   • コスト＜手間／即時復旧 → GCS + Cloud Sync（Upload‑only）で続行し、必要なら世代管理はローカル Snapshot で補完。

3. 長期増加（17 TB 想定）を見据えるなら

   • 30 年総額は AWS ≒ $6.2 k、GCS ≒ $8.8 k。差額 $2.6 k を「取出し速度」と「再設定の手間」でペイできるかが判断基準。
   • 途中でより安価なストレージ（例：Backblaze B2、Wasabi）へ再移行する柔軟性も確保しておくと安心です。

最後に

• DSM と各パッケージは常に最新へアップデート（S3 接続周りの不具合修正が頻繁に入ります）。
• 年 1 回は 整合性チェック（Hyper Backup の「バックアップ検証」機能）を実行しておくと、30 年後の安心感が段違いです。

ご家族の大切な写真が安全に保管されることを願っています。疑問点があればお気軽にどうぞ！

Synology NASクラウドバックアップ戦略 総合調査レポート

エグゼクティブサマリー

本レポートは、Synology DS220+（2TB使用中）に保存されている家族写真の災害対策バックアップ戦略について、Hyper BackupのGoogle Cloud Storage（GCS）対応状況、Cloud SyncとHyper Backupの機能比較、AWSとGCSのコスト比較を詳細に調査し、最適な解決策を提案するものです。

主要な調査結果

1. Hyper BackupのGCS対応: 実質的に非対応。S3互換API経由での接続は技術的に可能だが、ストレージクラス制御の問題により実用性に欠ける。

2. Cloud Sync vs Hyper Backup: 家族写真バックアップにおいては、Cloud Syncは確実性、Hyper Backupは世代管理機能で優位性を持つ。

3. コスト比較: AWS S3 Glacier Deep Archiveが30年間で約25.5%（$378）安い。

推奨案

状況別推奨案:

• コスト最優先: AWS S3 + Hyper Backup
• 確実性優先: GCS + Cloud Sync（既設定活用）
• バランス重視: AWS S3 + Hyper Backup（新規設定の価値あり）

1. 調査背景と目的

1.1 背景

東京在住のユーザーが、Synology DS220+（2TB使用中）に保存している家族写真を、火災・地震・落雷などの災害から守るためのオフサイトバックアップ戦略を検討。年間約500GB増加し、30年間の長期保存を想定している。

1.2 要件

• データ: 家族写真（追加のみ、削除・更新なし）
• 予算: できるだけ安く
• 復旧頻度: 人生で1-2回程度を想定
• 保存期間: 30年間
• 現在の状況: GCS設定済み、Cloud Sync運用検討中

1.3 調査目的

1. Hyper BackupのGCS対応状況の確認
2. Cloud SyncとHyper Backupの機能比較
3. AWSとGCSのコスト・機能比較
4. 最適なバックアップ戦略の提案

2. Hyper BackupのGoogle Cloud Storage対応状況

2.1 調査結果概要

結論: Hyper BackupはGCSに実質的に非対応

2.2 技術的詳細

2.2.1 S3互換API経由での接続

GCSはS3互換のXML APIを提供しており、理論上はHyper Backupから接続可能です。しかし、実際の運用では以下の問題が発生します：

主要な問題点:

1. ストレージクラス制御の不具合: バケットのデフォルトストレージクラスをArchiveに設定しても、Hyper BackupはStandardクラスでアップロードしてしまう
2. 認証エラーの頻発: 正しいHMAC認証情報を設定しても「バックアップ先の共有フォルダにアクセスする権限がありません」エラーが発生
3. 署名バージョンの非対応: Hyper Backupが対応する署名バージョンとGCSの要求が一致しない場合がある

2.2.2 コミュニティでの報告事例

Synologyコミュニティフォーラムでの調査により、以下の事実が判明：

• 成功事例: 一部のユーザーがStandardストレージクラスでの接続に成功
• 失敗事例: Archiveストレージクラスでの運用は困難
• 回避策: 現時点で確実な回避策は存在しない

2.2.3 DSMバージョン別対応状況

• DSM 7.0以降: S3互換APIサポートは改善されているが、GCS特有の問題は解決されていない
• DSM 6.x: より多くの互換性問題が報告されている

2.3 代替案としてのCloud Sync

Hyper BackupがGCSに対応していない一方で、Cloud SyncはGCSにネイティブ対応しており、確実に動作します。

Cloud Syncの特徴:

• GCSの全ストレージクラスに対応
• 認証問題なし
• リアルタイム同期機能
• ただし、世代管理機能なし

3. Cloud SyncとHyper Backup機能比較分析

3.1 基本機能比較

3.2 Cloud Sync詳細分析

3.2.1 主要機能

• リアルタイム同期: ファイル変更を即座に検知し、クラウドに同期
• 双方向同期: NASとクラウド間での双方向データ同期が可能
• 暗号化機能: データ暗号化に対応（ファイル名は暗号化されない）
• スケジュール機能: 指定時間での同期実行が可能

3.2.2 制限事項

• 世代管理なし: 過去のバージョンは保持されない（クラウド側のバージョニング機能に依存）
• 1アカウント1接続: 1つのクラウドアカウントにつき1つの接続のみ
• 競合処理: 同時変更時はローカル変更を優先

3.2.3 家族写真バックアップでの適性

適している点:

• 追加のみのデータ（家族写真）に最適
• リアルタイム同期で最新状態を維持
• 設定が簡単で確実に動作

注意点:

• 誤削除時の復旧が困難（世代管理なし）
• ファイル名が暗号化されない

3.3 Hyper Backup詳細分析

3.3.1 主要機能

• 包括的バックアップ: 共有フォルダ、パッケージ、LUNの全てをバックアップ
• 世代管理: 最大65,535個のバージョンを管理
• ブロックレベル増分: 変更されたブロックのみをバックアップ
• 完全暗号化: AES-256によるクライアント側暗号化

3.3.2 世代管理機能

• スマートバージョン管理: 古いバージョンの自動削除
• 柔軟なローテーション: 日次→週次→月次の段階的保持
• クロスバージョン複製: ストレージ効率を最大化

3.3.3 家族写真バックアップでの適性

適している点:

• 世代管理により過去の状態に復旧可能
• 完全暗号化でセキュリティ確保
• 長期保存に最適化された設計

注意点:

• 復旧時にHyper Backupが必要
• 設定変更時は新規タスク作成が必要
• GCSとの互換性問題

3.4 家族写真バックアップにおける推奨度

3.4.1 Cloud Syncが適している場合

• リアルタイム同期が必要: 常に最新状態を維持したい
• ファイルを通常形式で保持: 復旧時の簡便性を重視
• 設定の簡便性: 確実に動作する設定を求める
• GCSを確実に使用: 既にGCS設定済みで変更したくない

3.4.2 Hyper Backupが適している場合

• 世代管理が重要: 過去の状態への復旧が必要
• 完全な暗号化: セキュリティを最重視
• 長期保存が主目的: アーカイブ用途での使用
• AWS S3を使用: 確実な動作が保証されている

4. AWSとGCSコスト・機能比較詳細分析

4.1 2025年最新料金体系

4.1.1 Google Cloud Storage (us-central1)

• Archive Storage: $0.0012/GB/月
• データ取得料金: $0.05/GB
• オペレーション料金: $0.05/1,000リクエスト（Class A/B共通）
• 最小保存期間: 365日

4.1.2 AWS S3 Glacier Deep Archive

• ストレージ料金: $0.00099/GB/月
• データ取得料金:
  • Standard: $0.02/GB
  • Bulk: $0.0025/GB
• リクエスト料金:
  • Standard: $0.03/1,000リクエスト
  • Bulk: $0.00/1,000リクエスト
• 最小保存期間: 180日

4.2 30年間コスト詳細分析（3TB想定）

4.2.1 保存コスト計算

前提条件:

• 初期容量: 2TB
• 年間増加: 500GB
• 30年後の総容量: 2TB + (500GB × 30年) = 17TB
• 平均容量: 約3TB（計算簡略化）

保存コスト比較:

• GCS Archive: $0.0012 × 3,072GB × 360ヶ月 = $1,326.59
• AWS Deep Archive: $0.00099 × 3,072GB × 360ヶ月 = $1,094.68
• 差額: $231.91（AWS有利）

4.2.2 災害復旧時コスト（3TB一括取得）

GCS Archive:

• データ取得: $0.05 × 3,072GB = $153.60

AWS Deep Archive:

• Standard取得: $0.02 × 3,072GB = $61.44
• Bulk取得: $0.0025 × 3,072GB = $7.68

4.2.3 30年総コスト（保存 + 1回復旧）

• GCS Archive: $1,326.59 + $153.60 = $1,480.19
• AWS Deep Archive (Standard): $1,094.68 + $61.44 = $1,156.12
• AWS Deep Archive (Bulk): $1,094.68 + $7.68 = $1,102.36

結論: AWSが約25.5%（$377.83）安い

4.3 ユーザー提供データとの比較分析

4.3.1 ユーザー計算値

• GCS: $1,806（保存$1,296 + 復旧$510）
• AWS: $1,129（保存$1,069 + 復旧$60）

4.3.2 差異の原因分析

復旧コストの差異:

• ユーザー: $510 vs 実際: $153.60
• 原因: 複数回復旧を想定、または古い料金体系を使用

保存コストの差異:

• 軽微な差異は料金改定や計算方法の違いによる

4.4 機能面での比較

4.4.1 可用性・信頼性

Google Cloud Storage:

• SLA: 99.95%（Archive）
• 11 9's（99.999999999%）の耐久性
• グローバルネットワーク

AWS S3 Glacier Deep Archive:

• SLA: 99.9%
• 11 9's（99.999999999%）の耐久性
• 世界最大のクラウドインフラ

4.4.2 取得時間

GCS Archive:

• 取得時間: 12時間以内

AWS Glacier Deep Archive:

• Standard: 12時間以内
• Bulk: 48時間以内（最安）

4.4.3 Synology製品との互換性

GCS:

• Cloud Sync: ✅ 完全対応
• Hyper Backup: ❌ 実質非対応

AWS S3:

• Cloud Sync: ✅ 完全対応
• Hyper Backup: ✅ 完全対応

4.5 隠れたコスト要因

4.5.1 最小保存期間

GCS Archive: 365日

• 早期削除時は365日分の料金が発生

AWS Deep Archive: 180日

• 早期削除時は180日分の料金が発生

4.5.2 オペレーション料金

家族写真のバックアップでは、オペレーション回数は限定的なため、両社とも実質的な影響は軽微。

4.5.3 ネットワーク料金

両社とも、アップロード時のネットワーク料金は無料。ダウンロード時のみ課金されるが、災害復旧時の1-2回程度であれば影響は限定的。

5. 総合推奨案

5.1 状況別推奨戦略

5.1.1 【推奨】コスト最優先案: AWS S3 + Hyper Backup

適用条件: 30年間で$378の節約を重視する場合

メリット:

• 30年間で約25.5%（$377.83）のコスト削減
• 世代管理機能による高い復旧柔軟性
• AES-256完全暗号化によるセキュリティ確保
• Synologyとの確実な互換性

デメリット:

• 新規設定が必要（GCS設定が無駄になる）
• 復旧時の操作がやや複雑

実装難易度: 中（新規設定が必要）

5.1.2 確実性優先案: GCS + Cloud Sync

適用条件: 既設定を活用し、確実な動作を重視する場合

メリット:

• 既にGCS設定済みで即座に運用開始可能
• 確実な動作保証（実績豊富）
• リアルタイム同期による最新状態維持
• 復旧時の操作が簡単（通常ファイル）

デメリット:

• 30年間で約$378のコスト増
• 世代管理機能なし
• ファイル名暗号化なし

実装難易度: 低（設定済み）

5.1.3 最高信頼性案: ハイブリッド構成

適用条件: コストより信頼性を最重視する場合

構成: AWS S3 + Hyper Backup + GCS + Cloud Sync

メリット:

• 複数クラウドによるリスク分散
• 片方に問題があっても安心
• 異なる復旧方式の選択肢

デメリット:

• コストが約2倍
• 管理が複雑
• 設定・運用の手間が増加

実装難易度: 高

5.2 最終推奨案

結論: AWS S3 + Hyper Backupを推奨

理由:

1. コスト効率: 30年間で$377.83の節約は大きな価値
2. 機能性: 世代管理機能は家族写真の長期保存に有効
3. 信頼性: AWS S3とHyper Backupの組み合わせは実績豊富
4. 将来性: AWSの継続的な価格競争力とサービス改善

ただし、以下の場合はGCS + Cloud Syncも有効:

• 設定変更の手間を避けたい
• 月額$0.63の差額を許容できる
• リアルタイム同期を重視する

6. 実装ガイド

6.1 AWS S3 + Hyper Backup実装手順

6.1.1 事前準備

1. AWSアカウント作成

   • AWS公式サイトでアカウント作成
   • 請求情報の設定

2. S3バケット作成

   • リージョン: us-east-1（最安）
   • バケット名: 一意の名前を設定
   • デフォルトストレージクラス: Glacier Deep Archive

3. IAMユーザー作成

   • S3フルアクセス権限を付与
   • アクセスキーとシークレットキーを取得

6.1.2 Hyper Backup設定

1. パッケージインストール

   • DSMのパッケージセンターからHyper Backupをインストール

2. バックアップタスク作成

   • バックアップ先: S3カスタムサーバー
   • サーバーアドレス: s3.amazonaws.com
   • バケット名: 作成したバケット名
   • アクセスキー・シークレットキーを入力

3. バックアップ設定

   • 対象フォルダ: 家族写真フォルダを選択
   • 暗号化: 有効（推奨）
   • スケジュール: 週1回（推奨）
   • バージョン管理: 52世代（1年分）

6.1.3 初回バックアップ実行

• 初回は時間がかかるため、夜間実行を推奨
• 進捗状況を定期的に確認

6.2 GCS + Cloud Sync実装手順（既設定活用）

6.2.1 Cloud Sync設定

1. パッケージインストール

   • DSMのパッケージセンターからCloud Syncをインストール

2. 接続作成

   • クラウドプロバイダー: Google Cloud Storage
   • 既存のGCSアカウントで認証

3. 同期設定

   • ローカルパス: 家族写真フォルダ
   • リモートパス: GCSバケット内のフォルダ
   • 同期方向: 単方向アップロード
   • 暗号化: 有効（推奨）

6.2.2 初回同期実行

• リアルタイム同期を有効化
• 初回同期の完了を確認

6.3 運用・保守ガイド

6.3.1 定期確認項目

1. バックアップ状況確認（月1回）

   • バックアップタスクの実行状況
   • エラーログの確認
   • ストレージ使用量の確認

2. 復旧テスト（年1回）

   • 小規模なファイルでの復旧テスト
   • 復旧手順の確認・更新

3. コスト確認（四半期毎）

   • クラウドストレージの請求額確認
   • 予算との比較

6.3.2 トラブルシューティング

よくある問題と対処法:

1. バックアップエラー

   • ネットワーク接続の確認
   • 認証情報の再確認
   • ストレージ容量の確認

2. 同期エラー

   • ファイル権限の確認
   • ファイル名の文字制限確認
   • 同期対象フォルダの確認

3. コスト超過

   • ストレージクラスの確認
   • 不要なデータの削除
   • バックアップ頻度の見直し

7. 結論

7.1 調査結果まとめ

本調査により、以下の重要な事実が明らかになりました：

1. Hyper BackupのGCS対応: 技術的には可能だが、ストレージクラス制御の問題により実用的ではない
2. 機能比較: Cloud Syncは確実性、Hyper Backupは世代管理で優位
3. コスト比較: AWS S3が30年間で約25.5%安い
4. 総合評価: AWS S3 + Hyper Backupが最適解

7.2 最終推奨案

第1推奨: AWS S3 Glacier Deep Archive + Hyper Backup

• 30年間で$377.83の節約
• 世代管理機能による高い復旧柔軟性
• 確実な動作保証

第2推奨: GCS Archive + Cloud Sync（現状維持）

• 設定済みで即座に運用開始可能
• 確実な動作
• 月額$0.63の追加コストは許容範囲

7.3 実装タイムライン

AWS S3移行を選択する場合:

• Week 1: AWSアカウント作成、S3設定
• Week 2: Hyper Backup設定、テスト実行
• Week 3: 初回フルバックアップ実行
• Week 4: 運用開始、GCS設定の無効化

GCS継続を選択する場合:

• Week 1: Cloud Sync設定、初回同期
• Week 2: 運用開始

8. よくある質問（Q&A）

Q1: 本当にHyper BackupはGCSに対応していないのか？

A: 技術的には接続可能ですが、以下の理由で実用的ではありません：

• ストレージクラスがArchiveに設定されない（Standardでアップロードされる）
• 認証エラーが頻発する
• Synologyコミュニティでも多数の問題報告がある
• 確実な回避策が存在しない

現時点では、GCSを使用する場合はCloud Syncの利用を強く推奨します。

Q2: Cloud Syncのミラーリングで十分か？世代管理は本当に必要か？

A: 家族写真のバックアップにおいては、以下の観点で評価できます：

世代管理が有効な場面:

• 誤削除やファイル破損からの復旧
• 過去の特定時点の状態に戻したい場合
• ランサムウェア等の攻撃からの復旧

Cloud Syncで十分な場面:

• 追加のみのデータ（家族写真の特性）
• 誤操作のリスクが低い環境
• シンプルな運用を重視

家族写真は「追加のみ」という特性があるため、Cloud Syncでも十分な場合が多いですが、長期保存（30年）を考慮すると、世代管理機能があると安心です。

Q3: 月額差$0.63のために、AWSに乗り換える価値はあるか？

A: 以下の要因を総合的に判断することを推奨します：

乗り換えを推奨する場合:

• 30年間で$377.83の節約は大きな価値
• 世代管理機能を活用したい
• より確実なバックアップ環境を構築したい

現状維持を推奨する場合:

• 設定変更の手間を避けたい
• 月額$0.63の差額を許容できる
• 既にGCSで安定運用している

判断基準: 設定変更の手間を時給換算した場合、数時間の作業で30年間$377.83の節約になるため、コストパフォーマンスは高いと言えます。

Q4: 他に考慮すべき点はあるか？

A: 以下の点も検討することを推奨します：

技術的考慮点:

• 復旧テスト: 年1回は実際の復旧テストを実施
• ネットワーク帯域: 初回バックアップ時の帯域制限
• ストレージ容量: 年間500GB増加の前提が変わる可能性

運用面の考慮点:

• 料金変動: クラウドサービスの料金は変動する可能性
• サービス継続性: 30年間のサービス継続性
• 技術進歩: より良いソリューションの登場可能性

リスク管理:

• 単一障害点: 1つのクラウドサービスに依存するリスク
• アカウント管理: 長期間のアカウント管理体制
• 復旧スキル: 復旧作業を実行できる人材の確保

Q5: ハイブリッド構成は本当に必要か？

A: 一般的な家庭用途では過剰ですが、以下の場合は検討価値があります：

ハイブリッド構成が有効な場合:

• 絶対に失えないデータ（代替不可能な家族写真等）
• 予算に余裕がある
• 複数のクラウドサービス管理が苦にならない

単一クラウドで十分な場合:

• 一般的な家庭用途
• 管理の簡素化を重視
• コストを抑えたい

推奨: まずは単一クラウド（AWS S3またはGCS）で運用を開始し、必要に応じてハイブリッド構成を検討することを推奨します。

9. 付録

9.1 参考資料

• Synology公式ドキュメント: Hyper Backup、Cloud Sync
• AWS S3料金表（2025年最新）
• Google Cloud Storage料金表（2025年最新）
• Synologyコミュニティフォーラム調査結果

9.2 用語集

• Archive Storage: 長期保存用の低コストストレージクラス
• 世代管理: 複数のバックアップバージョンを保持する機能
• 増分バックアップ: 変更部分のみをバックアップする方式
• ブロックレベル増分: ファイル内の変更ブロックのみをバックアップ

9.3 連絡先

本レポートに関するご質問やご相談は、Synologyコミュニティフォーラムまたは各クラウドサービスのサポートまでお問い合わせください。

レポート作成日: 2025年7月20日
調査期間: 2025年7月20日
対象システム: Synology DS220+, DSM 7.x
調査範囲: Hyper Backup, Cloud Sync, AWS S3, Google Cloud Storage

Google Cloud Storage
Google Cloud Storage Nearline Storage Classは頻繁に変更されないデータ用に設計されているため、ファイルの編集や削除は早期削除料金を引き起こす可能性があります。詳細はGoogle Storageの価格ウェブサイトを参照してください。

ファイルが同期できない状況
単一のファイルのサイズが5 TBを超えています
フォルダまたはファイルパスに文字 * ? # [ ] \r \n が含まれています
ファイルまたはフォルダ名が空白です
フォルダまたはファイルパスが1,024文字を超えています
Cloud SyncはGoogle Driveの共有アイテム、コンピュータ、およびショートカット内のファイルの同期をサポートしていません
Google Docs（gdoc、gdraw、gjamなどを含む）はデフォルトで同期されないようにフィルタリングされています。これらのファイルを同期するには、同期方向をリモートの変更をダウンロードのみに設定し、タスクリスト > 設定でMicrosoft Office形式への変換を有効にしてください。これにより、ローカルでファイル名を変更した際に、Synology NASとパブリッククラウドの両方で発生する可能性のある誤削除を防ぎます
その他の制限
Google Cloud Storageにアップロードする際、Cloud Syncはオブジェクトバージョニングを有効にしません。