Package level security

[Modesto Vega]

[SNIP]

We are not planning to use version control. Instead, auditing is enabled as a safeguard.

[SNIP]

We've been told that auditing is a very "heavy" process.  So we have steared clear.

We use regular snapshotting via Transfer Project to create clones of the repository at specific points in time (takes less than 10 mins a time).  If we need to recover something, we are able to merge the current state of the repository with the clone as required via queries.  In over 5 years, there hasn't been any significant issue with recovery (including losing over 300K connectors due to some underlying SQL Server problem (beyond our control) on a number of occasions).

If you DO go the auditing route, we'd be very interested in your experiences.

Paolo

Thanks Paolo. There was an ulterior motive for switching auditing on: strange things were happening with the repository, mainly packages being accidentally moved (please note the emphasis). I said “was” because it hasn’t happened since we announced auditing is of.

We will consider switching auditing off and moving to periodic snapshots.

[Geert Bellekens]

[SNIP]

We are not planning to use version control. Instead, auditing is enabled as a safeguard.

[SNIP]

We've been told that auditing is a very "heavy" process.  So we have steared clear.

We use regular snapshotting via Transfer Project to create clones of the repository at specific points in time (takes less than 10 mins a time).  If we need to recover something, we are able to merge the current state of the repository with the clone as required via queries.  In over 5 years, there hasn't been any significant issue with recovery (including losing over 300K connectors due to some underlying SQL Server problem (beyond our control) on a number of occasions).

If you DO go the auditing route, we'd be very interested in your experiences.

Paolo

I have a very similar experience. We take .eap backups every week of all of our production model (semi-automated with a little vbscript)
Whenever there is an issue of lost data we have been able to fix it using the .eap backups.
No auditing as this tends to blow up the database size, and no one ever actually uses the auditing data. It's just there to ease the minds of managers.

Geert

[Marc Vanstraelen]

We used to have auditing on; after 2 years the single table storing the auditing info (T_SNAPSHOT) accounted for some 82% of the total 5.4 Gb volume of our database. So we switched it off some years ago and reduced the database by some 4 GB. Nobody ever complained or asked for auditing info since.