Timeshift question

Discussion
1

Hi all, :wave:

I´ve got a question regarding timeshift, to see whether I understand it correctly.

After installing my current system Linux Lite 6.2 on Jan 18, and after updating the system I let timeshift run for the first time.
After that I let it do a weekly snapshot and set it to keep two ones of them.
Later I decided to abandon weekly snaphots and perform them manually.

As a result I have two snapshots available at the moment: the first one is from Jan 18 (marked as “O” = manual snapshot) and the second one is from July 1, 2023 (also marked as “O”).

My question is: how crucial is it to keep the very first snapshot (the initial one) :question:
Is it possible to delete it and the second one would still work in case
of an emergency?

I guess it would make sense not to keep the first one (as it´s become pretty old by now); it would certainly be better to always keep the last two ones. :thinking:

Would this work?

Thanks a lot in advance and many greetings.

Rosika :slightly_smiling_face:

2

Hi Rosika,
Once again my answer is another question
Does timeshift do incremental snapshots, or is each snapshot an independent full copy?

Answer that, and you have the answer to your question.
I thought it was the latter… my concept of a snapshot is like a photocopy… contains everything.

Regards
Neville

3

Yes, we already talked about that in the past.
I´m not completey sure but you may of course be right, Neville.

Well, I´ll hopefully do a more thorough investigation this time and report back. :wink:

Besides: I was thinking…

… if I tried to delete the first snapsot from within the GUI and timeshift accepts the task then everything should be alright?
Otherwise it would be a case of “bad coding” of the programme, wouldn´t it :question:

Cheers from Rosika :slightly_smiling_face:

4

You could try renaming it temporarily, and see if timeshift still functions… ie can it still do a restore? You would have to be careful… restore to somewhere else, not onto your main system.

I think I would rather know exactly what timeshift does. Then the right thing to do becomes obvious.
Try asking gpt

1 Like
5

Good idea. I would take me a bit more time and effort to research that manually. :wink:

O.K. then:

  • first I asked how important it is to keep the very first snapshot.

In general, the initial system snapshot created by Timeshift is important as it captures the state of your system at the time of installation or initial configuration. It serves as a baseline from which you can restore your system to its original state if needed.

While it is technically possible to delete the initial snapshot and retain only the second one, there are a few considerations to keep in mind:

Restoring from the second snapshot: If you delete the initial snapshot, you would still be able to restore your system using the second snapshot from July 1, 2023.
However, keep in mind that this snapshot assumes the presence of the initial snapshot as a reference point. Deleting the initial snapshot might impact certain functionalities or dependencies that were present during the system’s installation.

Rollback to the initial state: If you encounter a critical issue or want to revert your system back to its original state, having the initial snapshot readily available can be beneficial. It allows you to roll back your system to the exact state it was in when you first installed it, avoiding any potential issues that might have arisen since then.

Considering these factors, it is generally recommended to keep the initial snapshot, along with the most recent snapshots, for a comprehensive backup strategy. This way, you have a recent snapshot for emergencies and the initial snapshot as a reference point for a complete system restoration.

If storage space is a concern, you may consider deleting older snapshots from the sequence but still retain the initial snapshot. This ensures you have a more recent backup while still maintaining the baseline snapshot.

This far it seems keeping the very first snapshot is at least recommended. :thinking:

  • then I asked:
    “Does timeshift do incremental snapshots, or is each snapshot an independent full copy?”

Timeshift has the capability to perform both incremental and full snapshots, depending on the settings and the underlying file system used.

By default, Timeshift uses the RSYNC algorithm for creating snapshots. This algorithm allows for incremental backups, where subsequent snapshots only capture the changes or differences from the previous snapshots. This approach helps save disk space by avoiding the need to duplicate unchanged files in each snapshot.

However, it’s important to note that the behavior of Timeshift can vary based on the file system used. Timeshift works seamlessly with file systems that support snapshotting, such as Btrfs and ZFS. In these cases, Timeshift can take advantage of the built-in capabilities of these file systems to efficiently create incremental snapshots.

On the other hand, if you are using Timeshift with a file system that does not support snapshots, such as ext4 [or ext3], it will still create snapshots, but they will be full snapshots. Each snapshot would contain a complete copy of all the files and directories.

Ah, now it´s getting interesting. I´m using ext3, so it´s full snaphots after all… :neutral_face:

  • I asked more about ext3:

