[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"public:public\u002Fcontent\u002Fdocs\u002Fgetting-started":3},{"slug":4,"title":5,"description":6,"draft":7,"updated":8,"html":9},"getting-started","How access works","What Verestore needs from your storage and why a list-and-read key on one prefix is enough.",false,null,"\u003Ch1>How access works\u003C\u002Fh1>\n\u003Cp>Verestore restores \u003Cstrong>the newest object under a bucket prefix\u003C\u002Fstrong>, for example \u003Ccode>s3:\u002F\u002Facme-backups\u002Forders\u002F\u003C\u002Fcode> (or an Azure Blob container prefix). Your backup job keeps writing \u003Ccode>pg_dump\u003C\u002Fcode> files there (custom format \u003Ccode>-Fc\u003C\u002Fcode> or plain SQL, optionally gzipped). We never write, delete or list anything else.\u003C\u002Fp>\n\u003Cp>The key you give us needs exactly two permissions on that prefix:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Action\u003C\u002Fth>\n\u003Cth>Why\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Ccode>ListBucket\u003C\u002Fcode> (\u003Ccode>ListObjectsV2\u003C\u002Fcode>) limited to the prefix\u003C\u002Ftd>\n\u003Ctd>find the newest backup\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>GetObject\u003C\u002Fcode> on \u003Ccode>prefix\u002F*\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>download it into the isolated run\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>When you add the key, we run a \u003Cstrong>permission check\u003C\u002Fstrong>: we list the prefix and read the first bytes of the newest object, and tell you what we found. The key is then encrypted so that only our orchestrator, the service that starts runs, can open it, and it can never be read back (see \u003Ca href=\"\u002Fsecurity\">Security\u003C\u002Fa>).\u003C\u002Fp>\n\u003Cp>Pick your platform:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Faws-rds\">AWS (RDS and S3)\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fscaleway\">Scaleway\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>S3-compatible stores: \u003Ca href=\"\u002Fdocs\u002Fcloudflare-r2\">Cloudflare R2\u003C\u002Fa>, \u003Ca href=\"\u002Fdocs\u002Fbackblaze-b2\">Backblaze B2\u003C\u002Fa>, \u003Ca href=\"\u002Fdocs\u002Fwasabi\">Wasabi\u003C\u002Fa>, \u003Ca href=\"\u002Fdocs\u002Fovhcloud\">OVHcloud\u003C\u002Fa>, \u003Ca href=\"\u002Fdocs\u002Fdigitalocean-spaces\">DigitalOcean Spaces\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fgoogle-cloud-storage\">Google Cloud Storage\u003C\u002Fa>, and \u003Ca href=\"\u002Fdocs\u002Fcloud-sql-gcs\">Cloud SQL scheduled exports to Cloud Storage\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fazure-blob\">Azure Blob Storage\u003C\u002Fa>, and \u003Ca href=\"\u002Fdocs\u002Fazure-postgres-flexible-backup\">Azure Backup for PostgreSQL Flexible Server\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fneon\">Neon\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fsupabase\">Supabase\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fself-hosted\">Self-hosted PostgreSQL with MinIO or any S3-compatible store\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Why off-site:\u003C\u002Fstrong> provider snapshots and managed backups live inside the provider account they protect, and go with it if the account is closed, compromised or deleted. A dump in storage you control (another account, another provider) is the copy that survives; Verestore proves it restores.\u003C\u002Fp>\n\u003Cp>For S3-compatible stores the signing region follows from the endpoint, so the region field can stay empty. Azure Blob uses its native API, with a read + list SAS token or a service principal holding \u003Cstrong>Storage Blob Data Reader\u003C\u002Fstrong> on the container.\u003C\u002Fp>\n\u003Cp>Automation: \u003Ca href=\"\u002Fdocs\u002Fapi\">API tokens\u003C\u002Fa> for CI and compliance tools, and \u003Ca href=\"\u002Fdocs\u002Fwebhooks\">webhooks, Teams, PagerDuty and Opsgenie\u003C\u002Fa> for alerts.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Recommendation:\u003C\u002Fstrong> use a dedicated prefix (or bucket) per database, and a dedicated key per Verestore target, so revoking one doesn't affect anything else.\u003C\u002Fp>\n",1794290783589]