We're using similar technique but using SAN instead of NAS. The current approach is shutting down the source Postgres database, clone or snap it to the target server and then start the database back up. On Oracle, I never had to shut down the source, instead I issue alter tablespace begin backup, snap, and alter tablespace end backup to ensure a consistent image. These being/end backup commands, were originally there to place the database in state that you can perform a hot backup while the database is up and running. I think PostgreSQL has similar commands for hot backup - it will be interesting to know if anyone used them to perform a snap or clone while the source is up and running and not compromising database consistency. -- Husam -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx] On Behalf Of Chris Travers Sent: Saturday, July 30, 2005 1:44 PM To: N/A Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: [ADMIN] Question on placing database on a network attached storage N/A wrote: > Hi, > > I'm putting together a mission critical application which will use a > Postgresql database, and I am trying to decide if I should place my > Postgresql database on a network attached storage appliance or on > local disks. Wherever possible, I think that local storage is almost always best as it is a less complex system (hence less can go wrong). However, you will probably get better answers if you tell us what sort of NAS you are looking at using, how it will connect to your system, etc. > > If I place the database on the NAS, it will get "backed up" by the NAS > device's "snap" type of images. That means the NAS will make a copy > of the delta, or difference, between the current version of the files > on it, and the version from the last time the "snap" was done. The > "snap" images will be dumped to tape at some interval of time. > How internally consistant is this snap? I.e. if the file is changed while the snap is being taken, what happens? This behavior may be product-dependnant and has serious ramifications for your data. > I'm concerned about using a "snap" of an open and active database to > restore the database if the need arises. Now, postgresql is pretty > good about keeping checkpoints and recovering, but I'm still concerned > about data integrity, (who knows what state any internal pointers are > in when the "snap is taken), and as my application will need to > archive groups of files that have to be kept together in order for the > data in those files to be meaningful, (a group of files could be in > the process of being archived to the database, the NAS takes a "snap" > when only some of the files have been written in the database, and > then the rest of the files are written in the database). There is > also the question of speed, Network attached storage vs. local disks, > (network speed is pretty good 100 Meg and will be going to 1 Gig in > the future). Personally I think that there are better approaches than NAS for this, but again I am unwilling to say "never use it." > > I suppose I could place the database on the NAS, shutdown the database > when a backup of the database is desired, have Postgresql create the > database re-creation script, let the NAS take it's "snap", and then > bring the database back up. > > Any suggestions, experiences, or observations? Best Wishes, Chris Travers Metatron Technology Consulting ********************************************************************** This message contains confidential information intended only for the use of the addressee(s) named above and may contain information that is legally privileged. If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message immediately thereafter. Thank you. FADLD Tag **********************************************************************