Ext3 is another file system that does not natively support snapshots like Btrfs or ZFS. Therefore, Timeshift will also create full snapshots on an ext3 file system.

When using Timeshift with ext3, each snapshot will be a complete copy of all the files and directories at the time the snapshot was taken. There won’t be any incremental backup functionality available on ext3, as it lacks the inherent snapshot capabilities.

It’s worth noting that while Timeshift can still create full snapshots on ext3, the benefits of space-saving incremental backups won’t be available. Each snapshot on ext3 will require a complete duplication of the files, resulting in potentially larger disk space usage compared to file systems that support snapshots

  • now I asked about keeping just the last snapshot when using ext3:

You raise a valid point. If you are using Timeshift with ext3 and have a completely functional system at the time of the first snapshot, you may not necessarily need to retain the very first snapshot if you have subsequent snapshots that capture the system in a stable and updated state.

The primary purpose of keeping the initial snapshot is to have a reference point from which you can restore your system to its original state if needed. However, if you have subsequent snapshots that capture your system after updates and installations, those snapshots can serve as effective restore points as well.

In such a scenario, where you have subsequent snapshots that adequately represent the state of your system with updates and installed programs, you can choose to omit the very first snapshot and retain the most recent snapshots that reflect a stable and up-to-date configuration.

It’s important to ensure that the retained snapshots capture all the essential configurations and installed programs required for your system to function correctly. Regularly reviewing and updating your snapshots ensures that you have recent and relevant backups while still maintaining the necessary restore points.

So, if I understood ChatGPT´s explanations correctly:

  • I can very well delete the first snapshot (as I´m using the ext3 filesystem) and the subsequent snapshot would cover everything quite as well.

  • No incremental snapshots are taken as ext3 won´t support this functionality.

I guess we have covered the main points, then. :smiley:

Thanks a lot for your help, Neville.
Many greetings from Rosika :slightly_smiling_face:

1 Like
6

Wow, you got a comprehensive answer
The only issue you have is making sure you keep snapshots of the system when it is in a good state.
Full snapshots are easy to manage. I am glad it turned out that way. Its just like clonezilla, only it does filesystems instead of partitions.

1 Like
7

Yes, Neville, that´s the crucial part, of course.

I think a good strategy would be to use the system in a normal way for a week (or a few days at least) after the latest updates.
If it doesn´t present any problems by then I´d take a snapshot and can delete the previous (or the first) one…

Yes, it seems that way (at least for ext4, ext3 filesystems) . You´ve summed it up quite adequately, Neville. :+1:

Thanks again and many greetings.
Rosika :slightly_smiling_face:

P.S.:

I just let baobab (“a graphical disk usage analyzer for the GNOME desktop”) perform a scan of the timeshift folder:

kgw_timeshift
kgw_timeshift1228×759 174 KB

and as you can see here is the disk usage of the two snapsots:

  • initial snapshot: 10.4 GB
  • latest snapshot: 11.5 GB

This makes sense, as the latest one covers all updates and post-installed packages.

Plus: it should prove that timeshift with ext4, ext3 indeed deals with full snapshots. not incremental ones. :wink:

P.S.2:

After a while…

Hmm… :thinking: … I´m not quite sure about anything anymore.

Looking at the screenshot I realized in contrast to the overall size (which makes sense) there´s something odd about the “localhost” line:

  • initial snapshot: 318069 items
  • latest one: 276576 items

That´s odd.

Here it says:

In RSYNC mode, snapshots are taken using rsync and hard-links. Common files are
shared between snapshots which saves disk space. Each snapshot is a full system
backup that can be browsed with a file manager.

Could the hard links account for the fact that the latest snapshot has less items than the initial one :question:

In which case it might be wise to keep the initial snapshot after all… :thinking:

8

This might help. I found this on “It’s Foss Guide” to Timeshift.

  • RSync: Snapshots are taken using rsync and hard-links. Common files are shared between snapshots, which saves disk space. Each snapshot is a full system backup that can be browsed with a file manager.

I like Timeshift and have used it many times successfully. But for a major / important points of the my OS, like first checkpoint, before major updates, and before release upgrade, I feel a lot more comfortable have a standalone backup / restore procedure. I use CloneZilla for those.

Part of normal backup procedure includes weekly Timeshift (2) and a monthly CloneZilla backup.

1 Like
9

