Repository navigation
Conversation
Kuruyia
marked this pull request as draft
September 15, 2026 13:13
Author
|
I'm opening this PR as draft for now, mainly so we can assess whether we want to continue going with this implementation for LVM metadata backups. I'm more interested in reviews on the idea rather than the code for now. I also have a couple of question that currently prevent this PR from being marked as ready, on which I'd like some discussions. Opening those in separate comment threads below. |
Kuruyia
commented
Sep 15, 2026
Nambrok
force-pushed
the
3.2.12-8.3-devel
branch
from
September 18, 2026 14:11
acc492e to
087fc03
Compare
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
from
September 18, 2026 14:48
8bf6934 to
47233a0
Compare
Kuruyia
commented
Sep 23, 2026
Author
There was a problem hiding this comment.
After discussing with @Wescoeur @Nambrok, we decided to:
- Remove the specific support for the LINSTOR, EXT and XFS SRs
- Change the backup destination directory to a sub-directory of
/etc/sm/ - Keep the current backup retention policy and adjust it later on if needed
- Delete the backup directory on SR destroy
- Check if code can be refactored between this PR and the LINSTOR database backup code to share some of the implementation
Nambrok
force-pushed
the
3.2.12-8.3-devel
branch
from
September 23, 2026 15:22
3a2a643 to
643d0ba
Compare
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
from
September 24, 2026 08:52
47233a0 to
359d024
Compare
Wescoeur
force-pushed
the
3.2.12-8.3-devel
branch
from
September 24, 2026 10:32
643d0ba to
c302395
Compare
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
from
September 24, 2026 14:16
359d024 to
64eb310
Compare
Wescoeur
force-pushed
the
3.2.12-8.3-devel
branch
from
September 24, 2026 14:28
c302395 to
93648e6
Compare
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
from
September 25, 2026 08:27
64eb310 to
2aa9f70
Compare
Nambrok
force-pushed
the
3.2.12-8.3-devel
branch
from
September 25, 2026 08:39
93648e6 to
f60e4c5
Compare
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
3 times, most recently
from
September 30, 2026 08:53
451556a to
5299f58
Compare
This adds backing up the metadata of the LVM VGs that are managed by the SM. This is done by copying the metadata files that are generated by LVM commands in the `/etc/lvm/backup/` directory to an SM-controlled directory. This minimizes the impact on performance that backing up metadata incurs. The SM also manages the lifecycle of the backed up files by only keeping some amount of the most recent files. Backups are done *before* running LVM commands, since the `/etc/lvm/backup/` directory is expected to contain the current state of the VGs. Metadata backup only occurs when running commands that would modify the metadata of a VG/LV, such as creation, removal and resizing. It also occurs when changing some of a VG/LV attributes, but not all. For instance, volume (de)activation is a common attribute-changing operation that does not require metadata backup. The backed-up LVM metadata files are removed from the SM-controlled directory when the associated SR is destroyed. Signed-off-by: Alexandre Sollier <alexandre.sollier@vates.tech>
Kuruyia
force-pushed
the
aso/lvm_metadata_backup
branch
from
October 5, 2026 13:30
5299f58 to
cd01c96
Compare
This adds a new generic abstract base class, `BackupManager`, that can be inherited to implement file-based backup operations. This base class implements common logic for sorting backup files, creating new ones, and applying a retention policy based on keeping a certain amount of the newest backup files. Inheritors of this class need to provide the concrete implementations for backup file naming, backup file listing, and the backup operation. They can also provide an implementation for a custom per-backup file retention policy, which can be used to e.g. forcefully remove backup files that are considered invalid. This also updates the LVM metadata backup code to take advantage of this new base class. Signed-off-by: Alexandre Sollier <alexandre.sollier@vates.tech>
This ports the LINSTOR database backup code to the newly-introduced `BackupManager` base class. Current behavior has been kept whenever possible. Signed-off-by: Alexandre Sollier <alexandre.sollier@vates.tech>
Kuruyia
marked this pull request as ready for review
October 7, 2026 11:02
Author
|
Done applying all suggestions that were discussed a few weeks ago. Leaving this PR out of draft as I think it's ready for review. I'm keeping the first commit for now since I'm waiting to hear whether we want to keep the refactor part or not. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds backing up the metadata of the LVM VGs that are managed by the SM. This is done by copying the metadata files that are generated by LVM commands in the
/etc/lvm/backup/directory to an SM-controlled directory. This minimizes the impact on performance that backing up metadata incurs.The SM also manages the lifecycle of the backed up files by only keeping some amount of the most recent files. Backups are done before running LVM commands, since the
/etc/lvm/backup/directory is expected to contain the current state of the VGs.Metadata backup only occurs when running commands that would modify the metadata of a VG/LV, such as creation, removal and resizing. It also occurs when changing some of a VG/LV attributes, but not all. For instance, volume (de)activation is a common attribute-changing operation that does not require metadata backup.
The backed-up LVM metadata files are removed from the SM-controlled directory when the associated SR is destroyed.