Why Deleted Files Are Recoverable: File Systems, Snapshots and SSDs

Deleted files are recoverable because deleting a file removes the file system's references to the data, not the data itself. The blocks stay on the disk until something reuses them, and journals, snapshots, shadow copies, sync services and an SSD's wear levelling keep extra copies you never see. Encryption at rest, plus a proper sanitize command for whole devices, is what actually makes old data unreadable.

Below, the mechanism layer by layer: file systems, snapshots, flash storage, memory, and how it maps onto NIST SP 800-88 Revision 2.

Key takeaways

• Delete is a bookkeeping operation. The file system marks space as free and forgets the name; the bytes stay until they are overwritten.
• Crash safety and data retention are the same feature. Journaling and copy-on-write file systems deliberately write new data somewhere else, which means old versions linger.
• Snapshots are designed to keep deleted data. Windows shadow copies, Time Machine local snapshots and Btrfs snapshots hold old blocks on purpose until the snapshot itself goes away.
• On SSDs you cannot reliably overwrite one file. The drive's flash translation layer writes to new physical pages and keeps spare capacity you cannot address. Research from 2011 found that single file overwrite tools left between 4% and 75% of a file's contents behind on SATA SSDs.
• Encryption is the practical answer. If data was only ever written encrypted, destroying the key is a fast, recognised Purge technique called cryptographic erase.
• RAM is not instantly blank either. DRAM kept most of its contents for seconds at room temperature and for minutes when chilled, in the 2008 "Lest We Remember" study.
• For secrets, rotation beats deletion. A token that sat in a file, a backup or a git commit should be revoked, because you can rarely prove every copy is gone.

What "delete" actually does

Every file system has two kinds of storage. One holds your data. The other holds metadata: names, sizes, timestamps, permissions, and the map from a file to the blocks that contain it. When you delete a file, almost every file system changes only the metadata. The directory entry goes away, the file's record is marked unused, and the blocks are returned to the free pool.

Nothing writes zeros over the data, because that would make deletion slow and wear out storage. The content sits in "free" space, readable from the raw device, until a later write lands on those blocks. When that happens depends on how full the disk is, the allocator, and on an SSD, the drive firmware. You cannot point at a moment and say the data is gone.

What happens on disk when you delete a file in NTFS, APFS, ext4 and Btrfs

NTFS: the Master File Table entry is marked free

NTFS keeps a file called the Master File Table (MFT). Microsoft's documentation says there is at least one MFT entry for every file on the volume, and that all information about a file, including its data, is stored either in MFT entries or in space outside the MFT that those entries describe. Small files can live entirely inside their MFT record; larger ones point to runs of clusters elsewhere on the volume.

On deletion, Microsoft states, the file's MFT entries "are marked as free and may be reused." The MFT does not shrink, and the clusters the file used go back to the free space bitmap. Until a new file claims that MFT record and those clusters, the old record (name, timestamps, cluster map) and the old content are both still on the disk. The map to the data often survives intact.

APFS: copy-on-write means the old version was never overwritten

The Apple File System Reference is explicit about its write model: "objects on disk are never modified in place, and modified copies of an object are always written to a new location on disk." APFS uses this copy-on-write approach, together with periodic checkpoints, for crash protection.

So when you edit a file on APFS, the new version goes to fresh blocks and the old blocks are released. When you delete it, the metadata objects that pointed to its extents are replaced with new ones that do not, and the extents return to the space manager. The previous contents are not touched. If a snapshot references those extents, the space manager cannot even reuse them until the snapshot is deleted.

APFS does have a strong counterweight: on Apple devices, data is encrypted. Apple's Platform Security guide says each new file on supported hardware gets its own 256 bit key, used by the hardware AES engine as the file is written to flash. A deleted file's leftover blocks are ciphertext. On Macs with Apple silicon, Apple says the default class uses a volume key instead, with FileVault binding it to the user's password. Either way, leftovers are only as safe as the keys that still exist.

ext4: the inode and bitmaps change, and the journal remembers

