#3580 Issue closed: Restore a backup without a specific folder¶
Labels: support / question, fixed / solved / done
ZzenlD opened issue at 2026-03-09 09:45:¶
Requesting support or just a question¶
Question: How to restore a backup without a specific folder?
Platform¶
No response
Output¶
Additional information¶
Hello everyone,
I am currently trying to run the restore process periodicaly and
automatically in a VM to ensure that the backups are functional.
Unfortunately, the machine has a very large backup directory under
/srv/backup, which I cannot restore completely for testing purposes
due to space constraints, and actually don't want to.
Is there a way to exclude individual directories from the restore? Very important: The directory should of course still be included in the backup!
Has anyone already implemented this, or are there better ways to verify
the backup?
Thanks in advance for your help :)
jsmeix commented at 2026-03-09 13:00:¶
@ZzenlD
I guess you use BACKUP=NETFS.
In this case EXCLUDE_RESTORE should provide what you ask for,
see its description in usr/share/rear/conf/default.conf
When you use a third-party backup tool there is
usually no support for 'EXCLUDE_RESTORE' so
you need to somehow specify "the right things"
as needed in your particular third-party backup tool.
jsmeix commented at 2026-03-09 13:48:¶
@ZzenlD
FYI in general regarding "big data" backup:
See in
https://en.opensuse.org/SDB:Disaster_Recovery
the section
"Relax-and-Recover versus backup and restore"
and therein the part
"ReaR versus 'big data' backup"
cf.
https://github.com/rear/rear/issues/3451#issuecomment-2841051182
You may also have a look at the following advanced topic:
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.md
ZzenlD commented at 2026-03-09 14:05:¶
Wow, thank you for the quick reply and the links. I'll take a closer look at them tonight.
My configuration currently looks like this:
# /etc/rear/local.conf
OUTPUT=ISO
OUTPUT_URL=file:///mnt/Disaster-Disk/Ventoy
BACKUP=NETFS
BACKUP_URL=file:///mnt/Disaster-Disk/DATA/rear
BACKUP_PROG=rsync
BACKUP_PROG_EXCLUDE=( ${BACKUP_PROG_EXCLUDE[@]} )
EXCLUDE_MOUNTPOINTS=('/mnt/Disaster-Disk/Ventoy' '/mnt/Disaster-Disk/DATA')
If I understand correctly, in my case, only the following line is missing to recursively exclude the directory from the restore:
EXCLUDE_RESTORE=('/srv/backup')
Am I on the right track?
jsmeix commented at 2026-03-09 14:36:¶
I have no experience with rsync.
We have two separated methods to use 'rsync' in ReaR,
see "man rear":
BACKUP=RSYNC
ReaR built-in backup using rsync via rsync or ssh protocol
versus
BACKUP=NETFS
ReaR built-in backup and restore via rsync or tar
to a network file system or to a locally attached
backup disk (USB, eSATA, ...)
From inspecting the ReaR scripts EXCLUDE_RESTORE is used in
usr/share/rear/layout/prepare/default/610_exclude_from_restore.sh
where things get added into the restore-exclude-list.txt file
and that file is then used in
usr/share/rear/restore/NETFS/default/400_restore_backup.sh
which belongs to BACKUP=NETFS.
So EXCLUDE_RESTORE should work
for BACKUP=NETFS with BACKUP_PROG=rsync
but (as far as I see from inspecting the ReaR scripts)
it seems BACKUP=RSYNC may not support EXCLUDE_RESTORE.
jsmeix commented at 2026-03-09 14:43:¶
In general better add things to config arrays via
EXCLUDE_RESTORE+=('/srv/backup')
to add /srv/backup to what there might be already
in EXCLUDE_RESTORE (e.g. via an automatism in ReaR).
As far as I see from inspecting the ReaR scripts
EXCLUDE_RESTORE=('/srv/backup')
should also work, but in general ARRAY+=( ... )
is the normally recommended way, cf. the initial comments in
usr/share/rear/conf/default.conf
gdha commented at 2026-03-16 15:27:¶
@ZzenlD Did it exclude work during the restore?
ZzenlD commented at 2026-03-20 10:34:¶
I haven't been able to test this yet. I'm using ReaR to back up a UEFI Proxmox host, but the ISO file won't boot right now - I'm getting the following error message:
Loading kernel /isolinux/kernel/ ...
error: can't find command `linuxefi`.
Loading initial ramdisk /isolinux/initrd.cgz ...
error: can't find command `initrdefi`.
Press any key to continue ...
But as soon as I get a chance to test it, I'll let you know :)
jsmeix commented at 2026-03-20 12:09:¶
@ZzenlD
to avoid that different topics get messed up in this issue
I recommend that you open a new separated issue
regarding the UEFI Proxmox GRUB booting problem
via the New issue button at
https://github.com/rear/rear/issues
and provide in particular your ReaR configuration
in /etc/rear/local.conf
and ReaR's messages what you get on your terminal
when you create a ReaR recovery system in debug mode
with "rear -d mkrescue" (or "rear -D mkrescue")
in particular all what ReaR shows on your terminal
which is related to booting.
FYI for now:
By googling for "error: can't find command linuxefi"
I found in particular
https://github.com/rear/rear/issues/2971
which is about an issue in GRUB in Fedora.
As far as Google AI told me
"Proxmox Virtual Environment (VE) is based on Debian GNU/Linux"
so https://github.com/rear/rear/issues/2971
may not apply in your case.
E.g. in my openSUSE Leap 15.6 system
I have the GRUB module linuxefi in the file
/usr/share/grub2/x86_64-efi/linuxefi.mod
which is provided by the grub2-x86_64-efi RPM package
and also as /boot/grub2/x86_64-efi/linuxefi.mod
and in the ReaR recovery system I have it also two times
as /boot/grub2/x86_64-efi/linuxefi.mod
and /usr/share/grub2/x86_64-efi/linuxefi.mod
To inspect things from within the ReaR recovery system
set KEEP_BUILD_DIR="yes" in /etc/rear/local.conf and
create a new ReaR recovery system with "rear mkrescue"
then 'chroot' into the new ReaR recovery system like
localhost:~# chroot /var/tmp/rear.../rootfs/
and therein e.g. find if linuxefi is there like
bash-4.4# find . -name 'linuxefi.*'
./boot/grub2/x86_64-efi/linuxefi.mod
./usr/share/grub2/x86_64-efi/linuxefi.mod
In general regarding UEFI with and without Secure Boot
see related entries in usr/share/rear/conf/default.conf
in particular UEFI_BOOTLOADER and SECURE_BOOT_BOOTLOADER
(I know - bootloader stuff is a complicated mess).
gdha commented at 2026-03-28 08:45:¶
@ZzenlD Can we close this issue? For the 2th issue you mentioned please create a new issue which is easier to track for us.
lzaoral commented at 2026-03-31 14:15:¶
The issue in
https://github.com/rear/rear/issues/3580#issuecomment-4097124342 is
related to https://github.com/rear/rear/issues/3423 where I actually
propose not to use linuxefi and initrdefi. I'll create a PR soon.
edit: reword as noted in https://github.com/rear/rear/issues/3580#issuecomment-4163048327
jsmeix commented at 2026-03-31 14:25:¶
@lzaoral
I assume you meant that the above new issue
https://github.com/rear/rear/issues/3580#issuecomment-4097124342
is related to
https://github.com/rear/rear/issues/3423
and not that the original description of this issue
https://github.com/rear/rear/issues/3580#issue-4044528278
is related to
https://github.com//rear/issues/3423
?
lzaoral commented at 2026-03-31 14:38:¶
Yes, exactly, @jsmeix! My bad, I should have been more explicit. I've just reworded my previous comment.
ZzenlD commented at 2026-04-01 04:39:¶
@lzaoral I'm not sure if I can avoid using linuxefi and initrdefi.
I'm having this issue with a Proxmox system running version 9.1.6, which
is based on Debian Trixie 13.3.
Is there any way I can fix this error or help find a solution?
lzaoral commented at 2026-04-01 18:01:¶
@ZzenlD Please, use the first boot entry marked as "non-secure boot", it
is just a misnomer. It will work regardless of secure boot enablement on
your machine. Debian Trixie no longer provides those commands because
they were just legacy aliases to standard linux and initrd commands,
see https://github.com/rear/rear/issues/3423#issuecomment-2955915149
and https://github.com/rear/rear/issues/3423#issuecomment-2976548159.
I've just created https://github.com/rear/rear/pull/3597 to remove the broken "Secure Boot" entry from the development version of ReaR.
[Export of Github issue for rear/rear.]