Beget: evidence linking a backup to its account and service
A surviving copy needs to be linked to the correct customer and service before returning to operation. Recovery also depends on the catalog, permissions and configuration that make that association verifiable.
Portekizce okuBy Pentesty
Preserve the sequence of statements
In its November 3 statement, Beget reported management-plane access and destructive scripts during the night of November 1 to 2, 2026. The provider said data in its VPS, S3 and Kubernetes infrastructure was lost, along with VPS binary backups. This describes the provider’s assessment; it does not independently establish the entry vector or identify the attacker.
The November 6 update estimated that file backups would be available for only half of VPS users and reported lost account-to-service associations. On November 7, the provider described restoration beginning and plans to associate copies with the correct accounts. Estimates and announced stages do not establish that every customer has recovered its environment.
Identify the service before choosing a copy
For a business dependent on hosting, the first practical decision is which service to recover and who can accept it. Collect contract, project and resource identifiers, including recent changes. A similar filename or address can help locate a candidate, but it still needs to be linked to an inventory the service owner recognizes.
In an authorized exercise, give the team synthetic copies for two fictional customers with similar names. Ask it to demonstrate correct ownership, permission to inspect each set and denial of cross-customer access. Retain test identifiers and outcomes while keeping real customer data outside the exercise.
Check the independence of recovery records
Identify the records needed to locate and interpret copies. Ask how they can be consulted if the usual console, administrative identity or inventory database is unavailable. Document observed dependencies without concluding that a particular provider had an unsuitable architecture simply because it reported recovery difficulties.
Our analysis of JadePuffer and deletion in Azure examines who can remove resources needed for recovery. Add a question to this assessment: can the team locate a copy and establish its owner when the usual source of that information is unavailable? Record who authorizes the alternative as well.
Restore configuration with accountable owners
The test needs to consider the restoration destination. Map the network, DNS, permissions, integrations and external services required for the agreed operation. Establish which settings come from the copy and which will be rebuilt. Avoid accepting a page that opens as sufficient evidence that every legitimate workflow has returned.
Separate permission to restore data from permission to reactivate old access. In a laboratory, use a fictional integration that was previously revoked and check that recovery does not enable it again. The owner should be able to connect each result to the restored version, the identity used and the decision to allow or deny the operation.
Define what makes a restoration acceptable
Agree on criteria before the exercise: an identified copy, validated ownership, authorized access and an observed business function. When a condition fails, record the affected service and outstanding decision. An overall recovery percentage does not replace evidence for the resource your organization depends on.
Our study of dependencies when a cloud zone is lost offers another setting for this exercise. Include the possibility that a dependency remains unavailable. The team needs to demonstrate the agreed alternative or keep the service pending, without turning a commercial expectation into a technical result.
Keep recovery observable after the return
After acceptance, assign someone to check subsequent copies and inventory changes. A migration can change names, owners or permissions. Repeating a synthetic restoration after those changes helps establish whether the documented association remains usable, rather than relying solely on success achieved during the crisis.
This proposal does not assess Beget’s internal infrastructure or promise complete recovery. It defines evidence a business can request and produce within its own contract and environment. Closure should record what was restored, the remaining gaps and who accepted responsibility for tracking them.
Frequently asked questions
Does finding a backup mean the service is recovered?
No. Validate its association with the service, permission to restore it and the expected behavior at the destination.
Does the half-of-users estimate apply to everyone now?
It is Beget’s November 6 assessment of VPS file backups. It does not establish the current position of every user.
Are real records needed to test ownership mapping?
Use fictional customers and datasets within an authorized scope. The aim is to observe correct mapping and denial of unauthorized access.
Who should accept the service’s return?
The designated service owner should assess the outcomes and limitations agreed with technical teams and the provider.
Sources and references
- Beget: incident statement, November 3
- Beget: backup and recovery assessment, November 6
- Beget: recovery stages, November 7
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.