Administration - ggRock
      Back to home
      1. ggCircuit Help Center
      2. ggRock User Manual
      3. Administration - ggRock

      How Writebacks and Snapshots work

      This article describes basic of ggRock diskless boot system, specifically how Writebacks and Snapshots are used to manage the Image changes

      What is a Writeback

      Writeback is a section of the ggRock Array that is responsible for storing all changes that a specific Machine has made since it was started.

      When a Machine starts it gets the Image in it's clean state, and the Windows starts generating files during boot that essentially represent the current state of the Machine. When you first boot your Machines you will have empty Windows. After you download, say, ggLeap installer on PC01 - the Writeback for PC01 will contain that data.

      Now, if you will shut boot any other Machine at the same time - that Machine will NOT have those ggLeap files. That is because the Writeback has not been applied. If you now reboot the PC01 - it will also be clean and identical to it's initial state.

      This way if a player makes any changes during their session it won't affect the next player, all you need is to reboot.

      Applying Writebacks

      When you are done with the applications you need to set up and you actually want to keep the changes made - you simply need to shut down your Machine and Apply Writebacks from the Machines screen:

      This action will create a Snapshot. You can read about it below. Essentially, it will apply your changes to the base image with an ability to roll back if needed.

      After you do that you'll be prompted to add a Comment to your Snapshot - it will help you identify the changes made later if you need it.

      You can Apply Writeback from any Machine, but only once it's turned off. If you start a Machine without applying Writeback you will lose your changes.

      Once you apply the writeback any machine that boots from that Image will contain the changes you've made.

      Keeping Writebacks

      Some software, namely ggLeap, requires your PC to reboot for the installation process to complete.

      In order to accommodate these cases you can enable Keep Writebacks advanced option for the Machine that you want to keep it's changes even after reboots:

      Bear in mind that if you have Keep Writebacks enabled then no changes applied to the base Image will be visible for the Machine that has this option enabled.

      Managing Snapshots

      Snapshots are essentially your "checkpoints" for the Image. Every time you Apply a Writeback from a Machine a Snapshot is generated.

      Once you Apply a Writeback the Snapshot generated will automatically become Activated. This means that every PC that boots after that will have the changes from that Snapshot.

      Latest Snapshot

      Latest Snapshot is, simply put, the Snapshot that was created after all other snapshots for a given reason. For simplicity sake we limit new Snapshot creation to only latest snapshot Machines.

      This means that you will NOT be able to Apply Writeback from a Machine that's not running the Latest Snapshot. Latest snapshot might not be Active,

      Active Snapshot

      Active Snapshot. This is the snapshot that all Machines will boot from. This isn't necessarily the Latest Snapshot. However, if the Active Snapshot is not Latest you will not be able to Apply Writebacks from it.

      Active Snapshot is needed if you want to roll back some of your Machines to a previous Snapshot for testing, debugging or other purposes.

      Writebacks and Snapshots Diagram

      The diagram below is mainly aimed at tech-savvy users who want to understand how exactly the Writebacks and Snapshots system works

      On the diagram above:

      1. OS Image is essentially a set of Snapshots, layered over one another. This way you can remove a Snapshot from the very bottom or middle of the list and ggRock will "stitch together" the changes, leaving the Image fully operational, just removing the extra data that was only present in the removed Snapshot

      2. OS Image Writebacks. Each PC creates a small section on the Array that stores all unique data associated with a specific Machine. Each Machine booting prompts ggRock to create that section automatically. These writebacks only store the data from the C:/ drive (OS Drive) in Windows

      3. Game Image. Same as the OS Image - a set of layered Snapshots

      4. Game Image. Same as OS Image Writebacks, but for the G:/ drive (or other driver letter designated by you)

      5. Game Image Read Operations. All machines do Read data from ggRock server (first through RAM Cache that can be read about here). No Writes are made to the Image, that allows us to very efficiently cache most frequently and recently accessed data to support hundreds of Machines.

      6. OS Image Read Operations. Same as Game Image Read Operations, only for the OS Image - C:/ drive

      7. A specific PC (PC-01 in this case) will be performing Write and Read operations to it's isolated Writeback space. OS Image PC-01 Writeback contains all changes from the PC-01 to the C:/ drive at any given time

      8. Same as (7) but for PC-02

      9. Same as (8) but for PC-100

      Applying Writeback Diagram

      When the user chooses to Apply Writeback they have to do their changes and then shutdown the Machine.

      1. Here you can see that PC02 has Apex Legends game files for the OS Image installed and stored in it's Writeback space

      2. Same as (1) but for the Game Image, presumably containing the game data itself

      3. Once the PC02 is powered down and Writeback is applied our OS Image. Our Snapshot is now created with comment Apex Install.

      4. Same as (3) but for the Game Image.

      Once that is done and user applied the Writeback - a new Snapshot is created and the Image, being a composite of all Snapshots, now contains the latest data. For other Machines to receive these changes one needs to reboot these Machines.