共有ボリュームとバックアップ

ボリュームは、ドライブの下にある API のディスクです（/v1/volumes）。ドライブもボリュームであり、その ID は vol-… です。ボリュームにしかできないのが共有ボリュームで、複数のサンドボックスが同時にマウントし、それぞれに書き込みを許すかどうかを決められるファイルシステムです。

共有ボリューム

glac volumes create --name team --shared
glac volumes attach team web:/team
glac volumes attach team worker:/team --read-only
glac volumes detach team worker

API では、{"name": "team", "shared": true} を付けた POST /v1/volumes と、サンドボックスの作成時や変更時の volumes: [{path, volume, read_only}] を使います。Python では glac.volumes.create(name="team", shared=True) と VolumeMount("/team", vol) です。

• マシンは、共有ボリュームを、それをマウントするサンドボックスに NFS で提供します。サンドボックスはボリュームと同じマシン上になければなりません（409 not_on_one_machine）。ただし、まだどのサンドボックスも使っていないボリュームは、リージョン内で、最初にマウントするサンドボックスのマシンへ移ります。共有ボリュームを提供しないマシンは 503 not_served_here を返します。
• size_bytes を指定しなければ、ボリュームは 64 GiB まで、またはプランで許される最大サイズの方が小さければそこまで大きくなれます。使う領域はサイズではなく、書き込まれたものの分です。
• サンドボックス内のプロセスが使っているボリュームのデタッチは、?force=true を付けない限り拒否されます（409 mount_in_use）。アタッチ中のボリュームや、スナップショットの取得に含まれたボリュームは削除できません（409 volume_in_use）。
• ボリュームはドライブと合わせてプロジェクトが保持できる量に数えられ、保持するものはドライブが保持するものと同じく課金されます。ドライブの仕組みを参照してください。

1 つのサンドボックスが持ち、マシン間を移動するディスクには、ドライブを使ってください。

バックアップ

バックアップは、ある瞬間のボリューム（ドライブも可）のコピーで、オブジェクトストアに保持され、プロジェクトの暗号鍵で暗号化されます。ドライブのバージョンであるドライブのスナップショットとは違い、バックアップはそれ自体が独立したコピーで、それだけからボリュームを作ることができ、元のボリュームより長く残ります。ボリュームのバックアップは増分です。それぞれ、前回のバックアップ以降に変わったブロックだけを送って保持し、残りは前回のものを指します。バックアップは期限が来るか削除されるまでプロジェクトの一覧に残り、元のボリュームがどうなっていても、そこから新しいボリュームを作れます。バックアップは、呼び出しによって、ボリュームのルールに従って毎日、またはデータを保持するサービスの新しいバージョンがインスタンスを置き換える前に取得されます（reason は manual、daily、before_version）。

glac backups create data --expires-in-days 7    # prints the backup's id
glac backups ls --volume data
glac backups restore bak-0123456789abcdef --name data-back

バックアップは、オブジェクトストアがすべてを受け取るまでは making、その後は ready です。作成できなかったバックアップは failed になります（failure に理由が示されます）。ボリュームは準備ができたバックアップからしか作れません（作成中は 409 backup_not_ready、失敗後は 409 backup_unusable）。consistency は取得方法を示します。frozen（コピーの間ファイルシステムが静止していた）か crash（電源が落ちた瞬間のディスクと同じ）です。バックアップを作るのは、ディスクをオブジェクトストアにコピーするマシンだけで、それ以外では呼び出しは 409 not_copied を返します。

バックアップから作ったボリュームは、そのバックアップを示し（from_backup）、バックアップ全体が戻るまでは restoring、その後は ready になり、それまではマウントできません。バックアップのリージョンのマシンがすぐに作成を拒否した場合（ディスクが満杯、アカウントにそのマシン上の空きがない、到達できない）は、オブジェクトストアにコピーする次のマシンに回され、ボリュームの placement_refusals が、拒否したマシンを問い合わせた順に、それぞれの拒否コードとともに挙げます（最初に問い合わせたマシンが作成した場合は null）。すべてのマシンが拒否すると、呼び出しは同じリストとともに 503 no_capacity を返します。配置先のマシンで復元できない場合、コントロールプレーンは同じ ID で、バックアップのリージョンの別のマシンにもう一度作成します。そのとき restore_attempt は 2 になり、first_failure が最初の試行に失敗した理由を示します。2 回目も失敗すると、ボリュームは failed のままとなり、削除しかできません。

SDK、コマンドライン、MCP サーバーには、これらすべての呼び出しがあります。Python、TypeScript、Go、Rust、Java、コマンドライン、MCP サーバーを参照してください。

**料金。**ボリュームの複数のバックアップが必要とするブロックは 1 回だけ保持され、そのうち最も古いバックアップで 1 回だけ課金されます。それが削除されると、次のバックアップで課金されます。つまり、バックアップの stored_bytes が課金の基準で、オブジェクトストアが（圧縮して）保持するバイトのうち、そのバックアップが必要とし、同じボリュームのそれより古いバックアップが必要としないものです。own_bytes は削除すると減る量で、同じボリュームのほかのどのバックアップも必要としないもの、shared_bytes は、そのバックアップが必要とし、ほかのバックアップも必要とするものです。バックアップは、準備ができた時点から削除されるか期限が来るまで、スリープ中のサンドボックスが保持するものと同じ料金（1 GB-月あたり $0.02）で、1 分ごとに計上されて課金されます。作成中や失敗したバックアップに料金はかかりません。GET /v1/billing は、その計測項目のうちバックアップの分を示し（state の行の backups_gb_hours）、GET /v1/usage は任意の期間について報告します。kind=backup（glac usage --kind backup）、group_by=backup（backup_id ごとに 1 グループ）、backup_id=bak-…（元のボリュームがどうなっていても、1 つのバックアップ）です。バックアップが保持するものは、利用上限額や残高不足では止められず、期限が来るか削除されるまで数えられ続けます。未払いのあるアカウントでも、データを取り戻すために、バックアップの一覧表示と、バックアップからのボリュームの作成はできます。新しいバックアップは取れません。