Gcloud compute snapshot of re-created disk is not complete?

Question

I recently recreated a disk / vm image in google compute from a previous set of snapshots. Those snapshots are currently dated and sized as follows:

 - May 20     60 MB
 - May 21    372 MB
 - May 22    255 MB
 - May 23    118 MB
 - May 24     93 MB
 - May 25   1110 MB

After creating the disk I took the original source disk off-line (stopped the VM), made the new disk the boot disk, and started it. I then saved a machine image of it, and then did a manual snapshot. The new snapshot:

  May 25     16 MB

I don't have an image to verify, but I'm fairly certain the original May 20 snapshot was 300+ MB.

Questions:

1. As subsequent snapshots obsolete parts of existing snapshots, are the obsolete files "taken-out" of the preceeding snapshot? I.e. the snapshot is uncompressed, pieces removed, and then recompressed?

2. Why is the first snapshot of the newly created disk so small? It looks like it must be linked to the snapshot series of the disk from which it was created. Note: the snapshot schedule for the original disk was disconnected from it and re-used with the new disk.

3. What happens to the snapshot of the newly created disk if the series from the first disk is deleted? Is it invalidated? Or are the originals "rolled into it"?

Can someone explain to me what is going on?

Update 2020-05-27:

Subsequent investigations have revealed some behavior; still waiting to investigate more:

I successively deleted snapshots starting with the oldest, and observed the size of the others as they changed. Clearly snapshots are not read-only. When an old snapshot is deleted, something is merged into the subsequent remaining one:

 Sys-1 May 20    60 MB
 Sys-1 May 21   372 MB   380 MB
 Sys-1 May 22   255 MB   255 MB   463 MB
 Sys-1 May 23   118 MB   118 MB   118 MB   468 MB
 Sys-1 May 24    93 MB    93 MB    93 MB    93 MB   468 MB
 Sys-1 May 25  1110 MB  1110 MB  1110 MB  1110 MB  1110 MB  1130 MB
 Sys-2 May 25    16 MB    16 MB    16 MB    16 MB    16 MB    16 MB

The snapshot of the disk re-created from the original series of snapshots remained at 16 MB. When I feel sufficiently safe I will delete the last (May 25) backup of the original disk and see what happens to the snapshot(s) for the re-created disk.

Update 2020-05-29:

When the last snapshot of the original disk (Sys-1 May 25, 1130 MB) was deleted, nothing else changed. In particular, the 16 MB first-time snapshot of the recovery disk (Sys-2 May 25, 16 MB) did not expand. As a result, it appears that when a Disk-B is created from a machine image of Disk-A and snapshots of Disk-A are applied to Disk-B, then Disk-B is used to replace Disk-A in the VM, snapshots of the VM are likely to no longer be adequate for recovery:

 Sys-1 May 25  1110 MB  1110 MB  1110 MB  1110 MB  1110 MB  1130 MB
 Sys-2 May 25    16 MB    16 MB    16 MB    16 MB    16 MB    16 MB    16 MB

The only way I have managed to force what appears to be a full snapshot is as follows:

  VM-A  (running system)
  MI-A  Machine image created from VM-A at approx. desired snapshot time
  VM-B  (backup VM created from MI-A)
        When created, it is automatically started, unfortunately; stop it
  SS-B  Snapshot created from VM-B
        Delete VM-B

In the original scenario, this would by Sys-3; a manual snapshot made of it immediately after creation was 1.53 GB, which seems reasonable.

One unknown in the above events revolves around the VM name. The first replacement system (Sys-2) was attached to the original VM — Sys-1 was replaced in that VM with Sys-2. Since they were the same VM, the snapshot mechanism may have been confused. When Sys-3 was created, it was put in a new VM with no existing snapshot schedule.

Update 2020-05-29(2):

When looking at the snapshots again (~1 hr later?), I am now totally confused. The Sys-2 original snapshot of May 25 (formerly 16 MB) is now 1.52 GB. This was the 1st snapshot of a new disk (created from snapshots of the original disk).

Answer 1

Snapshots are incremental and automatically compressed. The first snapshot of a disk is a full snapshot that contains all the data on the disk. A subsequent snapshot only contains new or modified data since the previous snapshot. For reliability reasons, occasionally snapshots might capture a full image of the disk.

Snapshots are created at the block level. They are not aware of what happens at the file system level. However, certain file systems can "propagate" information about unused blocks to the devices (TRIM). This could help to reduce the snapshot size.

Although the snapshot size somehow correlates with the amount of changes in your DB tables atop of the file system and in the file system itself, from this point of view the snapshot size provides more valuable information for evaluating billing, as it helps to understand how much real storage space you consume.

Questions:

1. No. Snapshots are read-only copies of the data frozen at a certain moment. Snapshots are incremental by default. When a subsequent snapshot is created, nothing changes in the previous existing snapshot at the file system level.

2. The first snapshot of a disk is a full snapshot that contains all the data on the disk. Since a newly created disk is empty and snapshots are automatically compressed, it has a small size.

3. If we're speaking about two different disks: "the first disk" and "the newly created disk" (even though it was created "from a previous set of snapshots"), their snapshots are independent, and nothing will happen to the snapshots of the second disk if snapshots of the first one are deleted.

Compute Engine > Doc > Creating persistent disk snapshots

Formatting and mounting a persistent disk

Compute Engine > Doc > Restoring and deleting persistent disk snapshots > Deleting a snapshot