Asigta How-to: Investigate a spike in your Asigra backup storage usage

If you have received a notice that your backup storage usage has increased — or you have noticed a change on a usage report or invoice — this article walks you through reviewing your own backup activity in the Asigra DS-Client, so you can see exactly what changed, when it changed, and which data was responsible. Everything here uses the DS-User console you already use to manage your backups.

Applies to: Asigra Cloud Backup v14.x (DS-User / DS-Client). Menu labels may vary slightly on other versions.

How Asigra measures your storage

A quick primer makes the rest of this article easier to interpret. Asigra describes your data in two ways:

• Native size — the original, uncompressed size of the most recent version of everything currently protected. Think of it as “what you would restore.” It includes files that were deleted at the source but are still retained under your rules.
• Stored size — the actual space your data occupies after Asigra deduplicates and compresses it. Usage and billing are typically based on stored size.
• Generations & retention — Asigra keeps multiple historical versions (generations) of your files according to your retention rules. Each retained version of a changed file adds to stored size, so heavy file churn — or a change to retention — can raise usage even when your live data set looks the same.
• Deduplication & compression — Asigra stores only unique, changed blocks. A spike often reflects genuinely new or heavily changed data that could not be deduplicated against what was already stored.

Before you begin

• Access to the DS-User management console (the interface you use to run and monitor backups).
• Sign-in credentials for the DS-Client that protects the data in question.
• The approximate date range when usage increased (from your notification, report, or invoice) — having this to hand makes the search much faster.

Step 1 — Connect to your DS-Client

1. Launch DS-User.
2. Connect to the DS-Client you want to review — select it from your list of DS-Clients, or enter the address and sign in.
3. Once connected, the main window shows your backup sets and the menu bar you will use in the following steps.

Step 2 — Find when usage changed (Activity Log)

The Activity Log is the fastest way to see when usage changed and how much data each backup added.

1. On the Logs menu, click Activity Log.
2. In the Select By area at the bottom, set the From and To dates to bracket the period when usage rose (for example, a week either side of the date on your notification).
3. Leave Node/Set set to all backup sets to start, so nothing is excluded.
4. Review the list of backup activities. For each backup, note the amount of data added to online storage (commonly shown as the “Online” figure) alongside the number of files processed and the data transmitted.
5. Look for one or more sessions where the online figure is noticeably larger than the surrounding days. Those are your spike candidates.

Step 3 — See which files were added (Detailed Log)

Once you have identified a session that added more than expected, look inside it to see the actual files.

1. In the Activity Log, select the backup activity you flagged.
2. Click Detailed Log. This lists the individual files backed up in that session.
3. Sort or scan for large files or a large number of new files — a new dataset, a database dump, a VM image, media files, or a bulk copy are common culprits.

Optional cross-check — browse by restore date

Another angle — and a good way to capture the actual filenames behind a spike — is to browse the backup by restore date. Because Asigra lets you view a set as it existed on any given day, you can compare two dates and see what data appeared in between.

1. Start a restore for the backup set you flagged (for example, right-click the set and choose Restore). You are only browsing here — nothing is recovered until you explicitly confirm a restore.
2. Use the date / time selector to view the set as it existed the day before the increase, and note the folders and file sizes.
3. Change the date to the day of (or just after) the increase and compare. Folders or files that are newly present — or noticeably larger — are your spike candidates, and you can read the actual filenames and paths right here.
4. Record those filenames and paths. They tell you what drove the increase and whether that data belongs in this backup set.

Step 4 — Compare storage across your backup sets

To see where your storage sits overall — and which set carries the most — use the built-in reports. From the Reports menu you can generate:

• Storage Summary Report — total online / stored data; useful for the big-picture view and trend.
• Statistical Summary Report — a per-set breakdown, so you can see which backup set holds the most stored data.
• Online File Summary Report — what is currently held online; helpful for spotting a set that has grown.

Compare the stored size of each set. The set with an unexpectedly large — or recently increased — stored size is where to focus, and it should line up with the session(s) you found in Step 2.

Seeing a set’s growth over time

The reports above are point-in-time snapshots. There is no single per-set “trend” report on the DS-Client itself, but you can see how an individual set has grown in two accurate ways:

1. On the DS-Client — open Logs > Activity Log, filter Node/Set to a single backup set, and read the per-session “Online” figures across your date range. Scanning them day by day shows when and how fast that set grew — effectively a per-set trend built from data you already have. You can also run the Storage Summary or Statistical Summary Report at intervals (or export the data) and compare stored size per set across dates.
2. From CyberFortress — Asigra also records a longer storage history on the DS-System side, which we can produce as a Storage Trend Report for your DS-Client. This is an account-level trend across the DS-Client rather than a per-set breakdown, so it pairs well with the per-set view above. Just let us know if you would like it.

Step 5 — Identify the likely cause

Use this checklist to match what you found to a common cause.

What to do next

• Note your findings: the date(s), the backup set involved, and the files or cause you identified.
• If the growth was expected — a planned new dataset, or an intentional retention change — no action is needed; your backups are working as designed.
• If it was not expected, you can adjust the backup set’s scope or retention in the DS-Client.

Quick reference

Navigation labels reference Asigra Cloud Backup v14.x.

Still need help?

If anything is unclear, or you would like a second set of eyes, our Customer Success team can review the same logs and reports with you, interpret the numbers, and recommend adjustments that balance cost and recoverability.