NetBackup GitHub and Nexus Backups: Make Them Consistent

If GitHub related services and Nexus are already protected by whole-VM NetBackup jobs but the requirement is application-consistent recovery, add an application-aware layer instead of simply backing up more directories. Use the application's supported backup or export procedure to create a consistent recovery point, then use NetBackup to protect that output and keep the VM backup for full machine recovery.

That is the most useful interpretation of a source case involving SUSE Linux VMs, VMware, GitHub, and Nexus. The team already had VM backups but wanted separate consistent backups. The discussion correctly moved away from “which folders should I copy?” and toward coordinating the application backup with NetBackup.

Why is a whole VMware backup not automatically enough?

A VMware image captures the virtual machine at the infrastructure layer. That is excellent for recovering a deleted VM, damaged operating system, or failed host, but application consistency depends on what the workload is doing when the snapshot is taken.

On Linux, applications do not all participate in one universal quiescing framework that guarantees every database, repository, and metadata service reaches a consistent state. A crash-consistent snapshot may recover perfectly most of the time, but “most of the time” is not the same as a supported recovery design for a source-code platform or artifact repository.

The source discussion made this distinction clearly. One commenter described the VM snapshot as similar to pulling power and letting the service recover its filesystems and databases afterward. That can work, but the requirement for a consistent backup exists specifically because the organization wants more certainty.

The NetBackup VM backup versus database backup guide covers this recovery-layer distinction in more detail.

Should you just install the NetBackup Linux agent and back up important directories?

Not by itself. A file-system agent can reliably protect files, but it cannot make an application's internal state consistent merely by reading the right directories.

If a service writes related data across a database, blob store, configuration directory, repository path, and transaction journal, copying those locations at slightly different moments can produce a backup that is individually readable but logically inconsistent.

The better use of the NetBackup agent is to protect output that the application has already prepared for backup. That could be an export, snapshot, database dump, or vendor-supported backup directory.

This is where NetBackup pre and post scripts can be useful. A pre-backup action can trigger the application's supported backup routine, wait for it to complete, and place the result in a staging path. NetBackup then protects that stable output. A post action can clean up the staging data according to retention policy.

What is the correct approach for GitHub Enterprise Server?

If the “GitHub” system in your environment is GitHub Enterprise Server, use GitHub's supported backup design rather than treating it as a generic SUSE application directory. GitHub Enterprise Server has its own appliance architecture and current backup service.

As of August 2026, GitHub documents the built-in GitHub Enterprise Server Backup Service as the preferred solution. It can schedule and manage backups through the Management Console and stores backup data on dedicated storage accessible to the instance.

GitHub still documents the older Backup Utilities workflow, which uses a separate host and takes snapshots over SSH, but the documentation says Backup Utilities are scheduled for removal in GitHub Enterprise Server 3.22.

The source Reddit post does not establish which GitHub product is running on the SUSE VM. That ambiguity matters. If it is not GitHub Enterprise Server, identify the exact Git service before choosing a backup routine. Do not apply GitHub Enterprise Server instructions to a different product merely because users call the service “GitHub.”

What does Nexus Repository require for a consistent backup?

Sonatype states that Nexus Repository stores data in blob stores while metadata and configuration information live separately in databases, and those components need to be backed up together. That is the key recovery requirement.

For file-based blob stores, Sonatype identifies the blob directory as something that must be protected. For database state, follow the procedure for the Nexus version and database architecture you run. The goal is a point-in-time set where metadata and blobs correspond to one another.

This is why “back up the repositories directory” is too vague. A repository manager can have millions of blobs whose meaning is defined by database metadata. Restoring one without the matching other can leave missing artifacts, orphaned blobs, or inconsistent repository state.

Sonatype also recommends testing restoration and choosing backup frequency around RPO and RTO. A backup is not complete because NetBackup returned status 0. It is complete when Nexus can be restored and serve the expected artifacts.

How can NetBackup pre scripts fit into the workflow?

Use a pre script to invoke a supported application backup operation before NetBackup starts reading the staged backup data. The script should fail clearly if the application export fails, rather than letting NetBackup protect an empty or partial staging directory and report success.

A reliable sequence looks like this in plain language: verify enough staging space, start the application backup or database dump, wait for completion, validate the expected output, then allow NetBackup to protect the staged files. After a successful NetBackup job, clean up old staging data according to policy.

Do not make the script silently ignore application errors. The hardest backup failures are false positives where the backup software successfully saves a broken export.

Also avoid long application pauses if the vendor supports online backups. The goal is consistency with minimal production impact, not stopping services for the entire duration of a multi-terabyte NetBackup transfer.

Should the staged backup live on the same VM?

It can, but that is a design choice. Staging on the same VM is simple and allows the NetBackup Linux agent to protect the output directly. It also consumes local disk and creates a temporary second copy of application data.

If the environment has a supported shared or deduplicated staging target, that may reduce local capacity pressure. The source discussion mentioned NetBackup Universal Share as one possible design when MSDP is available, but the administrator said Universal Share was not present in that environment.

Without that feature, a normal local or mounted staging path can still work. The important requirements are enough free space, predictable permissions, reliable cleanup, and a recovery process that knows which files belong to one application backup set.

Do not let staging become an unmanaged archive. NetBackup retention should protect the durable copy, while local staging should be short-lived and monitored.

How should the VM and application backups be scheduled together?

Treat them as complementary recovery points. The VM backup protects the operating system, installed software, service configuration, and general machine state. The application backup protects the state the application vendor knows how to restore consistently.

One practical schedule might run application backups more frequently than full VM protection if the source code or artifact repository changes rapidly. The exact frequency should come from the business RPO, not from a generic daily schedule.

Avoid overlapping resource-intensive operations without testing. A GitHub or Nexus export can create heavy disk I/O, and a VM snapshot plus NetBackup data movement can add more. Stagger jobs if simultaneous execution causes latency or extends snapshot duration.

The Proxmox backup strategy guide addresses another hypervisor, but its recovery-first principle applies here: design the backup around the restore objective, not around which job type is easiest to configure.

What should a restore test prove?

For the VM layer, prove you can recover the machine into an isolated network and boot it. For the application layer, prove you can restore GitHub or Nexus according to the vendor procedure and that application data is actually usable.

For Nexus, verify repositories, metadata, representative artifacts, authentication, and any external blob storage dependencies. For GitHub Enterprise Server, follow the supported restore workflow for the backup method and version, then verify repositories, users, configuration, and any external service dependencies such as Actions storage where applicable.

Keep the restore test separate from the production system. A test that overwrites the live application is not a routine backup validation exercise.

Record the restore duration too. A technically valid backup that takes three days to rebuild may fail the business RTO even though the data is intact.

What would I implement for the SUSE VM case?

First I would identify the exact GitHub product and Nexus version. Then I would document each vendor-supported backup procedure before changing NetBackup policies.

For Nexus, I would create a coordinated backup of the database and blob stores, stage the result, then protect that backup set with the NetBackup Linux agent or another supported NetBackup path. For GitHub Enterprise Server, I would use GitHub's preferred backup service or supported backup utility rather than copying repository directories directly.

I would keep the existing VMware backup as the machine-recovery layer. Then I would run isolated restores from both layers and document when each one should be used.

The key is that NetBackup should protect a consistent application recovery point, not try to manufacture application consistency by copying more files. Once that boundary is clear, the design becomes much easier to reason about.