Veeam Backups Deleted by Ransomware or by Mistake: How to Recover Deleted VBK and VIB Files

Most ransomware groups go after the backups first. With administrator rights on the network, they delete the jobs and restore points in the Veeam console, delete the files in the repository folder, or format the repository volume, and only then start the encryption. Mistakes do the same on a smaller scale: a retention setting that is far too short, a wrong job removed with "Delete from disk", or a repository disk reformatted during a clean-up.

A deleted backup file is not erased. Windows and Linux only mark its space as free; the data stays on the disk until new data is written there. Veeam backup files are large and the repository is usually written to only by Veeam, so if the backup jobs are stopped in time, much of a deleted VBK or VIB file is often still there. This guide covers where to look for a surviving copy first, what to stop at once, and how deleted Veeam files are recovered from the disks when there is no other copy.

The biggest risk now is not the attacker but your own backup system. Disable the backup jobs that target the repository, especially any that would start tonight: a new full backup takes exactly the free space the deleted files are sitting in. Pause backup copy jobs, health checks and defragmentation or compaction tasks too, and do not run a new "active full" to "start clean" on the same volume.

Do not format or re-initialise the repository, do not run chkdsk, fsck or a RAID rebuild on it, and do not restore anything onto it. If the repository is a NAS or a RAID array, leave the disks in place and powered off, or, better, have the volume imaged first. All recovery work then happens on the image, so the original disks stay as they are.

Before recovering deleted files, check every place a copy may still exist; it is faster, and attackers often miss one of them:

Backup copy jobs to a second repository, another site, tape or the cloud. A capacity or archive tier on object storage, especially with object lock (immutability) switched on. A hardened Linux repository: its immutable files cannot be deleted, even with stolen Veeam credentials, until the immutability period ends. A Veeam Cloud Connect provider: with Insider Protection switched on, backups deleted from the provider's repository are kept in a recycle bin for a set number of days, so call the provider at once. Snapshots on the NAS or SAN that holds the repository, such as Synology, QNAP or NetApp snapshots: a snapshot taken before the attack contains the backup files as they were. Even an old USB disk with last month's full backup is worth more than nothing.

If one of these exists, copy it to clean storage first and test a restore from the copy before relying on it. If the deleted chain is newer than the surviving copy, it can still be worth recovering both: the copy for safety, the deleted files for the missing days.

On an NTFS repository, deleting a file removes its entry from the folder index and marks its MFT record and clusters as free, but the MFT record, with the list of where the file's data lies, usually stays readable until it is reused. Recovery reads those records, finds the deleted VBK, VIB and VBM files, and copies their data out by the cluster list. A quick format writes a new, empty file system but leaves most of the old data area untouched, so the old records and clusters can often still be found.

Veeam files help in a second way. A Veeam backup is built from data blocks that each carry their own checksum, and the file keeps its metadata in two copies. So even when a deleted file is only partly intact, the recovered file can be checked block by block: every block either matches its checksum or is counted as lost. You know exactly which virtual machines, disks and files are complete, instead of hoping the restore works.

Overwritten space is gone. If backup jobs ran after the deletion, the new files may sit exactly where the old ones were, and the more that was written, the less survives. Thin-provisioned LUNs, SSDs and virtual disks that pass TRIM or UNMAP to the storage are a special case: once the storage has reclaimed the freed blocks, they read back as zeros, often within minutes of the deletion. A full format, a wipe, or encryption of the repository volume itself also leaves nothing to undelete, although an encrypted backup file can sometimes be recovered in other ways.

ReFS repositories with block cloning (Veeam's fast clone) need more care. Synthetic fulls on ReFS share blocks with older backup files, and ReFS stores its file system metadata differently from NTFS, so a deleted backup cannot simply be undeleted by an ordinary NTFS recovery tool. The data is often still on the disk, but rebuilding which blocks belonged to which file is laboratory work.

Recovered files are written to clean storage, never back to the source repository. A full backup file (.vbk) can then be imported into Veeam Backup & Replication with Import Backup, or by adding the folder as a repository and running a rescan, and restored the usual way. For an incremental chain, the .vbm metadata file helps Veeam see the whole chain; if it was not recovered, the full .vbk can still be imported and restored on its own.

If a recovered file is incomplete, Veeam may refuse it. The intact virtual machines and files can still be taken out of it by reading the file directly, block by block: AS VBK Recovery Studio does this without the Veeam console, and its free edition analyses the file and lets you browse and preview what is inside before you buy a licence to save it.

If the deleted files are on an ordinary NTFS volume, nothing has been written since, and you have a disk image, an undelete tool may find them. For a repository on RAID, NAS, ReFS or a SAN, after a format, or when the business depends on the result, our Veeam backup recovery service images the repository, recovers the deleted backup files, checks every block, and returns the virtual machines and data that are complete. We have solved many ransomware cases where the backups were the attackers' first target; contact us for a free assessment, and if no data can be recovered, there is no charge.

Afterwards, the lasting fix is to keep at least one copy the attackers cannot delete: a hardened Linux repository or object storage with immutability, a backup copy offline or off-site, and Veeam credentials that are not the same as your domain administrator accounts. Then test a restore from that copy on a schedule.