Hi Rosika,
That is all rather ambiguous

  • from the point of view of looking at it, each snapshot is a full backup
  • from the point of view of removing it, each snapshot is a muddle of new files and hard links to old files

So can you ever remove anything , without disabling everything that follows it?

The only way to clean up space would be to remove everything , and start again with
a new zero level snapshot

So did gpt get it wrong?

Regards
Neville

1 Like
10

I agree, especially after this discussion.
I think Borg is more promising than Timeshift… just not as popular

1 Like
11

Hi everyone, :wave:

thanks a lot for your input. :heart:

@easyt50 :

Thanks Howard.
Did you by any chance ever remove the initial snapshot at all? Or have you always kept that one?

Thanks also for the links. :heart:

@nevj :

I couldn´t agree more.

That´s at least what ChatGPT made us believe. I´m beginning to doubt that. :neutral_face:

You must be able to safely delete any previous snapshots:

  • I did quite a lot af additional reserach yesterday on the topic and the general opinion was that you could delete any snapshot at any time. Alas I don´t have the sources available at the moment.

  • timeshift itself provides a dedicated “delete” button for snapshots within its GUI

  • within GUI: click on any snaphot with right mouse button: it´s context menu also provides the delete option, even for the initial snapshot.

  • from CLI: man pages say:

timeshift --delete-[all][OPTIONS] [...]
Delete:
              --delete Delete snapshot.
              --delete-all Delete all snapshots.

I guess it would work like this:

If one deletes all snapshots except the last one the hard-link feature would render the last snapshot.

From @easyt50 ´s link:

If you delete the target file, you can still access its content through the hard link. It’s because both target file and hard link has the same inode and thus they point to the same data block.

So the last snapshot would have all files in it (no need for hard-links anymore, because no previous snapshot is available).

Of course, it just a guess. :thinking:

That of course is something you can do at all times. :+1:

It almost looks that way… :slightly_frowning_face:

That´s why I keep saying: "

Always take anything ChatGPT says with a grain of salt. Think about it and do some research. It may still act as a good starting point, though". :wink:

Thanks to all of you.
Cheers from Rosika :slightly_smiling_face:

12

Hi Rosika,
OK, if Timeshift does the delete, it might be capable of leaving behind anything that is hard linked to later snapshots
but
if you simply deleted the files with rm it could be a disaster

That might make sense

Regards
Neville

1 Like
13

Yes, I think that´s a good point.
Never delete anything with the rm command but only use timeshift´s built-in deletion mechanism, either within its GUI or from the command-line.

Cheers from Rosika :slightly_smiling_face:

14

I tested this hard link thing.

Created a text file called asdf.txt which has one line in it with “asdf”.

Then created a hard link to it like this.

ln asdf.txt xxx.txt

When I cat asdf.txt and xxx.txt they are the same.

Then I removed asdf.txt like this.

rm asdf.txt

When I then cat xxx.txt it still shows the contents of the file. An answer I see online is that this hard link points to the same inode as the original file does. Removing the file itself doesn’t affect the hard link it seems. It would affect a soft link.

Still, I would manage the snapshots from within Timeshift.

2 Likes
15

Hi @pdecker , :wave:

thank you for doing the experiment.

So you could confirm what we learned from @easyt50 ´s link:

If you delete the target file, you can still access its content through the hard link. It’s because both target file and hard link has the same inode and thus they point to the same data block.

As timeshift snapshots are taken using rsync and hard-links that´s good so far.

We were just wondering where this “same data block” resides.
Is it part of the initial snapshot?
And if it is: what happens to it if we delete the initial one and keep just the last one?

Yes, that´s certainly good advice. :+1:

Thanks a lot and many greetings from Rosika :slightly_smiling_face:

1 Like
16

Hi @Rosika,
I do not keep any of the old snapshots in Timeshift past a month or so. I figure that if a problem has not shown up after a month then I pretty safe. If not for some reason, I always have my monthly Clonezilla backups that goes back for at least 2 months. If for some reason something was so bad and I still did not notice it for over 2 months, then I would be a bit upset at myself and re-install Linux.

Have a nice day.
Howard

2 Likes
17

Hi Howard, :wave:

thanks for your input. :heart:

What do you do with older timeshift snapshots?
I guess you keep the initial one. What about the subsequent ones? Do you keep the latest and delete older ones?

Cheers from Rosika :slightly_smiling_face:

18