ext4 tracks files with inodes and free space with block bitmaps. Deleting a file removes the directory entry, decrements the inode's link count, and when it reaches zero, frees the inode and its blocks in the bitmaps. The data blocks themselves are not cleared.

The journal adds a second place where content can live. The kernel documentation lists three modes. In data=journal, both data and metadata are written to the journal before they reach their final location. In the default data=ordered mode, only metadata is logged. In data=writeback, metadata is journaled and data is not forced out first. The documentation also notes that journal transactions copy blocks verbatim into the journal. On a system mounted with data=journal, a recent copy of file content can therefore sit in the journal area until the circular log wraps around and overwrites it.

Even in the default mode, journaled metadata can show that a file existed and where its blocks were, which helps incident responders rebuild timelines.

Btrfs: copy-on-write plus cheap snapshots

Btrfs is a copy-on-write file system like APFS. Its documentation says a snapshot and its original "initially share all of the same data blocks," and that creating a snapshot is close to instant because it only copies a tree root in metadata. Deleting a file from the live subvolume therefore frees nothing if a snapshot still references the same extents. The data remains, reachable through the snapshot path, until every snapshot holding it is removed.

Snapshot deletion is two phase: the directory vanishes at once, and a background "cleaning" step releases the data later.

Why journaling and copy-on-write keep old copies around

Both designs answer the same question: what happens if power fails halfway through a write? A file system that overwrites blocks in place can be left with a half old, half new structure. To avoid that, modern file systems do one of two things.

Journaling file systems (NTFS's log, ext4's journal) write a description of the change to a log first, then apply it. If the machine crashes, the log is replayed or discarded. Copy-on-write file systems (APFS, Btrfs, and ZFS) never overwrite live data; they write a new version elsewhere and then switch a pointer to it in one atomic step.

Either way, the system holds before and after states for a while: in the log, or as old blocks no longer referenced. That is why the GNU shred manual opens its caution with "shred assumes the file system and hardware overwrite data in place," then warns that many platforms do not, and that backups and mirrors can hold copies that let a shredded file be recovered later.

How snapshots, shadow copies, Time Machine and cloud sync preserve "deleted" data

Operating systems also keep deliberate copies so you can recover from mistakes. Each is a place where a deleted file survives by design.

Windows Volume Shadow Copy

The Volume Shadow Copy Service (VSS) underpins System Restore, Windows Server Backup and Shadow Copies of Shared Folders. Microsoft's documentation describes the built in system provider as copy-on-write: before a block on the original volume is changed, the old block is read and saved into a shadow copy storage area, the "diff area." That is exactly the mechanism that preserves a file you later delete. Microsoft also says the system provider can hold up to 512 software shadow copies per volume, and that when the storage area fills, the oldest shadow copies are deleted first.

Excluding files from shadow copies is not a deletion tool either: Microsoft says such files "aren't guaranteed to be deleted."

Time Machine local snapshots on macOS

Apple's Time Machine guide says that in addition to backups on an external disk, Time Machine "saves local snapshots you can use to recover previous versions of files." These snapshots are created hourly, stored on the same disk as the original files, and kept for up to 24 hours or until space is needed. They exist only on APFS volumes. A file you delete at 10:00 is therefore still present inside the 09:00 snapshot on your internal drive, and inside every backup on the external disk.

Btrfs and ZFS snapshots on Linux servers

Some Linux setups take snapshots automatically, for example before package upgrades, and storage appliances often take them on schedules. Each one pins the blocks of every file that existed at that moment. If a credentials file was on disk when the snapshot ran, deleting it from the live volume changes nothing about the snapshot.

Cloud sync, version history and recycle bins

Sync services usually keep a deleted items area and version history for a retention period, so a file deleted on the laptop may only move into a cloud recycle bin. Email attachments, chat uploads and CI artifacts are separate copies with their own retention, untouched by your local delete.

Git history

A committed file removed in a later commit stays in every earlier commit, clone and fork. GitHub's guidance starts with revoking or rotating the secret, and warns that even after a history rewrite "the commits with sensitive data may still be accessible elsewhere."

How an SSD's flash translation layer differs from an HDD's sectors

