NetBackup Alta View Reporting: Find Missing Backups

If your goal is a simple report such as “show every server without a full backup in the last seven days,” do not start by building a reporting system from scratch. NetBackup reporting already has report patterns for clients with no backup in a configurable number of days, and the report library can be a faster starting point than fighting a blank custom report designer.

That does not mean the frustration is imaginary. In one administrator discussion, Alta View was described as cumbersome and sometimes slow. Another person said they could produce custom Python reports faster and with better control. The specific request was basic: identify servers that had not received a full backup in seven days.

Is there already a report for clients with no recent backup?

Yes. Current NetBackup IT Analytics transition documentation maps the older “Clients Not Backed Up” concept to customer reports named “Clients with no Backup in X Days” and “Failed or No Backup in 3 days.” That is almost exactly the use case raised in the discussion.

The practical move is to start from that existing report and modify the window or backup criteria rather than recreating the whole query. If seven days is the operational threshold, use that as the report parameter or adapt the report template to match it.

Be precise about what “no backup” means. A server may have an incremental backup but no recent full. Another may have attempted jobs that all failed. A third may have been decommissioned but is still present in inventory. Those are different exceptions and should not land in the same queue without context.

The earlier NetBackup backup success rate guide makes the same point from an SLA angle. A percentage is useful only when you can explain which clients make up the missing portion.

Why does Alta View reporting feel cumbersome?

Reporting products become difficult when the data model is much richer than the question an operator is trying to answer. Alta View can aggregate information across NetBackup domains, which is valuable for enterprise visibility, but a simple operational question can still feel buried under report configuration choices.

The community feedback in the source case is blunt. One user called the setup a pain and noted that custom reports can be slow. Another preferred Python because it gave direct control over the query and output.

Both reactions are reasonable. A graphical report designer has to expose filters, scopes, time ranges, dimensions, schedules, and presentation options. Python lets an experienced administrator encode the same logic directly. The tradeoff is maintenance. Once a script becomes part of the daily backup control process, someone owns its credentials, API behavior, error handling, scheduling, and version changes.

Before writing code, check whether the desired output already exists in the report library.

What is the IT Analytics Customer Report Library?

The Customer Report Library is a collection of community-created reports that can be downloaded, imported, and customized. Current documentation says these reports complement more than 300 reports included with NetBackup IT Analytics and cover areas such as backup, capacity, SAN fabric, and chargeback reporting.

For backup operations, that library includes useful patterns such as client status, job success, stalled jobs, error summaries, tape status, backup window exceptions, and clients missing recent backups.

There is an important caveat. The documentation says customer report examples are not supported in the same way as built-in product functionality, and some reports may not suit large environments or MSP portals. Treat them as templates you can inspect and adapt, not magic production code.

That is still a much better starting point than a blank report. It gives you the intended data relationships and a working query structure you can test against your own estate.

How should a “no full backup in seven days” report be defined?

Define the exception in operational terms before touching the report designer. The cleanest rule is something like: active production clients expected to receive a full backup must have at least one successful full backup within the previous seven complete days.

That sentence immediately exposes several filters. Which clients are active? Which policy types count? Does a synthetic full count? What about application protection plans? Are test servers excluded? What happens when a client is intentionally paused for maintenance?

Without those definitions, the report may be technically correct and operationally useless. It will flag systems that nobody expects to protect or hide systems that have successful incrementals but no usable full recovery point.

This is also where licensing and inventory hygiene meet reporting. The NetBackup FETB capacity guide explains why duplicate or stale client records can distort another view of the estate. Reporting benefits from the same cleanup.

Should you use Alta View, IT Analytics, or a Python report?

Use the product reporting layer when the requirement is common, shared, and likely to be consumed by more than one team. Use code when the logic is highly specific, the output must feed another system, or the built-in data model cannot express the condition cleanly.

A Python report can be excellent for an operations team that already maintains internal tooling. It can send a concise list to a ticketing system, enrich clients with CMDB ownership, and apply business-specific suppression rules.

But custom code creates a dependency on whoever wrote it. A report that starts as a ten-line script often grows authentication, retries, pagination, CSV formatting, email delivery, logging, and exception handling. That is fine if the value justifies it.

The middle ground is often best: start with the standard or customer report library, prove the definition of the exception, then automate only the pieces the reporting product cannot handle well.

Why can reporting performance degrade in large environments?

The source discussion reports slowness but does not identify a specific root cause, so it would be wrong to blame one component. Report performance can be affected by the scope of data being queried, history retention, the number of connected domains, the complexity of the report template, and the amount of aggregation required.

Start by narrowing the query. Run one NetBackup domain, one client group, and a shorter time window. If that is fast, expand the scope gradually until the slowdown appears. That tells you whether the problem is data volume or the report definition itself.

Also compare a built-in report with a custom report over the same scope. If both are slow, investigate platform performance and data collection. If the built-in report is fast and the custom report is slow, the template deserves attention.

Do not optimize the visual layout before the query logic is correct. A report that returns the wrong client list quickly is still wrong.

What should a useful daily backup report actually contain?

A useful exception report should help an operator decide what to do next. Include client identity, last successful full backup time, last successful backup of any type, most recent failure status, policy or protection plan, and enough ownership context to route the issue.

Avoid turning the report into a wall of every successful job. The point is to make exceptions visible. If the team has 9,000 daily backup processes, a report of 8,900 successes is less actionable than a clean list of the 100 systems that need attention.

Add decommissioning state if you can. One common reason backup success rates stay below 100 percent is that systems disappear without the backup team being told. Reporting should separate “failed protection” from “asset no longer exists.”

Then measure the report itself. If the daily exception list keeps growing, the reporting process has identified a control problem that needs ownership, not another dashboard.

What would I use for the seven-day full backup question?

I would first import or inspect the “Clients with no Backup in X Days” report pattern and adapt it to full backups and a seven-day window. Then I would validate the output against a small known set of clients before scheduling it.

If the report designer still makes the logic unnecessarily difficult, I would use Python for the final exception workflow, but I would keep the report definition documented in plain language so the script does not become the only place the business rule exists.

Alta View and IT Analytics are useful when they reduce the time between a missed backup and a corrective action. The best report is not the fanciest one. It is the one that reliably tells the backup team which systems are outside policy today.