In the GUI for Timeshift under “Setting” I set up the number of Timeshifts I want for a day, week, month, and so on. Once the value is reached, the older ones are deleted automatically. The only Timeshifts I have to delete are the ones I create. Right now my oldest Timeshift snapshot is 06-14-23 which I did create before a large Mint update.

1 Like
19

Ah, I see.

I also used to set it to keep 2 weekly ones before I decided to create them manually.
I complete forgot about that. :blush:

Thanks for the clarification.

Thinking about it: if timeshift itself has a setting for automatically removing snapshots it should have a mechanism for seeing to it that no data blocks hard links point to are lost…

I´m right in the middle of discussion about that with ChatGPT and it seems it´s telling me nonsense again… :angry: .

Thanks a lot, Howard.
Cheers from Rosika :slightly_smiling_face:

1 Like
20

Update:

I confronted ChatGPT with the findings of our research here in the forum.
I was interested to see what it had to say now:

ChatGPT:

You are correct that the maintainer of Timeshift has provided specific information about the behavior of snapshots on file systems like ext4 and ext3.

According to the maintainer’s statement, when using Timeshift in RSYNC mode with file systems that do not natively support snapshots, such as ext4 and ext3, each snapshot is indeed a full system backup. However, the space-saving technique employed is through the use of rsync and hard-links.

Well, that was a given, but ChatGPT admitted the facts. :wink:

Then I asked about the intermediate snapshots:

ChatGPT:

If you have and keep the initial snapshot and then create additional snapshots (2, 3, 4, and 5), and later delete snapshots 2, 3, and 4, the remaining snapshots (initial and 5) would still retain the data blocks they originally captured.

However, it’s important to note that while snapshot 5 would contain all the changes that occurred after the initial snapshot, it would not specifically encompass the changes made in snapshots 2, 3, and 4. Each snapshot is a unique point-in-time backup that captures the system’s state at that moment.

When you delete snapshots 2, 3, and 4, the data blocks associated with those snapshots will be removed, potentially resulting in broken hard links and incomplete data references within the remaining snapshots.

While the initial snapshot provides the baseline, subsequent snapshots build upon that baseline by capturing the changes that occur over time. Deleting any intermediate snapshots may disrupt the continuity and integrity of the remaining snapshots.

If you want to maintain a complete and consistent backup history, it is generally recommended to retain the intermediate snapshots in addition to the initial and most recent snapshots. This ensures that you have a comprehensive record of the system’s state at various points in time.

If storage limitations are a concern, you can consider reducing the frequency of snapshots or adjusting the retention policy to strike a balance between storage usage and maintaining an adequate backup history

If that was true, everything would be getting from bad to worse… :frowning_face:

So my final question was:

me:

Right. I understand what you are telling me, ChatGPT, but there´s still something I cannot understand: In the GUI for Timeshift under “Setting” I set up the number of timeshifts I want for a day, week, month, and so on.
Once the value is reached, the older ones are deleted automatically. See, that´s a setting timeshift itsel provides.
And if timeshift itself has a setting for automatically removing snapshots it should have a mechanism for seeing to it that no data blocks hard links point to are lost. Do you agree?

Ah, I now I wanted to see if ChatGPT had an answer to this one.
Here´s what it responded:

ChatGPT:

You bring up a valid point regarding the settings in the Timeshift GUI for automatically removing older snapshots. Timeshift does provide this feature to help manage disk space by automatically deleting older snapshots once the specified number is reached.

When Timeshift removes older snapshots, it does handle the cleanup process to ensure that any data blocks associated with those snapshots, which are shared through hard links, are not lost or orphaned. The cleanup process takes into account the dependencies between snapshots and the shared data blocks to maintain the integrity of the remaining snapshots.

While I don’t have access to the specific implementation details of Timeshift, it is reasonable to assume that Timeshift’s deletion mechanism is designed to handle the removal of snapshots and associated data blocks in a manner that preserves the integrity and functionality of the remaining snapshots. This would include properly managing the hard links and ensuring that no shared data blocks are lost or left unreferenced.

Therefore, you can rely on Timeshift’s automatic deletion feature, configured through the GUI settings, to handle the cleanup process appropriately and maintain the integrity of the remaining snapshots and their associated data blocks.

Aha, I think now we have it. :smile:

You have to ask and ask and ask… Not being satisfied with the first response ChatGPT offers seems to be of utmost importance… :wink:

Many greetings to all from Rosika :slightly_smiling_face: