# Snapshot

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/snapshot

## Quick definition

A snapshot is like taking a quick photo of your computer's files or settings at a specific moment. You can use that photo later to go back to that exact state if something goes wrong. It saves space by only recording what changed after the photo was taken.

## Simple meaning

Think of a snapshot as a photograph of your computer's entire system at one exact moment. Imagine you are building a complex LEGO castle and you take a photo right after finishing the main tower. Later, if your little brother knocks over part of the castle, you can look at the photo and rebuild the tower exactly as it was. A snapshot works the same way for digital systems. When you take a snapshot of a virtual machine, a server, or even a database, you capture its current state, including all the files, settings, applications, and memory contents. The really clever part is that snapshots don't usually copy everything all over again. Instead, they record only the changes that happen after the snapshot is taken. This makes them fast and efficient. If something goes wrong, a bad software update, a virus, or an accidental deletion, you can use the snapshot to revert the system back to the exact moment you took the picture. Snapshots are commonly used in virtualization platforms like VMware and Hyper-V, in cloud services like AWS and Azure, and in storage systems like SAN and NAS. They are not the same as full backups because they often rely on the original data still being there. A snapshot is like a bookmark in time: it points back to your data at that moment, but it doesn't create a separate, independent copy unless you export it.

## Technical definition

A snapshot, in the context of IT networking and storage, is a point-in-time reference or copy of a storage volume, virtual machine, or database state. The technical mechanism depends on the platform but commonly involves a copy-on-write (CoW) or redirect-on-write (RoW) process. In a copy-on-write snapshot, when a snapshot is created, no data is immediately copied. Instead, the system marks the current blocks as protected. When a write operation targets a block that was present at snapshot time, the original block is first copied to a separate snapshot storage area before the write proceeds. This ensures the snapshot retains the original data. In a redirect-on-write approach, new writes are sent to a differencing disk or delta file, while the original disk remains untouched. The snapshot then represents the original data plus the chain of changes.

In virtualization environments such as VMware vSphere, a snapshot preserves the state and data of a virtual machine at a specific point. It includes the memory state (if selected), disk state, and power state. The snapshot creates a delta file (e.g., a -delta.vmdk in VMware) that tracks all writes made to the virtual disk after the snapshot was taken. The parent disk remains read-only. When reverting to a snapshot, the hypervisor discards the delta files and resumes using the parent disk. Snapshots are not meant for long-term backups because they can degrade performance and consume significant storage if left to grow over time.

In storage area networks (SAN) and network-attached storage (NAS), snapshots are often implemented using block-level or file-level cloning. Technologies like ZFS snapshots use a copy-on-write transactional model where the snapshot is a read-only point-in-time view of the filesystem. The snapshot shares data blocks with the active filesystem until those blocks are modified. This makes snapshots space-efficient and quick to create, often in milliseconds.

Database snapshots, such as those in Microsoft SQL Server, create a static, read-only view of the database at a given moment. They work at the page level: when a page is modified after snapshot creation, the original page is copied to the snapshot file. Queries against the snapshot will read from this copied page. Database snapshots are used for reporting on historical data or as a safeguard before applying schema changes.

Key standards and protocols related to snapshots include the Virtual Machine Disk (VMDK) format, the VHDX format for Hyper-V, and the Common Internet File System (CIFS) protocol for file-level snapshots in NAS. In AWS, EBS snapshots are stored in Amazon S3 and are incremental, only changed blocks are saved after the first snapshot. Azure uses managed disk snapshots for backup and disaster recovery, while Google Cloud Persistent Disk snapshots are global and can be used to create new instances. Understanding the underlying storage technology is critical for IT professionals, as misuse of snapshots can lead to data loss, performance issues, or unexpected costs.

## Real-life example

