On 04/13/2018 12:48 PM, Jonathan Morgan wrote:
> For a system with information stored in a PostgreSQL 9.5 database, in
> which data stored in a table that is deleted must be securely deleted
> (like shred does to files), and where the system is persistent even though
> any particular table likely won't be (so can't just shred the disks at
> "completion"), I'm trying to figure out my options for securely deleting
> the underlying data files when a table is dropped.
>
> As background, I'm not a DBA, but I am an experienced implementor in many
> languages, contexts, and databases. I've looked online and haven't been
> able to find a way to ask PostgreSQL to do the equivalent of shredding its
> underlying files before releasing them to the OS when a table is DROPped.
> Is there a built-in way to ask PostgreSQL to do this? (I might just not
> have searched for the right thing - my apologies if I missed something)
>
> A partial answer we're looking at is shredding the underlying data files
> for a given relation and its indexes manually before dropping the tables,
> but this isn't so elegant, and I'm not sure it is getting all the
> information from the tables that we need to delete.
>
> We also are looking at strategies for shredding free space on our data
> disk - either running a utility to do that, or periodically replicating
> the data volume, swapping in the results of the copy, then shredding the
> entire volume that was the source so its "free" space is securely
> overwritten in the process.
>
> Are we missing something? Are there other options we haven't found? If we
> have to clean up manually, are there other places we need to go to shred
> data than the relation files for a given table, and all its related
> indexes, in the database's folder? Any help or advice will be greatly
> appreciated.
I'd write a program that fills all free space on disk with a specific
pattern. You're probably using a logging filesystem, so that'll be far from
perfect, though.
--
Angular momentum makes the world go 'round.