Active Directory ProActive Directory Pro
Book a demo Free Trial

Database and Retention Settings

AD Audit Pro stores its events in an embedded PostgreSQL database and manages growth with two separate retention windows plus scheduled backups. This page covers what lives on Settings > Database and how each control affects your data.

1. Database

AD Audit Pro ships with an embedded PostgreSQL database. There is nothing to install or license separately. The Database card on the settings page shows storage information plus a usage bar for the drive PostgreSQL lives on.

What is on disk

  • Engine: PostgreSQL (embedded)
  • Database: ADAuditPro
  • Data directory: C:\ProgramData\ActiveDirectoryPro\ADAuditPro\pgsql\data
  • Log directory: C:\ProgramData\ActiveDirectoryPro\ADAuditPro\logs
  • Listen port: localhost:5432
  • Started by: AD Audit Pro service (not a Windows service)

PostgreSQL is not registered as a Windows service. AD Audit Pro starts and stops it via pg_ctl as part of its own service lifecycle, so nothing extra needs to be managed separately.

Disk usage and the space alert

The Database card shows a usage bar for the drive that holds the PostgreSQL data directory. Colors are:

  • Green, under 60% used.
  • Amber, 60% to 79% used.
  • Red, 80% or higher. A warning callout appears on the page.

A background job checks the drive every 30 minutes. When usage crosses 80%, AD Audit Pro raises an alert (visible in Alerts and the bell badge) and emails the address in Settings > Email Server > To Address. The alert only fires on the transition upward; it clears silently when usage drops back below 78%.

Low free space is the leading cause of PostgreSQL PANIC crashes and can interrupt event ingestion. If you routinely sit above 80%, shorten retention (Section 2) or move to a larger drive.

2. Data Retention

Two separate retention windows: one for compliance-oriented audit events, one for the high-volume AD logon events. Logon events are typically ~95% of database row count, so keeping them shorter than compliance events dramatically reduces database size without touching audit history.

Audit events, default 365 days. User, group, computer, OU, GPO, and password changes, plus every Microsoft 365 event. These are the ones compliance regimes usually care about, so the default is one year.

  • User created / deleted / enabled / disabled / modified
  • Group membership changes
  • GPO and OU changes
  • All M365 events (sign-ins, SharePoint, Teams, Exchange, roles)

AD Logon Events, default 90 days. Event IDs 4624 (logon), 4625 (failed logon), 4634 (logoff), and 4647 (user-initiated logoff). Dominated by ambient noise from workstations, so a shorter window is standard.

  • Successful and failed logons from DCs
  • Workstation and member-server logon events
  • Logoff events (4634 and 4647)

How the purge works

  • Runs every 24 hours plus once on service startup.
  • Cutoff is midnight-based. "60 days" means "before midnight on today's date minus 60 days," not "60 days ago to the minute." Restarts on the same day find nothing extra to delete after the first pass, which is what most admins expect.
  • Server-side DELETE. Runs entirely inside PostgreSQL, so it is fast even on millions of rows and doesn't load anything into the app.
  • 0 = Keep forever. Setting either field to zero disables purging for that class of events.

Every run writes a line to the log, so you always know it happened:

  • Retention purge: removed 0 audit events (>365d) and 0 AD logon events (>90d)

Change retention

  1. Go to Settings > Database.
  2. Under Data Retention, pick a window from each dropdown:
    • Audit events: 7, 30, 60, 90, 180, 365, 730, or Keep forever.
    • AD Logon Events: 7, 30, 60, 90, 180, 365, or Keep forever.
  3. Click Save. The next 24-hour purge cycle uses the new windows.

Events older than the window are permanently deleted and can only be recovered from a backup taken before the purge. Shortening retention takes effect on the next daily run.

Sizing rule of thumb

A typical install with default logon-type filters generates roughly:

  • 1,000 workstations, 90-day logon retention, about 2 million rows, about 2 GB on disk.
  • The same fleet with Logon Type 3 (Network) enabled, 10 to 50x more rows.
  • Non-logon audit events (user/group/GPO changes, M365) at 365-day retention, usually well under 1 GB.

3. Backup

Scheduled backups produce an encrypted archive of the PostgreSQL database using pg_dump. Backups can include the master encryption key or leave it out, covered below.

Backup settings

  • Enabled: off by default
  • Schedule: Daily, Weekly, or Monthly
  • Time of day: configurable hour (0-23)
  • Default path: C:\ProgramData\ActiveDirectoryPro\ADAuditPro\backups
  • Retain count: 7 (oldest deleted after)
  • Include master key: on by default

Enable scheduled backups

  1. Go to Settings > Database.
  2. Under Backup, toggle Enable Scheduled Backups.
  3. Set Schedule (Daily / Weekly / Monthly), Time of day, and Backup Path. The path can be a UNC share (e.g. \\backup-server\adaudit) if the service account has write access.
  4. Set Retain to how many backups to keep. Older files past this count are deleted after each successful backup.
  5. Choose whether to Include Master Key (recommended, see below).
  6. Click Save.

Run a backup on demand

  1. Under Backup, click Backup Now.
  2. The backup writes to the configured Backup Path with a timestamped filename. Progress and result appear inline.

About the master key

AD Audit Pro encrypts stored credentials (M365 client secrets, email server passwords, DC connection passwords) with a master key generated on first launch. The key is written to masterkey.bin next to the app.

Include master key (default)

The backup archive contains both the database and the master key. A restore on any machine works out of the box, all stored credentials decrypt cleanly.

Backup without master key

The archive contains only the database. To restore, the same master key must be present on the target machine. Choose this option when the backup destination is untrusted (shared file share, cloud storage) and you keep the key separately, for example in a password manager.

If you back up without the master key and later lose the key, stored credentials cannot be decrypted, you will need to re-enter them after restore. The events themselves are not affected.

4. Restore

Restore replaces the current database with the contents of a backup file. The service pauses ingestion during restore and resumes when it completes.

Restore from a listed backup

  1. Go to Settings > Database.
  2. Under Restore from Backup, pick a file from the dropdown. AD Audit Pro lists every archive found in the configured Backup Path.
  3. Enter the passphrase used when the backup was taken.
  4. Click Restore and confirm.

Restore from a file you provide

  1. Place the backup file in a folder the service account can read (e.g. the Backup Path).
  2. Refresh the Database page. The file appears in the Restore dropdown.
  3. Continue with the steps above.

Restore on a different machine

  1. Install AD Audit Pro on the target machine.
  2. Copy the backup file to a local folder.
  3. If your backup was taken without the master key, copy the source machine's masterkey.bin to the target machine (next to ADAudit.exe) before restoring.
  4. Follow the restore steps above.

Restore is destructive: the current database is overwritten. Take a fresh backup first if there is any chance you will want the current data back.