Re: Records go poof!

Shawn wrote:

We cannot explain why a group of tables ended up completely empty
yesterday.

I don't know your app, but from what information you've provided, this
almost has to be either malicious or, at best, the result of foolhardy
exploration/experimentation. I'm going to assume you've verified that these
tables are, in fact, actually empty.

You can wind up with an empty table during a botched restructure, and index
damage can result in an apparently empty table, but 42 tables at once? It's
hard to fathom how some glitch could be solely to blame.

Someone else please chime in if you thhink I am off base here, but, absent
evidence to the contrary - your customer needs to first and foremost regard
this as a security incident and behave accordingly. Look to the network OS
file access audit logs, if in place. If not in place, put them in place.
If they have not implemented a guaranteed cold backup policy on this data,
they need to at once.

Without cold backups, recovery is difficult, because recovered tables may
individually represent different states of the database if anything was
updated between the start and end of the backup. Hence the above
requirement. For that same reason, they really need to consider recovering
*all* tables from backups, not just the ones which were emptied.

The file sizes reflect the unreclaimed space since the rows were deleted.
The space will be reclaimed slowly as new records are added, or the file
sizes will shrink down after the tables are restructured.

These are the three biggest technical weaknesses of Paradox. Of all
file-shared databases, really. No explicit operational auditing, no
built-in support for read-consistent backups, and (IMHO, worst of all)
direct end user access to the database files.

What to tell your customer? Aside from the likelihood they've got a
(potentially ongoing) security issue, they need to consider an audit of file
access permissions to ensure that access is restricted to legitimate users
only.

A workaround that solves a good deal of the security issues would be to
employ a Terminal Services or similar arrangement, with local profiles on
the servers restricted to only running your runtime app and nothing else -
no CMD, Explorer, etc.

--
Larry DiGiovanni


.

Relevant Pages

  • Re: SQL restore table / rollback / undo table drop without backups?
    ... If your database has been in Full recovery mode since it's ... creation there is a ... we have a database which previously was understood to have backups on ... The database recovery model is Full, but we do not have any bak ...
    (microsoft.public.sqlserver.programming)
  • Re: Backup plan reccomendations for user with ZERO experience.
    ... I have basically ZERO experience using MS SQL Server ... Our database is fairly small we have 7 users with access to the ... First you need to determine which recovery model you want to use. ... should make sure that you have backups a couple of days back in time ...
    (comp.databases.ms-sqlserver)
  • Re: Comments?
    ... recovery has been explained to us. ... export to recreate the database with all users and system settings. ... then why isn't that DBA doing hot backups using shell or ...
    (comp.databases.oracle.server)
  • Re: Copying archivelogs every ten minutes
    ... If you don't use automatic recovery on the Standby database, ... If the other server is not physically offsite then I think the ... following is superior to useing a second server to hold the backups. ...
    (comp.databases.oracle.server)
  • Re: Strategy for backup and restore
    ... > My vb.net app will use database which will be deployed using MSDE on ... > a) I am thinking about Full backup option, ... to start on in disaster recovery situation... ...
    (microsoft.public.sqlserver.msde)