Duplicator Pro writes package metadata to wp_duplicator_packages and keeps the packaged archives on disk under wp-content/backups-dup-pro. Pro's Packages screen lists archive files with package type, size, and date, but it does not let you filter cleanly across recovery-point status, storage destination (Google Drive, Dropbox, Amazon S3, OneDrive, FTP, Local), or schedule source. A pre-deploy clone built last Wednesday and a nightly Full from this morning look the same in the list, even though only one of them is a recovery point.

SleekView reads wp_duplicator_packages directly and gives each package a row with the columns ops actually wants: created, name, type, size, destination, recovery point, status. The same dataset Duplicator writes, presented as a grid that can be sorted by size descending or filtered to recovery-point equals true. The result is that a restore engineer at four in the morning can find the right source in one click instead of clicking through tabs.

Edits route through Duplicator Pro's own actions. Pruning a package, promoting it to a recovery point, or re-uploading to a storage destination all use plugin hooks instead of direct writes to the custom table. The schedule, the cloud credentials, and the recovery-point logic stay canonical inside Duplicator; SleekView is purely the operational view layer.

Duplicator Pro is bought by sites with real restore obligations: agencies running dozens of client sites, regulated businesses with recovery-time targets, and release engineers who want a known-good archive before every deploy. The data Duplicator Pro stores supports all of that, but the default Packages screen treats every archive as a file to manage, not a row to query. Recovery-point status is buried inside detail, destinations cannot be filtered cleanly, and failed packages sit next to healthy ones with no visual separation.

That is acceptable for hobby sites and painful for the customers Pro was built for. SleekView reads wp_duplicator_packages and turns the same data into a grid: recovery-point as a column, destination as a filter, size as a sortable trend. Duplicator Pro continues to own the package builder, the storage credentials, and the recovery logic.

The grid is the operational layer over the data the plugin already maintains, which is the right way to add ops observability without competing with the backup tool.