Imagine you are cooking a complicated pasta sauce from a recipe you found online. You start by adding tomatoes, garlic, onions, and herbs. You taste it and it is perfect, that is the moment you love. You are afraid you might accidentally add too much salt later or overcook it. So you take a small cup and scoop out a bit of the sauce exactly at this perfect point and set it aside. That little cup is your snapshot. It represents the state of the sauce at that ideal moment. Later, you keep cooking. Maybe you add too much chili and it becomes too spicy. No problem, you can use that saved cup of sauce as a reference. You even can mix it back into the pot to fix the taste. But you cannot use that cup to feed a large family because it is just a sample, not a whole new batch. A computer snapshot is very similar. It captures the exact state of a system, files, settings, memory, at one moment. You can use it to restore your system if something goes wrong later. But unlike a full backup, which is like freezing an entire pot of sauce, a snapshot is lightweight and fast. It only records what changed after the snapshot was taken, just like your cup only holds a small amount of sauce. The original pot (your main data) is still there. If you lose the pot entirely (like a hard drive failure), the snapshot alone cannot save you because it still depends on the original data. That is why professionals use snapshots mostly for quick rollbacks after a change, not as a standalone backup.

## Why it matters

Snapshots matter because they provide a fast and space-efficient way to protect data and recover from mistakes. In real IT environments, changes happen constantly, software updates, configuration modifications, new deployments. A single misconfigured setting can take down an entire application or expose a security vulnerability. With snapshots, an administrator can take a quick point-in-time capture before making a change. If the change goes wrong, they can revert in seconds. That is far faster than restoring from a full backup, which might take hours. Snapshots also support testing and development. A developer can take a snapshot of a production database, create a test environment from it, and run experiments without affecting live data. When the testing is done, the snapshot can be deleted. Cloud providers charge for storage based on data size, so the incremental nature of snapshots, storing only changed blocks, saves significant money. Many enterprises use snapshot capabilities in their backup strategies to create consistent copies of data across distributed systems. Snapshots also enable off-site disaster recovery. For example, AWS EBS snapshots can be copied to another region, so if one availability zone fails, the data can be restored in another region. However, snapshots are not immune to risk. If the original volume becomes corrupted and the snapshot depends on that data, the snapshot may also be compromised. Also, snapshots should not be used as a long-term backup solution because they can degrade performance if too many accumulate. IT professionals must understand when to use snapshots versus full backups, and how to manage snapshot lifecycles through automation and monitoring. In short, snapshots are a critical tool for any organization that values uptime, agility, and data safety.

## Why it matters in exams

Snapshots appear frequently in IT certification exams such as CompTIA A+, Network+, Security+, Server+, and cloud-specific certifications like AWS Solutions Architect, Azure Administrator, and VMware VCP. In CompTIA A+ (Core 2), snapshots are covered in the context of virtualization and backup methods. Candidates may need to identify the purpose of a snapshot, differentiate it from a full backup, and understand its role in system recovery. In CompTIA Network+, snapshots might appear in questions about SAN and NAS storage features, while in Security+, they relate to data availability and disaster recovery strategies. For cloud certifications, snapshots are a central concept. The AWS Solutions Architect exam (SAA-C03) tests knowledge of Amazon EBS snapshots, including how they work (incremental, stored in S3), how to share snapshots across accounts, and how to automate snapshot creation using AWS Backup or Lambda. Questions may ask which storage option supports snapshots, the difference between snapshots and AMIs, or how to restore data from a snapshot to a different availability zone. In Azure exams, such as AZ-104 (Azure Administrator), candidates must understand Azure managed disk snapshots, how to create them, and how to use them to spin up new virtual machines. VMware VCP-DCV exams include deep dives into snapshot mechanics, including the impact on performance, the need for consolidate after reverting, and the best practices for snapshot creation (e.g., avoiding running multiple snapshots for extended periods). Exam questions often present a scenario, for example: A system administrator must test a software update but needs a quick way to revert if it fails. The correct answer is to take a snapshot before applying the update. Another common question type compares snapshots and backups: A company needs to retain data for one year with full independent copies, which is better? Backups. Traps include confusing snapshots with backups or assuming snapshots copy all data at creation. Knowing the specific implementation details of each platform is essential for scoring well.

## How it appears in exam questions

