Also when you get in the multi TB data storage the bill gets a little harder to digest in S3.
On Fri, May 15, 2020 at 11:49 Andreas 'ads' Scherbaum <adsm...@wars-nicht.de> wrote: > > > On Fri, May 15, 2020 at 7:52 PM Ravi Krishna <srkrish...@comcast.net> > wrote: > >> >> Why should the backup land in S3, and not local somewhere? >> Any good reason why one should pay for the additional storage and >> transfer costs? >> >> Good question. The key point in my statement was "db of this size". >> >> The problem with local backup is that space is not infinite. If your >> business requires you to >> store backups for say 7 years, storing it locally will be a problem. In >> one large financial >> company I use to work, full backup was used to store old data. >> (except last 30 days where WAL logs were used for a real PIT). We use to >> store full backups >> for about 60 days and then send older backup to an off site storage. >> Nothing is free. >> >> I remember a case where we were requested by business to restore a db of >> a given date two yrs >> prior as they had to look at old data. It took us close to 96 hrs to give >> the users the required database. >> >> S3 storage is ridiculously cheap. Off site storage companies like Iron >> Mountain should find their client base >> ditching them big time. >> > > If your database is running somewhere in the cloud, then yes, that might > make > sense. If your database runs in your own data center, then usually you > also have > disk space available there. Plus a transfer out of your data center will > take time. > > There is no "per se" recommendation to move data to S3. And there might be > additional requirements like data protection laws, encryption requirements > ect. > > -- > Andreas 'ads' Scherbaum > German PostgreSQL User Group > European PostgreSQL User Group - Board of Directors > Volunteer Regional Contact, Germany - PostgreSQL Project > -- T: @Thaumion IG: Thaumion scot...@gmail.com
