In Week 7, we built rkGetProtectionStatus() to retrieve protection and compliance state per workload.

In Week 6, we built rkGetSnapshotCount() to retrieve snapshot statistics across VMware VMs and filesets.

In Week 5, we extended rkGetSLAs() with cursor-based pagination and retention normalisation.

Up until now, the framework has been asking: "Should this workload be protected?"

Starting this week, we ask a harder question: "Can we prove that protection is actually happening?"

The answer lies in backup history. Every successful protection operation produces snapshots, making snapshot history the most reliable evidence that backups are occurring on schedule. A workload can have a valid SLA assignment, show PROTECTED status, and still have gaps in its recovery points due to backup failures or configuration drift.

This week we introduce:

rkGetSnapshots()

A reusable helper that retrieves individual recovery points for any protected workload directly from RSC.

SLA assignments describe intended protection. Snapshots record what actually happened.

These are not the same thing. A workload may have a perfectly configured SLA, report as compliant, and still experience backup failures or unexpected gaps in recovery points. Protection status tells you what Rubrik thinks. Snapshot history tells you what Rubrik did.

This is the information administrators reach for during audits, incident response, and routine health checks:

• When was the last successful backup?
• How many recovery points are available right now?
• Are backups being created at the expected frequency?
• How long are snapshots being retained?

None of these questions are answerable from protection status alone.

In Rubrik Security Cloud, each successful protection operation produces one or more snapshots. A snapshot is a point-in-time recovery image of a protected workload: the actual artifact used for recovery, Live Mount, or export.

Each snapshot carries:

• Snapshot ID
• Creation timestamp
• Expiration timestamp

Depending on workload type, additional metadata may be available. For our purposes, these three fields are sufficient to build backup validation, compliance reporting, and gap analysis workflows.

The RSC GraphQL API exposes snapshot history through snapshotOfASnappableConnection. The query accepts a workloadId and returns a paginated list of snapshots sorted by date.

The helper is designed to a simple contract:                  

function rkGetSnapshots(
    string $workloadId,
    int $maxSnapshots = 100
): array          

$snapshots = rkGetSnapshots($workloadId);

foreach ($snapshots as $snapshot)
{
    printf(
        "%s (%s)\n",
        $snapshot['date'],
        $snapshot['expirationDate']
    );
}         

Inside the helper, the query is parameterized: 

$query = '
query SnapshotHistory(
    $workloadId: String!,
    $first: Int!,
    $after: String
)
{
    snapshotOfASnappableConnection(
        workloadId: $workloadId,
        first: $first,
        after: $after,
        sortOrder: DESC
    )
    {
        count

        nodes
        {
            id
            date
            expirationDate
        }

        pageInfo
        {
            hasNextPage
            endCursor
        }
    }
}';     

A few things worth noting:

• sortOrder: DESC returns the most recent snapshots first, which is the order most operational workflows need.
• count gives you the total number of available recovery points without having to count the returned nodes yourself.
• We request only the fields we need. GraphQL performs field selection server-side. There is no benefit to fetching a large payload and filtering in PHP afterward. For a single workload this is a minor point. Across hundreds of workloads in a reporting loop, it becomes meaningful.

By now, pagination should feel familiar. The process is identical to the SLA and Snappable examples from previous weeks:

do
{
    $result = rkGraphQLQuery(
        $query,
        $variables
    );

    // Process snapshots

    $hasNextPage = $pageInfo['hasNextPage'];

}
while ($hasNextPage); 

The helper returns a clean PHP array:

[
    [
        'id'             => 'Snapshot:12345',
        'date'           => '2025-11-20T02:00:00Z',
        'expirationDate' => '2025-12-20T02:00:00Z'
    ],
    [
        'id'             => 'Snapshot:12346',
        'date'           => '2025-11-21T02:00:00Z',
        'expirationDate' => '2025-12-21T02:00:00Z'
    ]
]

By abstracting the raw GraphQL response into a consistent structure, future helpers do not need to understand the underlying schema. They consume normalized snapshot objects, keeping the framework maintainable as it grows.

This structure is immediately reusable for backup health validation, compliance reporting, gap analysis, and operational dashboards.

A simple CLI test produces:

Workload: PROD-SQL01

Snapshots Found: 14

2025-11-21 02:00 UTC
2025-11-20 02:00 UTC
2025-11-19 02:00 UTC
2025-11-18 02:00 UTC
2025-11-17 02:00 UTC
[...]

Immediate visibility into actual recovery points, not configuration metadata.

This helper marks the point where the framework moves beyond inventory and configuration data into operational backup intelligence.

Until now, the framework has been collecting information about workloads. From this point forward, it will begin evaluating how well those workloads are actually being protected.

/core/rkGetSnapshots.php

Having snapshot history is useful. Having to manually inspect it is not.

In Week 9, we transform raw snapshot records into backup health indicators. Rather than returning a list of timestamps, the framework will begin evaluating that list: identifying the most recent backup, flagging workloads with no activity in the last 24 or 48 hours, detecting gaps in expected backup frequency, and surfacing workloads that need attention before they become recovery problems.

This is where the framework moves from data collection into automated backup health assessment.