On a hard disk, each logical block address (LBA) maps to a physical sector, and a write to LBA 1000 rewrites that sector in place. The exception is a bad sector remapped to a spare, whose old contents can remain. Otherwise, overwriting an LBA really overwrites the old data.

Flash memory cannot work that way. NAND flash is written in pages but erased only in much larger blocks, and each block survives a limited number of erase cycles. Rewriting one page in place would mean erasing and rewriting the entire block around it. So SSDs add a layer of indirection called the flash translation layer (FTL). When you write LBA 1000, the FTL writes the new data to a fresh, already erased page somewhere else and updates its internal map. The old page is marked stale and is erased later, during garbage collection, on the drive's own schedule.

Wei, Grupp, Spada and Swanson described this directly in their 2011 USENIX FAST paper, "Reliably Erasing Data From Flash-Based Solid State Drives": the indirection between logical addresses and raw flash addresses "can also produce copies of the data that are invisible to the user but that a sophisticated attacker can recover." The host computer only sees logical addresses. It has no way to name the stale physical pages, so it cannot overwrite them.

What TRIM, wear levelling and over-provisioning do to overwrite tools

Three SSD features shape what a software overwrite can and cannot reach.

Wear levelling spreads writes across all blocks, so rewriting one logical address lands on many physical pages, each leaving a stale copy until garbage collection.

Over-provisioning is spare flash beyond the advertised capacity, used for garbage collection and replacements. The host cannot address it, and stale copies can live there.

TRIM (called discard on Linux, and Deallocate in NVMe) lets the operating system tell the drive which logical blocks no longer hold useful data, so the FTL can stop preserving them and erase them in the background. Timing is up to the drive, and TRIM is a performance and wear hint, not a sanitization command. The fstrim manual describes discarding unused blocks and suggests running it about weekly; it makes no promise about recoverability.

The research results are the clearest way to see the effect. Wei and colleagues extracted raw data directly from flash chips after applying common sanitization methods. Their findings:

• Every single file overwrite technique they tested failed on SSDs. Between 4% and 75% of a file's contents remained on SATA SSDs, and between 0.57% and 84.9% on USB flash drives.
• Overwriting the drive's entire visible address space twice was "usually, but not always" enough to sanitize a whole drive.
• Built in sanitize commands worked when implemented correctly, but of seven verifiable drives that supported ATA Security Erase, only four executed it reliably. One reported success while leaving all data intact.

NIST SP 800-88 Revision 2 reaches the same point. It says multi pass overwrite schemes "should be avoided" for media such as SSDs with over-provisioning, because "very little confidentiality protection is achieved," and that wear levelling and spare cells make it infeasible for a user to overwrite every location where data has been stored.

Firmware has improved since 2011, but the host still cannot address stale pages, and you still trust the vendor's implementation.

Why encryption at rest is the most practical answer, and what crypto erase is

If you cannot destroy every physical copy, make every copy useless. With full disk or file based encryption, stale flash pages, freed clusters, old extents and journal blocks are all ciphertext.

NIST SP 800-88 Rev 2 calls the resulting technique cryptographic erase (CE) and defines it as a Purge technique "in which key sanitization is applied to one or more keys" protecting the encrypted data. Destroy or zeroize the key, or the key that wraps it, and the ciphertext becomes unrecoverable. NIST notes CE can sanitize "with high assurance much faster than with other sanitization techniques," which is why phones and modern laptops reset in seconds rather than hours.

Platform vendors use this mechanism by default:

• Apple's security guide says instant remote wipe on a Mac with Apple silicon, a Mac with the T2 chip, or a Mac with FileVault turned on works by "securely discarding the media key," rendering all data unreadable. Erase All Content and Settings requires macOS Monterey or later on Apple silicon or T2 Macs.
• Android's documentation says file based encryption arrived in Android 7.0 and is required on all devices launching with Android 10 and later. Keys are managed by vold and wrapped by a Keystore key inside the trusted execution environment, and on devices whose KeyMint supports rollback resistance, FBE keys "can be securely deleted."
• The UK NCSC's sanitisation guidance says that for encrypted devices, a manufacturer's factory reset "deletes the encryption keys, making the data unreadable," which gives satisfactory assurance for most devices, though it cannot guarantee every piece of user data is unreadable.

