| Name | my-snaps JSON |
| Version |
1.0.5
JSON |
| download |
| home_page | |
| Summary | Simple BTRFS Snapshot Tools |
| upload_time | 2024-03-16 01:56:32 |
| maintainer | |
| docs_url | None |
| author | |
| requires_python | >=3.8 |
| license | |
| keywords |
btrfs
restore
snapshot
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
> **Minimal Quick Start:**
> * On python 3.11+, install `pipx`, else `pip`, and per your distro.
> * With `pipx`, run `pipx upgrade my-snaps || pipx install my-snaps`
> * With `pip`, run `pip install --upgrade my-snaps --user`
> * If `~/.local/bin/` is not on your $PATH, then make it so.
> * Run `my-snaps`; for each subvolume that you wish to snapshot, create a snapshot with `=Update` suffix (and as many as you wish to keep normally).
> * Subsequently before updates, run `my-snaps` and type `r` (replace-all) to replace the eldest `=Update` snaps per subvolume with new snaps.
# my-snaps - Simple Tools for BTRFS snapshots
* `my-snaps` assists creating snapshots and replacing the snapshots for the simplest BTRFS use cases (e.g., just before software updates).
* `my-restore` assists restoring snapshots to back out changes to the system
**Prerequisites.** To use these tools, you must have an appropriate BTRFS setup:
* Your mounted top-level subvolume names must not contain '.' (i.e., periods).
* Your snapshot names must be one of the forms:
* `{subvolume}.{date-string}`
* `{subvolume}.{date-string}={label}`
* Your snapshots must reside in a top-level subvolume ending with "snapshots"; and it must normally be mounted at `/.snapshots`
* Labels define sets of snapshots that independently managed.
* **note**: you cannot use the characters "." or "/" in the snapshot names and labels
* Suggested labels:
* **=Update** - created prior to a system update
* **=Daily** - scheduled daily snapshots (and similarly for other periods)
Here is a compliant BTRFS setup showing it subvolumes/snapshots:
```
top-levels: eos@cache eos@home eos@log eos@my-opt eos@root eos@snapshots
eos@snapshots:
'eos@home.2024-01-13-093817=Update' 'eos@root.2024-01-10-174732=Update'
'eos@home.2024-01-14-085102=Daily' 'eos@root.2024-01-13-084102=Daily'
'eos@home.2024-01-15-201554=Update' 'eos@root.2024-01-13-093817=Update'
'eos@my-opt.2024-01-13-093817=Update' 'eos@root.2024-01-14-085102=Daily'
'eos@my-opt.2024-01-14-085102=Daily'
```
**Installation.**
See the Quick Start. After install, run some tests per "Initial and Regression Testing"
---
## my-snaps
`my-snaps` can be used for simple snapshot maintenance. After running, it may look like this:
<!---  -->
* In the header, the BTRFS partitions are shown with `df -h` info (showing Size, Used, Avail, Use%, and Mounted on); run df separately to remind you of the fields when needed.
* On your very first run, highlight each subvolume for which you wish snapshots, and press `s` to create one (use one of your standard labels)
* `r` replaces your eldest snapshot of the same label for each top-level subvolume that has any snapshots.
* `a` replaces a snapshot of the same label for each top-level subvolume that has any snapshots.
* to describe snapshots, add a short label when prompted (e.g., "=Update").
* `d`: to remove highlighted subvolume (usually pick a snapshot); you cannot remove mounted subvolumes; if there are nested subvolumes, those are removed too.
* `u`: to get disk usage (this can take quite a while and is not perfect)
* `?`: to get help on all keys and navigation
**NOTE**: actions often require confirmation to ensure accidental keystrokes do not clobber your system.
**Non-interactive use**: `my-snaps` can be run non-interactively with these options:
* `-p` or `--print` dumps your top-level subvolumes and their snapshots
* `-s{N}` or `--add-snap-max={N}` adds a new snapshot for each subvolume with snapshots and removes the eldest until there are no more than `{N}`.
* `-l{label}` or `--label={label}` to set the label of the snapshots involved.
* `--cron={period}` adds an `anacron` job to add snapshots at the given period with appropriate defaulted `-s` and `-L` or you can specify those. Notes:
* `anacron` must be installed ... it is usually bundled in of a `cron` package such as `cronie`.
* jobs are stored in `/etc/cron.{period}/{period}.snaps`. To change jobs settings, edit those or just reinstall with new options.
* each time the job is run, its output goes to `/tmp/.my-snaps-{period}.txt`
* removal of the `anacron` jobs is done manually
---
## my-restore
`my-restore` is used to restore one or more of your snapshots. When launched, you see something like this:
<!---  --->
Choose the desired BTRFS partition to mount on `/mnt` (after running `umount /mnt` if occupied).
Next you'll see a screen like this:
<!---  --->
* Highlight and press enter on the desired choice to effect the given action:
* **restore**: promotes the snapshot to current
* **revert**: moves the reversion back to current
* **del**: deletes the reversion; **note**: delay deletion until a restore passes muster.
* when done with restores, reboot the system.
* to verify what would be done when choosing an action, you can put the tool in "dry-run" mode.
**Theory**: To restore a snapshot of the subvolume called "{subv}":
* normally, {subv} is renamed "{subv}.YYYY-MM-DD-HHMMSS=Reverted"; buf, if already reverted, {subv} simply removed, and
* secondly, a new, writable {subv} is created from the chosen read-only snapshot.
**------------- IMPORTANT NOTES -------------**
**When a restore is tested and deemed satisfactory then clean up.**
* To clean up, launch `my-snaps` or `my-restore` and delete "=Reverted" subvolumes.
* **Warning**: Failing to clean up will confuse the next `my-restore` and waste space.
**When a restore is tested and deemed unsatisfactory:**
* Launch `my-snaps` and adjust the restored snapshots as desired (e.g., restore a different snapshot or revert the reverted tip).
* Then reboot, test, and iterate until you are done and then clean up.
**In the case that an update or restore will not boot, then**:
* boot the live installer.
* install these tools per the instructions.
* use `my-restore` to return to a working system and reboot and eventually clean up the reverted subvolumes on the installed system.
---
## Initial and Regression Testing
Do not assume the BTRFS scripts work for you and then be in a pickle later. After install:
* Run `my-snaps` and ensure:
* all the top-level subvolumes are showing, and
* the expected snapshots are showing, and
* add snapshots for the volumes you may wish to restore.
* If `my-snaps` is working, run `my-restore` and, after device selection, that the "restore" entries look right, and
* If all looks well, restore and then revert one of your subvolumes (returning all subvolumes as they were).
If there are issues, ensure snapshots are in a subvolume ending with `@snapshots` which is normally mounted at `/.snapshots`, and snapshots are named `{subvol}.{timespec}[=Label]` where `{timespec}` has only numbers, dashes and colons.
If you installed periodic snap scripts:
* test with `sudo run-parts --debug -v /etc/cron.daily` (or whichever directory)
* run `ls -ltr /tmp/.my-snaps-*` to check that it was run recently by looking at timestamps.
---
## Best Practices for Using this Simple Snapshot Strategy
* `my-snaps` and `my-restore` support the most simple BTRFS snapshot strategy (for update protection and limited file recovery). To guard against huge catastrophes, add complementary strategies such as these so you can quickly reinstall if needed:
* keep your important document it the cloud (e.g., Google Drive)
* keep critical configuration on github (e.g., using [How to Store Dotfiles - A Bare Git Repository | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/dotfiles) or a dotfile manager).
* create a list or script of post-install tasks to add/remove apps (save with your dotfiles or in the cloud)
* BTW, the above complementary strategies have even more value if you have multiple installs (e.g., a desktop, a 24/7 server, and a few laptops all running similarly with the same apps an basic config).
* For more comprehensive protection, consider `snapper`, `btrbk`, `btrfsmaintenance`, and google for others.
---
## Special Behavior for BTRFS + Systemd-boot + pacman + dracut
In the titled cirumstance, BTRFS snapshots of root will not boot. Something like:
> Booting a live installer, mounting the BTRFS subvols
> and /efi, and running `reinstall-kernels` is needed
> (plus some /efi cleanup).
To get around that, first setup a pacman hook to copy /efi to /.efi-back when the kernel is updated:
```
# place in /etc/pacman.d/hooks/95-efibackup_post.hook
[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Path
Target = usr/lib/modules/*/vmlinuz
[Action]
Depends = rsync
Description = Backing up post /efi...
When = PostTransaction
Exec = /usr/bin/bash -c 'rsync -a -H --del /efi/ /.efi-back/'
```
Then, when replacing the root subvolume, /efi will be restored from its /.efi-back if that directory exists.
Raw data
{
"_id": null,
"home_page": "",
"name": "my-snaps",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": "",
"keywords": "BTRFS,restore,snapshot",
"author": "",
"author_email": "Joe Defen <joedef@gmail.com>",
"download_url": "https://files.pythonhosted.org/packages/41/0b/e84f77db4439152b63d50195cdc42f7bb768603d007c9ea8495278ab6516/my_snaps-1.0.5.tar.gz",
"platform": null,
"description": "> **Minimal Quick Start:**\n> * On python 3.11+, install `pipx`, else `pip`, and per your distro.\n> * With `pipx`, run `pipx upgrade my-snaps || pipx install my-snaps`\n> * With `pip`, run `pip install --upgrade my-snaps --user`\n> * If `~/.local/bin/` is not on your $PATH, then make it so.\n> * Run `my-snaps`; for each subvolume that you wish to snapshot, create a snapshot with `=Update` suffix (and as many as you wish to keep normally).\n> * Subsequently before updates, run `my-snaps` and type `r` (replace-all) to replace the eldest `=Update` snaps per subvolume with new snaps.\n\n# my-snaps - Simple Tools for BTRFS snapshots\n* `my-snaps` assists creating snapshots and replacing the snapshots for the simplest BTRFS use cases (e.g., just before software updates).\n* `my-restore` assists restoring snapshots to back out changes to the system\n\n**Prerequisites.** To use these tools, you must have an appropriate BTRFS setup:\n* Your mounted top-level subvolume names must not contain '.' (i.e., periods).\n* Your snapshot names must be one of the forms:\n * `{subvolume}.{date-string}`\n * `{subvolume}.{date-string}={label}`\n* Your snapshots must reside in a top-level subvolume ending with \"snapshots\"; and it must normally be mounted at `/.snapshots`\n* Labels define sets of snapshots that independently managed.\n * **note**: you cannot use the characters \".\" or \"/\" in the snapshot names and labels\n * Suggested labels:\n * **=Update** - created prior to a system update\n * **=Daily** - scheduled daily snapshots (and similarly for other periods)\n\nHere is a compliant BTRFS setup showing it subvolumes/snapshots:\n```\ntop-levels: eos@cache eos@home eos@log eos@my-opt eos@root eos@snapshots\n\neos@snapshots:\n'eos@home.2024-01-13-093817=Update' 'eos@root.2024-01-10-174732=Update'\n'eos@home.2024-01-14-085102=Daily' 'eos@root.2024-01-13-084102=Daily'\n'eos@home.2024-01-15-201554=Update' 'eos@root.2024-01-13-093817=Update'\n'eos@my-opt.2024-01-13-093817=Update' 'eos@root.2024-01-14-085102=Daily'\n'eos@my-opt.2024-01-14-085102=Daily'\n```\n\n**Installation.**\nSee the Quick Start. After install, run some tests per \"Initial and Regression Testing\"\n\n---\n\n## my-snaps\n`my-snaps` can be used for simple snapshot maintenance. After running, it may look like this:\n\n\n<!---  -->\n\n* In the header, the BTRFS partitions are shown with `df -h` info (showing Size, Used, Avail, Use%, and Mounted on); run df separately to remind you of the fields when needed.\n* On your very first run, highlight each subvolume for which you wish snapshots, and press `s` to create one (use one of your standard labels)\n* `r` replaces your eldest snapshot of the same label for each top-level subvolume that has any snapshots.\n* `a` replaces a snapshot of the same label for each top-level subvolume that has any snapshots.\n * to describe snapshots, add a short label when prompted (e.g., \"=Update\").\n* `d`: to remove highlighted subvolume (usually pick a snapshot); you cannot remove mounted subvolumes; if there are nested subvolumes, those are removed too.\n* `u`: to get disk usage (this can take quite a while and is not perfect)\n* `?`: to get help on all keys and navigation\n\n**NOTE**: actions often require confirmation to ensure accidental keystrokes do not clobber your system.\n\n**Non-interactive use**: `my-snaps` can be run non-interactively with these options:\n* `-p` or `--print` dumps your top-level subvolumes and their snapshots\n* `-s{N}` or `--add-snap-max={N}` adds a new snapshot for each subvolume with snapshots and removes the eldest until there are no more than `{N}`.\n* `-l{label}` or `--label={label}` to set the label of the snapshots involved.\n* `--cron={period}` adds an `anacron` job to add snapshots at the given period with appropriate defaulted `-s` and `-L` or you can specify those. Notes:\n * `anacron` must be installed ... it is usually bundled in of a `cron` package such as `cronie`.\n * jobs are stored in `/etc/cron.{period}/{period}.snaps`. To change jobs settings, edit those or just reinstall with new options.\n * each time the job is run, its output goes to `/tmp/.my-snaps-{period}.txt`\n * removal of the `anacron` jobs is done manually\n\n---\n\n## my-restore\n`my-restore` is used to restore one or more of your snapshots. When launched, you see something like this:\n\n\n<!---  --->\n\nChoose the desired BTRFS partition to mount on `/mnt` (after running `umount /mnt` if occupied).\n\nNext you'll see a screen like this:\n\n\n<!---  --->\n\n* Highlight and press enter on the desired choice to effect the given action:\n * **restore**: promotes the snapshot to current\n * **revert**: moves the reversion back to current\n * **del**: deletes the reversion; **note**: delay deletion until a restore passes muster.\n* when done with restores, reboot the system.\n* to verify what would be done when choosing an action, you can put the tool in \"dry-run\" mode.\n\n**Theory**: To restore a snapshot of the subvolume called \"{subv}\":\n* normally, {subv} is renamed \"{subv}.YYYY-MM-DD-HHMMSS=Reverted\"; buf, if already reverted, {subv} simply removed, and\n* secondly, a new, writable {subv} is created from the chosen read-only snapshot.\n\n\n**------------- IMPORTANT NOTES -------------**\n\n**When a restore is tested and deemed satisfactory then clean up.**\n* To clean up, launch `my-snaps` or `my-restore` and delete \"=Reverted\" subvolumes.\n* **Warning**: Failing to clean up will confuse the next `my-restore` and waste space.\n\n**When a restore is tested and deemed unsatisfactory:**\n* Launch `my-snaps` and adjust the restored snapshots as desired (e.g., restore a different snapshot or revert the reverted tip).\n* Then reboot, test, and iterate until you are done and then clean up.\n\n**In the case that an update or restore will not boot, then**:\n* boot the live installer.\n* install these tools per the instructions.\n* use `my-restore` to return to a working system and reboot and eventually clean up the reverted subvolumes on the installed system.\n\n---\n\n## Initial and Regression Testing\nDo not assume the BTRFS scripts work for you and then be in a pickle later. After install:\n* Run `my-snaps` and ensure:\n * all the top-level subvolumes are showing, and\n * the expected snapshots are showing, and\n * add snapshots for the volumes you may wish to restore.\n\n* If `my-snaps` is working, run `my-restore` and, after device selection, that the \"restore\" entries look right, and\n* If all looks well, restore and then revert one of your subvolumes (returning all subvolumes as they were).\n\nIf there are issues, ensure snapshots are in a subvolume ending with `@snapshots` which is normally mounted at `/.snapshots`, and snapshots are named `{subvol}.{timespec}[=Label]` where `{timespec}` has only numbers, dashes and colons.\n\nIf you installed periodic snap scripts:\n* test with `sudo run-parts --debug -v /etc/cron.daily` (or whichever directory)\n* run `ls -ltr /tmp/.my-snaps-*` to check that it was run recently by looking at timestamps.\n\n---\n\n## Best Practices for Using this Simple Snapshot Strategy\n* `my-snaps` and `my-restore` support the most simple BTRFS snapshot strategy (for update protection and limited file recovery). To guard against huge catastrophes, add complementary strategies such as these so you can quickly reinstall if needed:\n * keep your important document it the cloud (e.g., Google Drive)\n * keep critical configuration on github (e.g., using [How to Store Dotfiles - A Bare Git Repository | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/dotfiles) or a dotfile manager).\n * create a list or script of post-install tasks to add/remove apps (save with your dotfiles or in the cloud)\n* BTW, the above complementary strategies have even more value if you have multiple installs (e.g., a desktop, a 24/7 server, and a few laptops all running similarly with the same apps an basic config).\n* For more comprehensive protection, consider `snapper`, `btrbk`, `btrfsmaintenance`, and google for others.\n\n---\n\n## Special Behavior for BTRFS + Systemd-boot + pacman + dracut\nIn the titled cirumstance, BTRFS snapshots of root will not boot. Something like:\n> Booting a live installer, mounting the BTRFS subvols\n> and /efi, and running `reinstall-kernels` is needed\n> (plus some /efi cleanup).\n\nTo get around that, first setup a pacman hook to copy /efi to /.efi-back when the kernel is updated:\n```\n# place in /etc/pacman.d/hooks/95-efibackup_post.hook\n[Trigger]\nOperation = Upgrade\nOperation = Install\nOperation = Remove\nType = Path\nTarget = usr/lib/modules/*/vmlinuz\n\n[Action]\nDepends = rsync\nDescription = Backing up post /efi...\nWhen = PostTransaction\nExec = /usr/bin/bash -c 'rsync -a -H --del /efi/ /.efi-back/'\n```\nThen, when replacing the root subvolume, /efi will be restored from its /.efi-back if that directory exists.",
"bugtrack_url": null,
"license": "",
"summary": "Simple BTRFS Snapshot Tools",
"version": "1.0.5",
"project_urls": {
"Bug Tracker": "https://github.com/joedefen/my-snaps/issues",
"Homepage": "https://github.com/joedefen/my-snaps"
},
"split_keywords": [
"btrfs",
"restore",
"snapshot"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "3c9bb3999ae06e3a3bbf10458d4d18bce477fb2ecadc033d8cbe9e6d86876abe",
"md5": "bab62ca1729623bfa1badfc1a35a9c0a",
"sha256": "d76e351ff5b12b6de81d0556beffe97b711f6e291e4a94b2b573a202b909c05f"
},
"downloads": -1,
"filename": "my_snaps-1.0.5-py3-none-any.whl",
"has_sig": false,
"md5_digest": "bab62ca1729623bfa1badfc1a35a9c0a",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8",
"size": 30322,
"upload_time": "2024-03-16T01:56:30",
"upload_time_iso_8601": "2024-03-16T01:56:30.403162Z",
"url": "https://files.pythonhosted.org/packages/3c/9b/b3999ae06e3a3bbf10458d4d18bce477fb2ecadc033d8cbe9e6d86876abe/my_snaps-1.0.5-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "410be84f77db4439152b63d50195cdc42f7bb768603d007c9ea8495278ab6516",
"md5": "f46cabe4a844871c3b3ebbc99839a0f9",
"sha256": "66a9fc401d0f976bd12bc691366d158840e63998eaf7f20df8d7ac2d33864b69"
},
"downloads": -1,
"filename": "my_snaps-1.0.5.tar.gz",
"has_sig": false,
"md5_digest": "f46cabe4a844871c3b3ebbc99839a0f9",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 223631,
"upload_time": "2024-03-16T01:56:32",
"upload_time_iso_8601": "2024-03-16T01:56:32.094443Z",
"url": "https://files.pythonhosted.org/packages/41/0b/e84f77db4439152b63d50195cdc42f7bb768603d007c9ea8495278ab6516/my_snaps-1.0.5.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-16 01:56:32",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "joedefen",
"github_project": "my-snaps",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "my-snaps"
}
