Keep Your Metasploit Data Safe: Using msfdb, Workspaces, and Backups

Intro (hook): Metasploit stores valuable reconnaissance and exploitation artifacts — hosts, services, credentials and module loot — inside a PostgreSQL-backed database. Stopping postgresql or closing msfconsole doesn’t delete this data, but careless commands or deleted files will. This guide explains how the Metasploit DB works, practical commands, workspace behavior, and exact backup/export strategies so your engagement data stays recoverable.

1. Quick overview

Metasploit uses PostgreSQL (managed by msfdb on distros like Kali) to persist scan results, creds, loot, and other metadata.

msfconsole is the client; the DB holds the persistent state. Stopping postgresql or quitting msfconsole does not remove data.

Workspaces are logical views inside the same DB. Each workspace isolates a project’s hosts/services/loot but lives in the same underlying database.

2. Start & verify the DB

Commands you’ll use often:

sudo systemctl start postgresql msfdb init msfconsole msf> db_status

msfdb init creates DB/user/config. db_status tells you if msfconsole is connected.

3. Useful DB-backed commands

db_nmap — runs Nmap through Metasploit and stores results.

db_import — import Nmap/XML output into MSF DB.

hosts, services, vulns, creds, loot — inspect DB contents.

db_export -f xml -o /path/file.xml — export the currently active workspace.

workspace -a / workspace — create/select workspaces.

4. What happens when services/processes change

Stop PostgreSQL: data remains on disk; start it again and msfconsole can reconnect.

Quit msfconsole: no data loss; msfconsole is just a client.

Uninstall Metasploit: DB files and ~/.msf4 remain unless explicitly removed.

When data is lost:

Running msfdb reinit or running DROP DATABASE will destroy the DB.

Deleting Postgres data directories (e.g., /var/lib/postgresql/…) or removing ~/.msf4 will erase local loot and cache.

5. Workspaces & exports

db_export exports only the currently selected workspace. If you need per-workspace export files, switch to each workspace and run db_export.

Options:

Per-workspace exports (useful for client handover):

msf> workspace clientA msf> db_export -f xml -a /root/clientA-export.xml

Scripted export for many workspaces:

workspaces=(“default” “clientA” “clientB”) for ws in “${workspaces[@]}”; do msfconsole -q -x “workspace $ws; db_export -f xml -a /root/msf-$ws.xml; exit” done

Full DB backup (all workspaces): use PostgreSQL dump to capture everything in one file:

sudo -u postgres pg_dump -Fc -f /root/metasploit-full.dump

  1. Periodically pg_dump the DB to a secure location (remote or encrypted). This preserves all workspaces.

  2. db_export workspace-level XML exports for client handovers or per-project archives.

  3. Backup ~/.msf4/ (loot, logs) and the Metasploit database.yml config.

Example pg_dump restore commands (high level):

dump

sudo -u postgres pg_dump -Fc -f /root/metasploit-full.dump msf

restore

sudo -u postgres pg_restore -d msf -C /root/metasploit-full.dump

7. Safety tips & best practices

Never run destructive DB commands (msfdb reinit, DROP DATABASE) on a live DB unless you intend to destroy it.

Keep at least one backup copy off the testing host (secure/encrypted).

For team workflows, host Postgres centrally and allow db_connect from authorized machines; secure the DB with proper network and user access controls.

Consider automating nightly pg_dump and rotating backups.

8. Quick recovery checklist

If you suspect missing data:

  1. sudo systemctl status postgresql — confirm Postgres is running.

  2. msfconsole → db_status — confirm connection.

  3. hosts / services / loot — check stored records.

  4. Restore from pg_restore or import the relevant db_export XML if needed.

9. Closing / CTA

Back up your data proactively. If you’d like, I can generate:

a small backup script that runs pg_dump and rotates nightly backups, or

an export script that auto-discovers all workspaces and runs db_export for each.