Streamlined backup and restore: Plannings

A system updates are the weakest point in the life cycle of a Fedora server. There is a possibility that afterwards the system will no longer be operational or will only be usable with errors. The aim is to establish a system that creates a backup of the system partitions within a very short time before an update and provides a reliable procedure for restoring the state before the update in case of problems. Particular consideration must be given to lodging in a remote data center without direct access to a terminal or USB ports.

Worksteps

Detailed definition of objectives and requirements
Research and analyze already available solutions
Decision on the path to take
Implementation

So far known possible options for checking are

timeshife
snapper
CalliopeSystem timeshift-autosnap-dnf5

Timeline: Should be implemented with release F45.

b) Streamlining regular Server backups

For regular Server backups we need a reliable, automated procedure including flawless restore. The Focus is on standalone servers without integration into a centralized backup management, but probably includes a cluster of standalone server. Particular consideration should be given to lodging in a remote data center without direct access to a terminal or USB ports as well as privacy of user data.

Worksteps

Detailed definition of objectives and requirements
Research and analyze already available solutions
Decision on the path to take
Implementation

A so far known possible options to check are

Duplicity
BackupPC
rsync+tar
ReaR

Timeline: Should be implemented with release F45.

c) Providing Backup Service for local network clients

We need a proven, reliable, easy to use, and automated management procedure of backup and restore. It may not be the ultimate procedure for everything, but a recommendable way for a wide spread use case including central service data, user's private date and databases.

Worksteps

Detailed definition of objectives and requirements
Research and analyze already available solutions
Decision on the path to take
Implementation

A so far known possible candidate to check is

UrBackup

Timeline: Should be implemented with release F46.

### Proposal The discussion so far suggests that the project should be divided into three separate projects. a) **Strengthening Server updates** A system updates are the weakest point in the life cycle of a Fedora server. There is a possibility that afterwards the system will no longer be operational or will only be usable with errors. The aim is to establish a system that creates a backup of the system partitions within a very short time before an update and provides a reliable procedure for restoring the state before the update in case of problems. Particular consideration must be given to lodging in a remote data center without direct access to a terminal or USB ports. **Worksteps** 1. Detailed definition of objectives and requirements 2. Research and analyze already available solutions 3. Decision on the path to take 4. Implementation So far known possible options for checking are * timeshife * snapper * CalliopeSystem timeshift-autosnap-dnf5 **Timeline**: Should be implemented with release F45. b) **Streamlining regular Server backups** For regular Server backups we need a reliable, automated procedure including flawless restore. The Focus is on standalone servers without integration into a centralized backup management, but probably includes a cluster of standalone server. Particular consideration should be given to lodging in a remote data center without direct access to a terminal or USB ports as well as privacy of user data. **Worksteps** 1. Detailed definition of objectives and requirements 2. Research and analyze already available solutions 3. Decision on the path to take 4. Implementation A so far known possible options to check are * Duplicity * BackupPC * rsync+tar * ReaR **Timeline**: Should be implemented with release F45. c) **Providing Backup Service for local network clients** We need a proven, reliable, easy to use, and automated management procedure of backup and restore. It may not be the ultimate procedure for everything, but a recommendable way for a wide spread use case including central service data, user's private date and databases. **Worksteps** 1. Detailed definition of objectives and requirements 2. Research and analyze already available solutions 3. Decision on the path to take 4. Implementation A so far known possible candidate to check is * UrBackup **Timeline**: Should be implemented with release F46.

pboy removed the

meeting

label

2026-03-16 16:18:11 +00:00

pboy added

and removed

labels

2026-05-12 12:55:58 +00:00

goroboro commented

2026-10-12 14:55:30 +00:00

Member

a) Strengthening Server updates
I would put a vote forward for snapm and boom-boot here. This stuff was in the RHEL 10 - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_logical_volumes/managing-system-upgrades-with-snapshots and I think it is fair to say that it is a good approach. We probably need to work on a story to automate these snapshots around dnf transactions etc, maybe with a dnf5 pre-transaction hook.
b) Streamlining regular Server backups
I would like to propose either Borg or Restic here. While I am a fan of Restic and have been using it for many years, I believe that in a Server meeting we were made aware that Vorta was being proposed as a backup GUI for Workstation users. Vorta is based on Borg, so in the interests of stronger consistency with other Fedora selected tech, Borg would be the better option here. Downsides to Borg include lack of support on other platforms, requirement for Borg to be installed on the host where you are backing up to, and lack of native support for cloud object storage. Restic handles these problems really well, but is less efficient than Borg. But there is no reason that we can't provide options here.
On the other options proposed here, I would probably put forward the case that ReaR is worth documenting alongside something like Borg, because it provides a bare-metal bootable system image that recovers system state. You could use ReaR to boot and restore a system, and then use Borg to restore particular files. ReaR is also put forward as a solution for RHEL, so it is not unreasonable to include coverage for this.
I think that the other backup approaches mentioned are all pretty dated. Duplicity, BackupPC and rsync+tar use a lot of disk space, memory and CPU.

a) Strengthening Server updates I would put a vote forward for snapm and boom-boot here. This stuff was in the RHEL 10 - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_logical_volumes/managing-system-upgrades-with-snapshots and I think it is fair to say that it is a good approach. We probably need to work on a story to automate these snapshots around dnf transactions etc, maybe with a dnf5 pre-transaction hook. b) Streamlining regular Server backups I would like to propose either Borg or Restic here. While I am a fan of Restic and have been using it for many years, I believe that in a Server meeting we were made aware that Vorta was being proposed as a backup GUI for Workstation users. Vorta is based on Borg, so in the interests of stronger consistency with other Fedora selected tech, Borg would be the better option here. Downsides to Borg include lack of support on other platforms, requirement for Borg to be installed on the host where you are backing up to, and lack of native support for cloud object storage. Restic handles these problems really well, but is less efficient than Borg. But there is no reason that we can't provide options here. On the other options proposed here, I would probably put forward the case that ReaR is worth documenting alongside something like Borg, because it provides a bare-metal bootable system image that recovers system state. You could use ReaR to boot and restore a system, and then use Borg to restore particular files. ReaR is also put forward as a solution for RHEL, so it is not unreasonable to include coverage for this. I think that the other backup approaches mentioned are all pretty dated. Duplicity, BackupPC and rsync+tar use a lot of disk space, memory and CPU.

Rows
Columns

Streamlined backup and restore: Plannings #184

Proposal