Questions about snapshots typically fall into three categories: scenario-based, configuration, and troubleshooting. In scenario-based questions, you are given a situation such as: A virtual machine experienced a failed update. The administrator needs to restore the VM to its previous state while minimizing downtime. The answer is to revert to a snapshot taken before the update. These questions test your understanding of when snapshots are appropriate. Configuration questions ask about the steps to create or manage snapshots. For VMware: Which file type is created when a snapshot is taken? Answer: a delta VMDK file. For AWS: How are EBS snapshots stored? Answer: incrementally in Amazon S3. You might be asked what happens to the performance of a virtual machine if you keep a snapshot for several months (answer: performance degrades because the delta file grows and the hypervisor has to track changes). Troubleshooting questions often present a symptom: An administrator notices that a VM's performance has decreased significantly. After investigation, they find 10 snapshots older than 6 months. What should be done? Answer: remove or consolidate the snapshots. Another common trap: A learner might think a snapshot is a full backup. In a question asking for a method to get a complete, independent copy of data that can survive a disk failure, snapshot alone would be wrong. The correct answer is a backup, because snapshots depend on the original disk. Another pattern: The question asks about recovery time. A snapshot restoration is much faster than restoring from backup because the data is still on the same disk or storage pool. But if the question involves data retention compliance (e.g., keep data for 7 years), snapshots are not suitable because they are not independent and may not support long-term retention without performance issues. Sometimes questions compare different snapshot methods: copy-on-write vs. redirect-on-write. For example: In which snapshot technique is the original data immediately copied to a separate storage area when a write occurs? Answer: copy-on-write. Learners must memorize these technical distinctions for vendor-specific exams. Finally, watch out for questions that test the ability to interpret snapshot storage costs. In cloud exams, you may be asked to calculate the cost of storing snapshots given the size of changed blocks after a baseline. Remembering that only changed blocks are stored after the initial snapshot is key.

## Example scenario

You work as a junior system administrator for a small company. The marketing team uses a virtual machine running Windows Server to host their internal file sharing and a small contact database. The marketing manager tells you that they plan to install a new customer relationship management (CRM) tool on Wednesday afternoon. They are worried it might conflict with the existing database. Your job is to make sure everything can be restored quickly if the installation fails.

Your company does not have a full backup system yet, but they do use VMware vSphere. You decide to take a snapshot of the virtual machine before the CRM installation begins. At 1:00 p.m. on Wednesday, you right-click the VM in vSphere and choose Take Snapshot. You name it "Before CRM Install" and also check the box to capture the memory state, so the exact running state is preserved. The snapshot is created within seconds. The marketing team proceeds with the installation.

Two hours later, the marketing manager calls you. The new CRM software is causing errors with the contact database, records are disappearing, and the application keeps crashing. They need to go back to how things were before. You open vSphere, select the VM, and click Revert to Current Snapshot, choosing the snapshot named "Before CRM Install." The VM is restored exactly to its state at 1:00 p.m., including the open applications and data in memory. After a quick restart, everything works perfectly. The marketing manager is relieved. You helped avoid hours of database recovery work. You also learned an important lesson: you should have taken a full backup as well, because if the disk had failed during the process, the snapshot alone could not have recovered the data. Next time, you will combine a snapshot with a proper backup.

## Common mistakes

- **Mistake:** Thinking a snapshot is a full, independent backup that can survive a hard drive failure.
  - Why it is wrong: A snapshot normally depends on the original disk data. If the original disk fails, the snapshot becomes useless because it only stored changed blocks or pointers to unchanged data that no longer exists.
  - Fix: Treat snapshots as quick rollback tools, not replacements for backups. Always maintain separate full backups on different media or locations.
- **Mistake:** Keeping many snapshots for months, thinking they are harmless.
  - Why it is wrong: Each snapshot creates a delta file that tracks changes. Over time, these files grow large and can degrade virtual machine performance significantly. The hypervisor must constantly reference multiple delta chains.
  - Fix: Delete old snapshots after you are sure you no longer need them. A best practice is to avoid having more than 2-3 snapshots per VM and to consolidate or remove them within a week.
- **Mistake:** Assuming snapshots capture data from all attached disks automatically.
  - Why it is wrong: Some virtualization platforms allow you to choose which disks to include in a snapshot. If you add a new disk after taking the snapshot, or if you exclude a disk, that data is not protected.
  - Fix: Always verify that all necessary virtual disks are included when taking a snapshot. Configure snapshot settings to include all disks by default.
- **Mistake:** Confusing a virtual machine snapshot with a backup of the entire host server.
  - Why it is wrong: A snapshot only captures the state of one VM. It does not protect the hypervisor operating system, configuration files, or other VMs on the same host.
  - Fix: Use host-level backup solutions or disaster recovery tools to protect the entire server. Snapshots are VM-specific, not host-specific.

## Exam trap

