- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Lightshot vs. Snapshot
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lightshot vs. Snapshot
What is the difference between a Lightshot snapshot (new in R82) and a Snapshot.
The difference is not clearly explained in the new R82 documentation.
- My question is, what can the lightshot do better?
- Under what conditions should the different snapshot methods be used?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Let's share more information regarding lightshot:
1. Main benefit of lightshot is the disk space and time it takes to take it. while legacy snapshot will consume more than 12G per snapshot (on large scale VSX env even more than 30G) and can take quite few minutes to take it, lightshot will consume only the delta changes between last lightshot taken. time will be very fast if no big delta (can be less then 10 seconds as well).
2. each snapshot has his own separate partition while lightshot partition is common to all lightshots (mounted to /mnt/lightshot when needed)
3. The reason why all lightshots sits on same partition is because it work with linux hardlinks (which support only on same partition) so each file which is the same between lightshots will just increase the reference count to the inode of the file.
4. There is no problem to delete lightshot not by their order. holes are ok and each lightshot do not count on his previous.
5. lightshot is unique per the appliance. each appliance can restore his own ligtshots only.
6. lightshot is taken periodically every night (03:00) on scalable platform appliances. Total 5 periodic lightshots are taken and rotate every day.
7. first lightshot taken automatically is the fcd (8G above) and then we can see next one is 3G because it include all what installed as part of FTW. then the other are on this setup ~141MB each
8. There is an option to take lightshot of appliance directly on target ssh server. then when needed import from the remote ssh server and restore it (target option in the clish/gclish lightshot command)
Regards,
Shai.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just have sent a corresponding feedback to sk108902 😉 I will post the answer here...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @G_W_Albrecht,
Thanks for the info.
The R82 admininistartion guide contains less information to the following topics:
- What prerequisite must be given that I can restore the lightshot snapshot (same GAIA version and/or same Jumbo Hotfix)
- Is this an alternative to “Backup/Restore” or the classic Snapshot?
- Which method is better lightshot, snapshot or backup in the event of an software error /hardware replacement / upgrade?
- What is the best practices?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Answer from CP:
We will add the required information based on the R&D answer in
https://community.checkpoint.com/t5/General-Topics/Lightshot-vs-Snapshot/m-p/231080#M38579
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My understanding is that a lightshot allows you to add an additional lighter snapshot by backing up only the changed files on top of your previous full snapshot.
Say, you have one snapshot done before the change. It contains the full copy of your file system. Then you installed an HFA, and only some of the files were changed. To fix the current state, you can do a full snapshot or a lightshot. A snapshot will make another copy of your file system, thus doubling size of your backups. A lightshot only registers and saves the changed files which are not the same as in your previous snapshot, which is a more economical way of backups when you need to capture both binaries and config files.
I hope it make sense
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
THX, sounds plausible.
This information should be added to the R82 Administration Guide and sk108902.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Absolutely agree, Heiko, this is not documented in a clear manner.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only information can be found in R82 GAiA Admin Guide and here nothing is explained except the command syntax. Your explanation sounds good but does not really explain listed commands like:
|
Clones the lightshot snapshot from a remote Gaia server to this Gaia server. |
|
Creates a new lightshot snapshot.
|
In the last command, no "real" snapshot is mentioned upon lightshot creation, but only update of existing lightshot... I also find it confusing that lightshot is also called snapshot, making it hard to tell them apart.
What we find here is that:
- lightshots all are stored on a special lightshot partition
- you can diff two lightshots to see the differences
- lightshots can be restored during boot process
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had tested this under ElasticXL. But it's not really clear to me where I can see after which snapshot the lightshots were created:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As cited above:
Observing ElasticXL adding new cluster members
‘Lightshot’ (a snapshot alternative in R82) is used for copying image, JHFs, HFs,
configuration and policy to the joining member(s)
"Alternative" does not sound like additional tool for snapshots, and it is only mentioned in the ElasticXL context !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad you posted about it. I also noticed that in the lab, but had not looked into it further.
I also found below link, but it gives similar explanation to what you provided.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In this presentation, we only learn that:
Observing ElasticXL adding new cluster members
‘Lightshot’ (a snapshot alternative in R82) is used for copying image, JHFs, HFs,
configuration and policy to the joining member(s)
As it is called a snapshot alternative i would rather not assume that the above explanation is correct - you would have to use a real snapshot for a lightshot, and that is not mentioned here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Let's share more information regarding lightshot:
1. Main benefit of lightshot is the disk space and time it takes to take it. while legacy snapshot will consume more than 12G per snapshot (on large scale VSX env even more than 30G) and can take quite few minutes to take it, lightshot will consume only the delta changes between last lightshot taken. time will be very fast if no big delta (can be less then 10 seconds as well).
2. each snapshot has his own separate partition while lightshot partition is common to all lightshots (mounted to /mnt/lightshot when needed)
3. The reason why all lightshots sits on same partition is because it work with linux hardlinks (which support only on same partition) so each file which is the same between lightshots will just increase the reference count to the inode of the file.
4. There is no problem to delete lightshot not by their order. holes are ok and each lightshot do not count on his previous.
5. lightshot is unique per the appliance. each appliance can restore his own ligtshots only.
6. lightshot is taken periodically every night (03:00) on scalable platform appliances. Total 5 periodic lightshots are taken and rotate every day.
7. first lightshot taken automatically is the fcd (8G above) and then we can see next one is 3G because it include all what installed as part of FTW. then the other are on this setup ~141MB each
8. There is an option to take lightshot of appliance directly on target ssh server. then when needed import from the remote ssh server and restore it (target option in the clish/gclish lightshot command)
Regards,
Shai.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @ShaiF for the detailed description.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the first fcd snapshot a full snapshot or is it based on the basic R82 installation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The first lightshot taken (call fcd) is based on your clean installation before running the first time wizard. It will be like full legacy snapshot size (~ 8G) and taken automatically for you on SP environments(maestro/ElasticXL).
This lightshot is used to clean your appliance in case you remove the member from the cluster.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @ShaiF,
According to your descriptions, the lightshots also make more sense to me.
PS:
This might also be helpful for newly installed single gateways, ClusterXL GW and VSX GW.
When the first config wizard is completed, you could automatically create an fcd snapshot.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if i understand correctly, de-duplication landed on Gaia OS, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
