Thread: conditional backup
Hi, I need to take backup of my postgresql DB, but not all records from a few tables. My DB contains more than 700 tables, out of which 15 tables i need to take this conditional backup Example: Table: C_order I need to take backup from table C_order where "period=2009" and "org <> A" This is done to improve performance there by deleting all non-org records for old period from org A's server. Expecting ur feedbacks Thanks in advance!!! -- View this message in context: http://old.nabble.com/conditional-backup-tp29180107p29180107.html Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
suhailck <suhailck@gmail.com> wrote: > I need to take backup of my postgresql DB, but not all records > from a few tables. You can exclude particular tables from a database backup using the -T option (which can be included multiple times). You can dump just the schema for particular tables with the -s and -t switches. You can use the \copy command in psql to copy out selected rows using syntax like: \copy (select * from C_order where period=2009 and org <> 'A') to C_order.data You should be able to wire something together from those pieces. -Kevin
This isn't exactly a Postgres question, but I hope someone in the community has solved it. I want to encrypt some data in Postgres that arrives from Apache. How do you store an encryption key in such a way thatApache CGIs can get it, but a hacker or rogue employee who manages to access the machine can't find out the encryptionkey? Thanks, Craig
Kris, [Replying to list, too.] On 7/16/10 10:14 AM, Kris Deugau wrote: > Craig James wrote: >> This isn't exactly a Postgres question, but I hope someone in the >> community has solved it. >> >> I want to encrypt some data in Postgres that arrives from Apache. How >> do you store an encryption key in such a way that Apache CGIs can get >> it, but a hacker or rogue employee who manages to access the machine >> can't find out the encryption key? > > Short answer: You don't. > > Longer answer: You can tie things up with public-key encryption so that > a different system can retrieve the data, but the system that put it in > can't because it only has the public (encryption) key, not the private > (decryption) key. > > Even that isn't safe from a rogue employee - what if that rogue is your > seniour sysadmin with full root access on all your systems? If we assume no escalation of priviliges, that is, Apache stays apache and users can't escalate to root, what then? This must be a solved problem. Credit-card numbers are required to be encrypted by law. It wouldn't make sense for themto be encrypted but then find that the password is sitting around where anyone can find it. There must be any numberof Postgres users who store encrypted credit card numbers and other personal data. How do they solve this problem? Craig
On Fri, Jul 16, 2010 at 10:26 AM, Craig James <craig_james@emolecules.com> wrote: > On 7/16/10 10:14 AM, Kris Deugau wrote: >> >> Craig James wrote: >>> >>> This isn't exactly a Postgres question, but I hope someone in the >>> community has solved it. >>> >>> I want to encrypt some data in Postgres that arrives from Apache. How >>> do you store an encryption key in such a way that Apache CGIs can get >>> it, but a hacker or rogue employee who manages to access the machine >>> can't find out the encryption key? >> >> Short answer: You don't. >> >> Longer answer: You can tie things up with public-key encryption so that >> a different system can retrieve the data, but the system that put it in >> can't because it only has the public (encryption) key, not the private >> (decryption) key. >> >> Even that isn't safe from a rogue employee - what if that rogue is your >> seniour sysadmin with full root access on all your systems? > > If we assume no escalation of priviliges, that is, Apache stays apache and > users can't escalate to root, what then? > > This must be a solved problem. Credit-card numbers are required to be > encrypted by law. It wouldn't make sense for them to be encrypted but then > find that the password is sitting around where anyone can find it. There > must be any number of Postgres users who store encrypted credit card numbers > and other personal data. How do they solve this problem? Bruce has a presentation on this subject: http://momjian.us/main/writings/pgsql/securing.pdf Although, I don't know if it has an illustration that exactly matches your problem. -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lapug