Duplicator stores package metadata in custom tables and keeps the actual archives on disk in wp-content/backups-dup-*. The Packages screen lists the files, but it does not let you slice across type (Full, Manual, Database), destination (Google Drive, Dropbox, Local, S3), or recovery-point flag. A pre-deploy clone built last Wednesday and a nightly Full from this morning look the same in the list. They are not the same when something needs restoring.

SleekView reads wp_duplicator_packages directly and gives you the kind of grid a backup tool in 2026 ought to ship with: created, name, type, size, destination, status. The same dataset Duplicator writes; a different way of looking at it. A 5.7 GB nightly Full sitting next to a 0 MB Failed Dropbox push tells you in one glance which run is restorable. The Packages screen, focused on file management, never makes that contrast as visible.

Recovery points are the case where this matters most. Duplicator Pro promotes specific packages to recovery-point status, but the flag is buried inside the package detail. Surfacing it as a column means an ops engineer at 4am can filter to recovery-point equals true, sort by created descending, and have the restore source in one click. The same applies to clones built before a deploy: tag them with a name, and the grid becomes the audit trail of which version of the site shipped where.

Duplicator does two jobs that look similar but are not: it builds packages for migration and it builds packages for backup. Both leave the same kind of file on disk, both write the same kind of metadata, and both end up on the Packages screen indistinguishable from each other unless you read the names carefully. That ambiguity is fine on a single-site project.

On a site that has been migrated three times, cloned for a redesign, and is now running nightly Fulls plus weekly Pre-deploys, the Packages screen becomes a wall of zip files. The right question is not which file is at the top; it is which package matches the situation you are in. Restore from a Pre-deploy clone built before yesterday's release, or restore from the most recent successful nightly Full to a known-good destination.

SleekView gives you the structured view that lets that question be answered with filters instead of memory. For agencies and migration specialists this is also a deliverable: an audit of every package across every client site, with destinations and recovery flags, ready to hand to an ops review.