NIST is careful about when CE counts:

• The data must never have been written in plaintext. NIST cites ISO/IEC 27040's precondition that no sensitive data was previously stored on the media unencrypted. If you turned on BitLocker or FileVault after a year of use, plaintext from before encryption may still sit in stale flash pages or unused sectors.
• Every copy of the key must be destroyed. NIST warns that CE "should not be trusted on ISM that have been backed up or escrowed" unless you know where the keys went. A recovery key printed in a drawer or stored in a directory service is a copy.
• Long lived secrets may need more. If algorithms weaken in future, leftover ciphertext could become readable, so CE may not suit data that must stay secret for decades.
• The cryptography must be sound: at least 128 bit strength, and FIPS 140 validated modules for US federal agencies.

The same idea at application level is crypto shredding, covered in our post on crypto shredding, when deleting the key deletes the data, and its limits in key destruction and cryptographic erasure limits.

What is data remanence in RAM, and what did the cold boot research show?

Storage is not the only place data outlives deletion. Encryption keys have to be in memory while a disk is unlocked, and memory does not go blank the instant power is cut.

In "Lest We Remember: Cold Boot Attacks on Encryption Keys" (17th USENIX Security Symposium, 2008), J. Alex Halderman and colleagues found that DRAM typically lost data gradually over several seconds at normal temperatures, even when removed from the motherboard. With surface temperatures of about minus 50 degrees Celsius, achieved by spraying an inverted can of compressed air duster onto the chips, they "typically found that fewer than 1% of bits decayed even after 10 minutes without power." Submerged in liquid nitrogen, a module showed only 0.17% decay after 60 minutes out of the computer.

They recovered disk encryption keys and defeated BitLocker, TrueCrypt and FileVault, even with the screen locked or the machine suspended. BitLocker with only a TPM could sometimes be attacked even when fully powered off.

The lesson holds: a locked screen does not protect memory, and sleep keeps keys in RAM. In practice:

• Shut down or hibernate a laptop before travel or when leaving it unattended in a risky place, rather than closing the lid into sleep.
• Use pre boot authentication (a PIN or password before the disk unlocks) where your encryption supports it, rather than relying only on automatic unlock.

Hardware has changed since 2008, so the exact timings will differ on current memory, but the defensive habits above still apply. Our post on CWE-1330, remanent data after memory erase covers the hardware weakness class, and CWE-1301, incomplete hardware data removal covers the storage equivalent.

Does emptying the trash or recycle bin do anything for security?

Very little. Moving a file to the Trash or Recycle Bin is a rename into a special folder; the file is fully intact and any user or process with access can restore it. Emptying the bin performs the ordinary delete described above: references go, data stays. It does not touch shadow copies, local snapshots, backups, sync history or other copies.

It frees space for later overwrites and, on an SSD with TRIM, tells the drive the blocks are free. Neither is a guarantee. Treat it as housekeeping, not sanitization.

How do you delete one sensitive file properly vs sanitize a whole device?

Removing one file with certainty is mostly impossible on modern hardware. Sanitizing a whole device is easier, because the drive can erase everything it holds, including areas the host cannot address.

Step 1: Decide which job you have

• One file, device stays in use: rotate the secret if it is a credential, rely on encryption for the leftover blocks, and clean up the known copies (snapshots, backups, sync history, git history).
• Whole device leaving your control (sale, return, disposal, reassignment): use the vendor's erase or reset on an encrypted device, or a drive level sanitize command, and record it.

Step 2: Confirm encryption is on and has been on

Encryption is what turns leftover blocks into noise, so check it before anything else.

# macOS: FileVault status
fdesetup status

# Windows (elevated prompt): BitLocker status for each volume
manage-bde -status

# Linux: list block devices and see whether volumes sit on a LUKS (crypt) layer
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS

If encryption was enabled only recently, plaintext written before then may still exist in unaddressable flash; plan a full sanitize at end of life.

Step 3: Find and remove the copies you control

