I haven't read the beginning of the thread yet, but. I would just like to voice a feeling that personally I do not like snapshots at all. I have used them in LVM (thin) but I consider them risky. They are really not my style. They are basically volume or partition operations in a general sense that you use on a day-to-day basis. I know Windows does it too and yes I have used Windows snapshots and I have always not really liked it. I can see the advantage of making filesystem backups without disrupting e.g. databases, of course, but then still. Every one of those things could be designed around with better software that feels more like a real backup or an investment in software systems that can actually maintain their congruent state. System restore seems to be a call for "oh, let's forget about that, people can revert anyway". "Who cares if the system is fail-safe, we have a fail-safe right there!" "Our programs fuck up your computer? Don't worry! You can always get back to a previous state!" Time machine!. It was also my gripe with the only usable method for me to use Git (on a sidenote): you create backups of your git+data folder because reverting a backup is easier than reverting an actual destructive or possibly destructive action performed in Git. And I don't like that model. It gives incentives for bad software products because a disaster recovery mechanism is in place. You can easily see how much more Shoddy Windows has become since for example Windows XP/Windows 2000. With Windows 10 being a disaster full of bugs that bring it on par with a Kubuntu 15.10 daily update breaking a system by rendering it unbootable (just like, Yesterday). So people are like, oh we can't really make the SYSTEM function well, we will just ensure that any big error can easily be recovered from by going back in time. So you get a system that does what people can't do, you usually can't go back in time. You usually have to live with your mistakes, in that sense, and try to correct them or create a working state again. I wonder if the Universe itself contains a state-based backup. What does it do when something breaks down? Some books say that a person can go back in time slightly when they experience a near-death experience so as to divert a course of action that would lead to their death, if they don't want to die yet (on the 'other side'). But in general I think you can't do that and your efforts should be on a well-designed, safe, and invulnerable system that doesn't just blow up when you press the wrong button. (Like the bombs at the attacks in Brussels did. One went off after the fact when police had already cleared the area). Git itself is the most unusable system I have ever used. It tops Linux by a fairly large margin as well. Git is like an NGO: 95% of resources go to upkeep and maintenance, and only 5% gets put to actual use ;-). So that's just what I am saying, that snapshotting is in essence not a satisfactory thing and just a roundabout way to make a system function that is otherwise horribly broken. Instead of fixing the system, you ensure that it can't hurt you anymore - so bad. Like Sandboxing - Windows doesn't have sandboxing unless you buy some commercial tool. Sandboxing is one of the easiest things ever to implement and achieve, it's actually easier than letting software impact the system directly and then deal with the resulting mayhem. Every package should be its own circle, and these circles may overlap, and update-alternatives is a way to achieve that, choosing the circle that lies on top. Packaging in general is not perfect but it does allow for a definition of what the complete boundary of a collection of files belonging to the same unit, is. Maybe normally they don't keep to themselves and only affect their own circle: the entire system is affected. But nonetheless, conflicts that would be allowed in a circle-overlap system, are now simply resolved. In is nearly similar in the sense that the circles now do not overlap, but you just ensure that there aren't a great deal of circles that actually touch each other. If one offends, you throw it out and you have a conflict. Packaging by definition is a revertable thing, any action can normally be undone and so the system in principle is always in a consistent state. That's the whole idea of it anyway. It nears the idea of a sandbox because actions and changes are getting registered. Whereas if you have some "make install" script that is the opposite of a sandbox. And if the tools are right, the methods used are proper, and the definitions are okay, an empowered user would be able to solve any difficulties that may arise provided the dependencies etc., there are no errors in the packages themselves. It all stands on that. Cause instead of having a million files, you only have a 1000 packages, like that. But now systems are allowed to go bankrupt because we can go back in time anyway. Tools to revert (or progress) to a new stable state are no longer needed. Just go back in time. Problem solved. You mess up? Go back in time, it is easier than actually trying to solve a problem. Op 25-3-2016 om 00:39 schreef Richard Brown:
On 24 March 2016 at 22:32, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2016-03-24 at 17:00 -0400, Anton Aylward wrote:
But there are other forms of a failure of Integrity. There's a whole class of 'finger problems' that corrupt the data without corrupting its digital integrity. The best recording mechanism in the world can't do anything about that. its an "Oh my ${DEITY}! I've just overwritten the annual report with my resignation letter!". or perhaps not that catastrophic. Maybe you changed your mind about something you wrote and the "undo' only undoes this edit session, what you want is the version you wrote the day before yesterday. And this isn't VMS.
That's what I thought btrfs was for... on {home} it would be very useful. But snapshots are timed events, so they might not catch this. Not necessarily (in fact, IIRC on all current openSUSE distributions not-at-all, snapper only activates on YaST actions, zypper actions, and I think maybe booting, but that could be something I hacked together for myself and forgot about)
snapper has a number of other options to trigger based on user activity.. such as pam_snapper http://snapper.io/manpages/pam_snapper.html to create a snapshot for each user login and with the non-root users you can easily set up snapper to do whatever you want with your home directory https://lizards.opensuse.org/2012/10/16/snapper-for-everyone/
Conceptually, it's a simple as setting up a subvolume in btrfs, creating a snapper config for that subvolume, and then telling snapper to do it's thing whenever you want it to take a snapshot
(snapper snapshots single subvolumes and doesn't cross subvolume boundries.. hence the default configuration of '/ root' and all the default subvolumes openSUSE has to make sure those '/ root' snapshots only contain the operating system and no temporary/transient data
If you want to be particularly careful with a specific file, something like inotify could be used to make sure that snapper always takes a snapshot whenever a certain file is changed (note: If the file is changed a lot, you might need to tune snappers cleanup routines accordingly ;))
Regards,
Richard
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org