[arch-general] btrfs/snapper hook for pacman 5.0?
Hi all, now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet. Maybe I'm getting something wrong here, but in my understanding it should be doable and probably is even a cool feature that other distros / package managers already provide. Basically all we have to do is to create a snapshot before and after each pacman invocation. However, after having a look at the alpm-hooks(5) man page I'm not too sure what kind of trigger would make the most sense here. With the "recommended" btrfs / snapper subvolume layout, one could add triggers for paths that should be backed up (e.g. /, /var/, etc.). On the other hand the man page tells us that using the root directory as trigger path is not recommended. So has anyone already looked into this and has some thoughts on this? Best regards, Karol Babioch
On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
Hi all,
now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet.
What is the goal here? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, Am 01.02.2016 um 23:30 schrieb Leonid Isaev:
On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
Hi all,
now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet.
What is the goal here?
To have snapshots before and after pacman did any changes to the filesystem (i.e. upgraded packages), so one can easily rollback to a known good state in case of an error, and/or look at the difference between two snapshots to figure out what might cause an issue. You can find more information on snapper here [1]. There are appropriate hooks for aptitude and YaST, so I'm now looking into getting this functionality with Arch. Best regards, Karol Babioch [1]: http://snapper.io/
On 02/02/16 at 12:16am, Karol Babioch wrote:
Hi,
Am 01.02.2016 um 23:30 schrieb Leonid Isaev:
On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
Hi all,
now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet.
What is the goal here?
To have snapshots before and after pacman did any changes to the filesystem (i.e. upgraded packages), so one can easily rollback to a known good state in case of an error, and/or look at the difference between two snapshots to figure out what might cause an issue.
You can find more information on snapper here [1]. There are appropriate hooks for aptitude and YaST, so I'm now looking into getting this functionality with Arch.
Best regards, Karol Babioch
[1]: http://snapper.io/
Hi, Am 02.02.2016 um 01:32 schrieb Andrew Gregory:
thank you very much. This is basically exactly what I was looking for and I will have a play with it. By the way: When exactly and how often are the PreTransaction and PostTransaction actions executed? Are they executed for each and every package, or for each invocation of pacman itself, i.e. once per upgrade (of multiple packages)? Best regards, Karol Babioch
Hi, Am 02.02.2016 um 10:16 schrieb Karol Babioch:
When exactly and how often are the PreTransaction and PostTransaction actions executed? Are they executed for each and every package, or for each invocation of pacman itself, i.e. once per upgrade (of multiple packages)?
after having a play with this, I can answer my own question here: These hooks are indeed only invoked once per upgrade and are therefore perfectly suited for snapshotting. What a great feature ;). Best regards, Karol Babioch
do hook files need to end in .hook ? I couldn't find it mentioned in man alpm-hooks or pacman -- damjan
Am 02.02.2016 um 10:40 schrieb Damjan Georgievski:
https://github.com/andrewgregory/pachooks do hook files need to end in .hook ? I couldn't find it mentioned in man alpm-hooks or pacman
Yes, a hook ends in .hook, that should be mentioned somewhere. I had to check the sourcecode: https://projects.archlinux.org/pacman.git/tree/lib/libalpm/hook.c#n620 Lines: 620, 667-671
On 2 February 2016 at 10:40, Damjan Georgievski <gdamjan@gmail.com> wrote:
do hook files need to end in .hook ? I couldn't find it mentioned in man alpm-hooks or pacman
Also, `Exec =` requires a full path to the executable -- damjan
Hi, On Tue, Feb 02, 2016 at 12:16:53AM +0100, Karol Babioch wrote:
What is the goal here?
To have snapshots before and after pacman did any changes to the filesystem (i.e. upgraded packages), so one can easily rollback to a known good state in case of an error, and/or look at the difference between two snapshots to figure out what might cause an issue.
You can find more information on snapper here [1]. There are appropriate hooks for aptitude and YaST, so I'm now looking into getting this functionality with Arch.
Thanks. But /boot can not be snapshot with this, right? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, Am 02.02.2016 um 04:30 schrieb Leonid Isaev:
Thanks. But /boot can not be snapshot with this, right?
technically you can snapshot whatever you want. snapper can also (kind of) work with LVM and ext4, so btrfs is not an absolute requirement. Bootloaders can boot from btrfs. The only danger I can see is that you want to make sure that the booted kernel and initramfs lying around on /boot is consisted with the actually installed kernel. Otherwise you might be in for some trouble, when trying to load modules ... Best regards, Karol Babioch
However you may implement this feature please make sure that it takes care of the availabel disk space! Most people do only have limited space on their root partition and by making numerous snapshots your hard drive will be clobbered soon. Besides this the feature should stop automatically or ask for elder snapshots to be deleted before the max. drive fill reaches a certain percentage (f.i. 80%). As soon as your root partition gets filled by 100% you may not even be able to boot from it. Honestly thinking I can imagine there being an automatic restoration point for the last update only many consecutive updates being condensed for the same auto-restoration point on a single day, only. Anyway please do not leave many automatic restoration points hanging around. Elmar
Hi, Am 02.02.2016 um 14:15 schrieb Elmar Stellnberger:
However you may implement this feature please make sure that it takes care of the availabel disk space! Most people do only have limited space on their root partition and by making numerous snapshots your hard drive will be clobbered soon. Besides this the feature should stop automatically or ask for elder snapshots to be deleted before the max. drive fill reaches a certain percentage (f.i. 80%). As soon as your root partition gets filled by 100% you may not even be able to boot from it.
The good thing is that snapper is taking care of most of these issues. It will automatically remove snapshots (according to your configuration). pacman is also checking for available disk space before doing the upgrade. So for all practical means the combination of both should be good enough. Best regards, Karol Babioch
Am 2016-02-02 um 14:53 schrieb Karol Babioch:
Hi,
Am 02.02.2016 um 14:15 schrieb Elmar Stellnberger:
However you may implement this feature please make sure that it takes care of the availabel disk space! Most people do only have limited space on their root partition and by making numerous snapshots your hard drive will be clobbered soon. Besides this the feature should stop automatically or ask for elder snapshots to be deleted before the max. drive fill reaches a certain percentage (f.i. 80%). As soon as your root partition gets filled by 100% you may not even be able to boot from it.
The good thing is that snapper is taking care of most of these issues. It will automatically remove snapshots (according to your configuration).
pacman is also checking for available disk space before doing the upgrade.
So for all practical means the combination of both should be good enough.
Best regards, Karol Babioch
Hi all, The problem about it is that when a new snapshot is created no additional disk space becomes consumed immediately. Only on change of the given files a possibly huge amount of disk space can get allocated by Copy On Write. The problem about it is that the update tool does not know that changing one byte in file X will result in a full copy of that file structure and block. I am saying this because I have already run into the 100% disk space consumed issue with snapper and openSUSE a couple of years ago. Elmar
participants (6)
-
Andrew Gregory
-
Damjan Georgievski
-
Elmar Stellnberger
-
Karol Babioch
-
Leonid Isaev
-
ProgAndy