Look for the deliberate copies before you worry about raw blocks.

# macOS: list Time Machine local snapshots on the startup disk
tmutil listlocalsnapshots /

# Windows (elevated prompt): list Volume Shadow Copies
vssadmin list shadows

# Linux with Btrfs: list snapshots under a mount point
sudo btrfs subvolume list -s /

# Git: list every commit that ever touched a file, across all branches
git log --all --oneline -- path/to/secret.env

Deleting snapshots and shadow copies is irreversible and removes your ability to roll back. Take a fresh backup of what you need first, confirm which snapshots exist, and remove only the ones that hold the sensitive file. For git history, follow GitHub's documented process (rotate first, then rewrite with git filter-repo, then coordinate with everyone who has a clone).

Step 4: For one file on a hard disk, overwrite in place, with caveats

On a hard disk with a file system that overwrites in place, GNU shred can overwrite a file before removing it. On SSDs, copy-on-write file systems, or with snapshots and backups, it gives no assurance.

Warning: the next command permanently overwrites and deletes the named file. Check the path first.

# Check the exact file, its size and the file system it lives on
ls -l path/to/old-secret.txt
df -T path/to/old-secret.txt

# Overwrite three times (the default), add a final pass of zeros, then remove
shred -v -z -u path/to/old-secret.txt

On Windows, cipher /w "removes data from available unused disk space on the entire volume," per Microsoft, which catches clusters freed by earlier deletes on an HDD.

Warning: this writes over all free space on the volume that contains the path. Confirm the drive letter before you run it, and close programs that need disk space.

# Confirm which volume C:\ is and how much free space will be overwritten
Get-Volume -DriveLetter C

# Overwrite free space on the volume that contains C:\
cipher /w:C:\

On SSDs neither command reaches over-provisioned space or stale pages.

Step 5: Encourage the SSD to drop freed blocks

On Linux, fstrim tells the drive which blocks the file system no longer uses. This is not destructive to live data; it only discards free space.

# Discard unused blocks on all mounted file systems that support it
sudo fstrim -av

It is still a hint, not a sanitize.

Step 6: To sanitize an entire drive, use the drive's own commands

For a whole device that is leaving your control, the strongest non destructive option is the device's built in sanitize or secure erase, or cryptographic erase on a self encrypting or fully encrypted device. On Macs, iPhones, iPads and Android phones, use the vendor's documented erase or reset, which on current hardware destroys the media key.

On Linux, for drives you can remove from service, NVMe and SATA drives both expose sanitize features.

Warning: the commands below erase every byte on the target drive, cannot be undone, and will destroy the operating system if pointed at the boot disk. Boot from separate media, remove or disconnect drives you want to keep, back up anything you need, and confirm the device path and serial number immediately before running them.

# 1. Identify drives by model, serial and size. Match the serial to the physical label.
lsblk -d -o NAME,MODEL,SERIAL,SIZE,TRAN
sudo nvme list

# 2. Confirm nothing on the target is mounted
lsblk /dev/nvme1n1

# 3. Check that the controller reports sanitize support before trying it
sudo nvme id-ctrl /dev/nvme1 -H | grep -i -A6 sanicap

Warning: the next command erases the whole drive. Only run it after the three checks above match the drive you intend to erase.

# NVMe: start a crypto erase sanitize on the controller (0x04 = start-crypto-erase)
# Use 0x02 (start-block-erase) if crypto erase is not supported
sudo nvme sanitize /dev/nvme1 --sanact=start-crypto-erase

For SATA drives, hdparm exposes the ATA Security Erase commands. The man page labels these switches "DANGEROUS," and they only work if the drive is not in the "frozen" state, which many systems set at boot.

Warning: again, this erases the whole drive. Re-run the identification step and confirm the device path and serial before each command.

# Confirm the device, its serial, and that Security shows "not frozen"
sudo hdparm -I /dev/sdX | grep -i -E "serial|frozen|erase"

# Set a temporary security password, then issue the erase
sudo hdparm --user-master u --security-set-pass TempPass /dev/sdX
sudo hdparm --user-master u --security-erase TempPass /dev/sdX