{"trap":"An exam question asks: 'A systems administrator needs to perform a major software upgrade on a virtual machine. The upgrade is known to sometimes cause data corruption. Which method provides the fastest recovery option?' The options include 'full backup to tape', 'snapshot', 'export the VM', and 'copy the virtual disk files'. \n\nMany learners choose 'full backup to tape' because it sounds thorough and permanent. But the question asks for the fastest recovery. Tape restore is slow. Snapshot revert is nearly instantaneous.","why_learners_choose_it":"Learners often equate data safety with full backups and view snapshots as less reliable. They do not focus on the 'fastest' criterion in the question.","how_to_avoid_it":"Read the question carefully and identify the key constraint. If the requirement is speed for a short-term rollback, snapshot is almost always the correct answer. Remember that snapshots trade independence for speed."}

## Commonly confused with

- **Snapshot vs Backup:** A backup is an independent copy of your data stored on a separate medium, such as tape, external drive, or cloud storage. A backup can survive the failure of the original disk. A snapshot is not independent, it relies on the original data still being accessible and is stored on the same system in most cases. Backups are for long-term retention and disaster recovery; snapshots are for quick, short-term rollbacks. (Example: If your computer's hard drive dies, a backup on an external hard drive can restore everything. If you only had a snapshot on the same drive, that snapshot would be lost too.)
- **Snapshot vs Clone:** A clone is an exact, independent copy of a virtual machine or volume that can run on its own. Unlike a snapshot, a clone does not depend on the original and uses its own storage. Cloning takes more time and space than creating a snapshot, but the resulting VM is fully separate. Snapshots are smaller and faster but not independent. (Example: Cloning a VM is like making a photocopy of a document, you have two separate copies. Taking a snapshot is like placing a bookmark in the original document.)
- **Snapshot vs Checkpoint (Hyper-V):** Hyper-V uses the term 'checkpoint' instead of snapshot. However, Hyper-V has two types: standard checkpoints (which work similar to VMware snapshots using save states and differencing disks) and production checkpoints (which use Volume Shadow Copy Service for application-consistent backups). In VMware, the term snapshot is used for both memory and disk captures. In exam context, you must know the Hyper-V terminology and the difference between standard and production checkpoints. (Example: In a Hyper-V question, if you see 'checkpoint', think 'snapshot.' A standard checkpoint is like a snapshot with memory capture; a production checkpoint creates a backup-consistent disk state without memory.)

## Step-by-step breakdown

1. **Initiate Snapshot Creation** — The administrator triggers the snapshot from the virtualization management console (e.g., vSphere, Hyper-V Manager, or cloud CLI). The system notes the current time and prepares to capture the state.
2. **Mark Data Blocks as Protected** — The hypervisor or storage system marks all current disk blocks as 'protected.' No data is copied yet. This marking ensures that when a write occurs to a protected block, the original data is preserved.
3. **Create Delta File (Copy-on-Write)** — When any write operation targets a protected block, the system first copies the original block to a delta file or snapshot storage area. Then the write proceeds. This ensures the snapshot always points to the original data at the moment of creation.
4. **(Optional) Capture Memory State** — If memory capture is selected, the hypervisor saves the VM's RAM contents to a file. This allows the snapshot to restore the exact running state, including open applications and unsaved data. Skipping memory capture makes the snapshot crash-consistent.
5. **Store Snapshot Metadata** — The system writes metadata that links the delta files to the parent disk, records the timestamp, and stores other attributes (name, description, VM ID). This metadata allows the hypervisor to understand the snapshot chain.
6. **Revert or Delete Process** — To revert, the hypervisor discards the delta file and resumes using the parent disk as it was at snapshot time. To delete a snapshot, the system merges the changes from the delta file into the parent disk, committing any new data that was written after the snapshot was taken.

## Practical mini-lesson

In practical IT work, snapshots are invaluable for change management. Before applying any patch, upgrade, or configuration change, good administrators always take a snapshot. However, understanding the limitations and management overhead is critical. Snapshots are not set-and-forget tools. Every snapshot creates a differencing disk that grows over time as writes accumulate. In VMware, for example, each snapshot creates a -delta.vmdk file. If you take multiple snapshots, the hypervisor must traverse a chain of these files to read data, which slows down performance. A VM with five snapshots is significantly slower than one with none. Professional best practice is to limit snapshots to a very short lifespan, days, not weeks, and to remove them as soon as the change is verified.

In cloud environments such as AWS, snapshots are a primary tool for backup and disaster recovery. EBS snapshots are stored in S3 and are incremental. This means the first snapshot captures a full set of blocks, but each subsequent snapshot only stores the blocks that changed. This reduces storage costs and creation times. When you delete a snapshot, only the data unique to that snapshot is deleted. If you have a chain of snapshots, the full recovery data is preserved across the remaining snapshots. However, there is a cost consideration: keeping many snapshots of the same volume can become expensive because each incremental snapshot still carries storage charges. IT professionals should implement lifecycle policies to automatically delete snapshots after a set retention period.

Another practical consideration is application consistency. A simple snapshot captures only disk and memory state, which is crash-consistent, like pulling the power cord. For databases, this might cause corruption if transactions were in flight. To get an application-consistent snapshot, you need to use tools like VMware Tools quiescence, Hyper-V production checkpoints with VSS, or AWS's ability to freeze I/O before snapshot. In practice, for any database workload, always enable application-consistent snapshots.

What can go wrong? If the storage pool runs out of space while a snapshot is active, the VM may pause or crash. If you attempt to delete a snapshot that has a large delta file, the merge process can take a long time and temporarily impact performance. If you have a chain of snapshots and the parent disk becomes corrupted, the entire chain is compromised. This is why snapshots are not backups. Always pair snapshots with true, independent backups stored off-site or in a different storage tier. Finally, know the command-line tools: in VMware, use the vsphere CLI or PowerCLI; in AWS, use the AWS CLI with `create-snapshot` and `delete-snapshot` commands; in Azure, use `New-AzSnapshotConfig`. Understanding these tools helps you automate snapshot management and avoid manual errors.

## Memory tip

SNAP: Stops Now, Allows Presto Revert, Snapshots stop changes so you can instantly revert back.

## FAQ

**Can a snapshot replace a full backup?**

No, a snapshot is not a replacement for a full backup. Snapshots depend on the original data and are usually stored on the same system. If the original disk fails, the snapshot is lost. Always use snapshots for quick rollbacks and backups for long-term data protection.

**Do snapshots slow down my virtual machine?**

Yes, especially if left for a long time. Each snapshot creates a delta file that the hypervisor must reference for read and write operations. Multiple snapshots or a very large delta file can cause noticeable performance degradation.

**How long can I keep a snapshot?**

Best practices recommend keeping snapshots for no more than 72 hours. For critical production VMs, remove the snapshot as soon as the change is verified. Long-lived snapshots increase the risk of performance issues and storage space exhaustion.

**What is the difference between a crash-consistent and an application-consistent snapshot?**

A crash-consistent snapshot is like pulling the power cord, it captures data at an arbitrary point, which may leave transactions incomplete. An application-consistent snapshot uses tools to flush buffers and complete pending transactions before the snapshot, ensuring data integrity for applications like databases.

**Are snapshots supported on physical servers?**

Traditional physical servers do not support native snapshots. However, storage arrays (SAN/NAS) may offer snapshot functionality at the storage volume level. Some backup software also provides snapshot capabilities for physical systems, but it is less common than in virtualized environments.

**Can I share a snapshot with another account or region?**

In cloud platforms like AWS, yes. You can share EBS snapshots with other AWS accounts or copy them to different regions for disaster recovery. In on-premises virtualization, snapshots are typically local to the hypervisor and cannot be easily shared without exporting.

## Summary

A snapshot is a point-in-time, space-efficient capture of a system's state, typically used in virtualized environments and cloud storage. It allows administrators to quickly revert to a known good state after a change goes wrong, making it an essential tool for change management, testing, and rapid recovery. However, a snapshot is not a backup. It depends on the original data and is best suited for short-term rollbacks, not long-term data retention. IT professionals must understand the specific implementation on each platform, including VMware, Hyper-V, AWS, and Azure, as this knowledge is tested in many certification exams. Common exam traps include confusing snapshots with backups, assuming they capture all data automatically, or keeping them indefinitely. By mastering snapshot mechanics, copy-on-write, delta files, memory capture, and lifecycle management, you can answer scenario-based questions correctly and use snapshots effectively in real-world administration. Remember: snapshots are fast, flexible, and powerful, but they demand discipline to manage.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/snapshot