XCloner has been a steady open-source backup option for years. It writes archive files to /wp-content/backups (or wp-content/xcloner-backups depending on version), runs scheduled jobs through WordPress CRON and supports remote storage targets like FTP, SFTP, Amazon S3, Backblaze B2, Dropbox, Google Drive and WebDAV. The default admin shows a schedule list and an archive list. Both are useful for one-off operations and weak for ongoing visibility across many destinations and many schedules.

SleekView Charts reads the same wp_options entries XCloner writes for each scheduled job and reconciles them with the archive manifest on disk. A Number card surfaces successful runs in the last 30 days. A Pie splits jobs by destination across the configured remotes. A Bar groups archive size per schedule, so the schedule that has quietly grown to 12 GB becomes visible. An Area trends run cadence per day so a stalled CRON shows up as a chart break.

Chart and table views sit on the same dataset, so any filter (failed runs, runs over an hour, runs targeting one remote) applies to both surfaces. XCloner keeps doing the backups; SleekView Charts handles the dashboard side.

XCloner has done its job well for years, and the architecture (WordPress CRON, archives to disk, optional remote push) is robust. The cost of that simplicity is the same cost most backup tools share: the data is rich, the surface is thin. A schedule that has run cleanly for six months and then quietly stopped because a remote credential expired is invisible until somebody happens to scroll the archive list.

Charting the same data fixes the visibility gap without changing the engine. A KPI catches a stalled schedule on day two. A destination Pie catches a remote target rejecting uploads.

A size-per-schedule bar catches retention drift before it becomes a hosting bill. None of it touches the way XCloner actually performs backups.