Replace /dev/sdX with the verified device. After any sanitize, read back a sample of the drive to confirm it no longer returns the old data, and record what you did. Because the 2011 research found drives that reported success without erasing, verification is not optional for sensitive media. Where verification is impossible or the data is highly sensitive, physical destruction is the remaining option.

Step 7: Record it

NIST SP 800-88 Rev 2 frames sanitization as a program and points to the IEEE 2883 series for techniques. A minimal record states the device (make, model, serial), the method and technique used (for example "Purge, cryptographic erase via NVMe Sanitize"), who did it, when, and how it was verified. Our post on NIST 800-53 MP-6 media sanitization covers how auditors look at those records.

Where does each approach sit in Clear, Purge and Destroy?

NIST SP 800-88 Rev 2 (September 2025, superseding Rev 1 from December 2014) defines three methods:

• Clear applies logical techniques to all user addressable storage, protecting against simple, non invasive recovery through the normal interface. Overwriting with standard write commands, or a factory reset where rewriting is not supported, are Clear techniques.
• Purge makes recovery infeasible even with state of the art laboratory techniques while keeping the media potentially reusable. Dedicated sanitize commands (overwrite, block erase, cryptographic erase) are Purge techniques. NIST says Purge should be used instead of Clear when possible.
• Destroy makes recovery infeasible with laboratory techniques and leaves the media unusable: shredding, disintegration, incineration and similar. NCSC guidance for OFFICIAL level data specifies destruction to particles of 6 mm or less.

Rev 2 moves technology specific detail to the IEEE 2883 series, and says degaussing should not be used on SSDs.

The developer angle: rotation beats deletion

For developers, the files that matter are .env files, kubeconfigs, cloud credentials, private keys, registry tokens and debug database dumps. Their blocks, snapshots, backups, sync history and git history may all survive. You cannot prove every copy is gone. You can make them useless. Revoke and reissue the credential, and the copies are harmless strings. That is the same logic as cryptographic erase, applied to application secrets. Our post on whether backups contain plaintext secrets goes deeper on the backup side, and which files on a developer laptop hold credentials is a practical checklist of where to look. When a laptop leaves a person or a team, the developer laptop offboarding checklist pairs device sanitization with credential revocation. For consumer devices before sale, see factory reset smart devices before selling or giving them away.

Better still, keep secrets out of files: use the OS keychain, short lived tokens and a secrets manager.

Where Safeguard fits

Safeguard's fit here is indirect. It does not wipe disks, inspect deleted data, manage devices or scan files for secrets. It does software supply chain work: it scans repositories, container images and SBOM files for dependencies (safeguard scan --dir ., --image, --sbom), matches them against vulnerability databases, shows which projects contain a given component and version, applies reachability analysis, and evaluates policies and gates. When a machine is rebuilt or a project is restored from a backup or snapshot, old vulnerable dependency versions come back with the code. Scanning the restored project, using the local runner on your own machine, shows what came back before you start shipping from it again.

Common mistakes

• Treating delete as destruction. Delete removes a name, not data.
• Running multi pass overwrite tools on SSDs. NIST Rev 2 advises against it; they still miss stale pages.
• Forgetting snapshots. Local snapshots and shadow copies are designed to keep deleted files.
• Assuming encryption covers data written before it was enabled. Cryptographic erase only protects data that was encrypted when it was written.
• Keeping a recovery key and calling the reset a crypto erase. Any surviving key copy can still unlock the data.
• Trusting "erase successful" without verifying. Research found a drive that reported success and kept all data. Read back samples after sanitizing sensitive media.
• Skipping the device path check. Device names can change between boots. Match model and serial every time.
• Deleting a leaked credential instead of rotating it. Deletion is cleanup, not containment.

FAQ

Can deleted files be recovered after emptying the recycle bin?

Often, yes. The data blocks stay until reused. On an SSD with TRIM, recovery through the normal interface gets much less likely, but snapshots, backups and sync history may still hold copies.

Are deleted files on an SSD gone for good?

Not reliably. TRIM defeats simple recovery tools, but stale copies can sit in physical pages and over-provisioned space the host cannot address. Encryption at rest makes those leftovers unreadable.

Does formatting a drive erase the data?

A quick format writes new empty metadata and leaves old data in place. For sanitization, use the drive's sanitize command or cryptographic erase.

Does shred work on SSDs?

No, not with any assurance. The GNU shred manual says it assumes data is overwritten in place, which SSDs and journaling or copy-on-write file systems do not guarantee. Research on SATA SSDs found that file overwrite tools left between 4% and 75% of a file's contents recoverable from the flash chips.

What is cryptographic erase?

A NIST SP 800-88 Rev 2 Purge technique: if all data was encrypted when written, destroying the key makes it unrecoverable. It requires no earlier plaintext and no surviving key copies.

Is a factory reset enough before selling a phone or laptop?

For a current phone or Mac with encryption on from day one, the vendor's erase or reset destroys the media key, and the UK NCSC says that gives satisfactory assurance for most devices. First sign out of cloud accounts, remove activation locks and back up. Very sensitive devices may need a verified Purge or destruction.

How do I remove a file from Time Machine local snapshots?

You cannot edit a snapshot to remove one file. You can list local snapshots with tmutil listlocalsnapshots / and delete specific ones with tmutil deletelocalsnapshots followed by the snapshot date, which removes every file version in them. Apple says local snapshots are kept for up to 24 hours or until space is needed. Backups on your external Time Machine disk are separate and need their own handling.

I committed a secret to git and deleted it. Is it safe now?

No. It remains in earlier commits, clones and forks. Revoke or rotate it first, then rewrite history with git filter-repo if needed.

Fix it without waiting for upstream

Deleted file recovery is a storage problem, but the machines and backups involved are also where your software comes from. A rebuilt laptop or a project restored from last month's snapshot pulls its dependencies back in, often at the old versions, so the hygiene below still applies even though it does not touch the disk itself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos erase data or recover it; that work belongs to your operating system and your drive. They show the part that comes after a wipe or a restore: checking what software came back with your projects. To try them, download Safeguard and follow the CLI docs.

This demo sets up the Safeguard runner on your own machine, approves it with its device code, and then runs a scan from the terminal. After restoring projects onto a wiped or new laptop, this is the check that tells you which dependency versions came back with them, run locally on that machine.

Click through it at your own pace, or open it full screen.

This is a real CLI session: you ask the assistant to fix a lodash CVE in a repository, it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies when a project restored from an old backup or snapshot carries a stale, vulnerable dependency: you fix it with every step visible before you build from it again.

Click through it at your own pace, or open it full screen.

This demo is a real Android session that sends work to a computer running the Safeguard CLI and approves the command on the phone with Allow once, Allow for turn or Deny. It helps when you are rebuilding a machine and want each command on it approved deliberately, not run on autopilot.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025)
• NIST SP 800-88 Rev. 2, full text (PDF)
• Microsoft Learn: Master File Table
• Microsoft Learn: Volume Shadow Copy Service
• Microsoft Learn: cipher command
• Apple File System Reference (PDF)
• Apple Platform Security: Data Protection overview
• Apple Platform Security: Managed Lost Mode and remote wipe
• Apple Support: Erase your Mac and reset it to factory settings
• Apple Support: Back up your Mac with Time Machine
• Android Open Source Project: File-based encryption
• Linux kernel documentation: ext4 journal
• Btrfs documentation: Subvolumes and snapshots
• GNU shred manual page
• fstrim manual page
• hdparm manual page
• nvme-cli documentation: nvme sanitize
• Wei, Grupp, Spada and Swanson: Reliably Erasing Data From Flash-Based Solid State Drives, USENIX FAST 2011 (PDF)
• Halderman et al.: Lest We Remember, Cold Boot Attacks on Encryption Keys, USENIX Security 2008 (PDF)
• NCSC: Secure sanitisation of storage media
• GitHub Docs: Removing sensitive data from a repository

Last reviewed: 23 October 2026. Storage and operating system behaviour changes between versions; check the linked vendor pages for your exact version.