#3417 Issue open: Out of memory when restoring¶
Labels: support / question, fixed / solved / done
AmosMes opened issue at 2025-03-03 11:42:¶
ReaR version¶
2.9
Describe the ReaR bug in detail¶
When I try to restore the Debian OS via ReaR and the rescue is being mounted I get the error: out of memory.
Platform¶
No response
OS version¶
Debian 12
Backup¶
No response
Storage layout¶
No response
What steps will reproduce the bug?¶
No response
Workaround, if any¶
No response
Additional information¶
No response
gdha commented at 2025-03-03 13:04:¶
@AmosMes Could you please update the issue with details about your system (platform, architecture, and content of /etc/rear/local.conf)?
AmosMes commented at 2025-03-04 06:26:¶
Hi,
The platform is Debian 12 and architecture is 64bit.
The local.conf content is:
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
ONLY_INCLUDE_VG=( "os" )
USB_UEFI_PART_SIZE="1000"
KERNEL_CMDLINE="noip unattended"
USER_INPUT_TIMEOUT=15
USB_RETAIN_BACKUP_NR=1
COPY_AS_IS+=( /root/scripts )
The destination disk is nvme
AmosMes commented at 2025-03-04 06:28:¶
By the way it is a Debian 12 with Proxmox installed on it.
gdha commented at 2025-03-04 07:34:¶
@AmosMes Thanks for the replies. So, you boot from an USB disk, right? Does it boot up?
Try again to create a bootable USB disk without the KERNEL_CMDLINE in
the local.conf file. And, then boot from the USB disk. Does it boot up
properly? Are you have a root prompt? Can you inspect the rescue system
resources before running rear recover...
AmosMes commented at 2025-03-04 08:12:¶
Hi @gdha ,
I boot from a local NVME installed on the server. It is configured as
USB .
I followed your instructions and I do not get a prompt.
I do get the same error as before, I cannot add a screenshot, it fails in this stage:
Loading kernel /EFI/BOOT/kernel ...
Loading initial ramdisk /EFI/BOOT/initrd.cgz
error: out of memory.
Press any key to continue...
gdha commented at 2025-03-04 09:01:¶
@AmosMes Ok, add FIRMWARE_FILES=( 'no' ) to the local.conf and rebuild
the USB boot disk and then try to boot from it again. The rescue OS will
be much smaller. See if this helps?
AmosMes commented at 2025-03-04 09:42:¶
Hi @gdha,
Thanks a lot ... it works.
Should I expect any issues because of the FIRMWARE_FILES=( 'no' ) line
?
Another question please:
My backup disk is 1 TB in size and I would like to divide it to 2
partitions 1 is for data and the other is for the ReaR backup.
Can it be done ?
gdha commented at 2025-03-04 11:55:¶
@AmosMes Great news. As long as the USB rescue recovers the same system then no extra firmware is needed.
Sure, you can divide your disk with 2 partitions. Just make sure that you format the 1st partition again according the REAR-000 procedure you followed before.
AmosMes commented at 2025-03-04 12:40:¶
Thank you,
will try to divide.
jsmeix commented at 2025-03-04 13:16:¶
FYI
a side note regarding
https://github.com/rear/rear/issues/3417#issuecomment-2697294823
As long as the USB rescue recovers the same system
then no extra firmware is needed.
The point here is the exact meaning of the word 'extra'.
When you need some firmware on your original system
to make its hardware work, then you need the specific
firmware files which are used on the original system
also inside the ReaR recovery system to be able
to run the ReaR recovery system on the same hardware
as the original system.
In particular network hardware and many GPUs
(also iGPUs which are built-in in the CPU/APU package)
are known to need firmware to make the hardware work, cf.
https://github.com/rear/rear/issues/3194
But you do not need extra firmware files (i.e. additional
firmware files than what is used on the original system)
inside the ReaR recovery system to run it on the same
hardware as the original system.
In contrast when you intend to run the ReaR recovery system
on different hardware than the original system (e.g. to
recreate your system on different replacement hardware)
then you do a "migration" (onto different hardware)
because your replacement hardware is not fully compatible,
cf. "Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery
So to be able to do such a "migration" you should include
all firmware into the ReaR recovery system that could
be needed on different replacement hardware.
See the FIRMWARE_FILES config variable description
in usr/share/rear/conf/default.conf how to do that
https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L1820
Because the ReaR recovery system runs in main memory
(using a ramdisk) you need sufficient main memory
to run even a bigger ReaR recovery system
which contains lots of firmware files.
AmosMes commented at 2025-03-04 14:01:¶
Thanks @jsmeix
AmosMes commented at 2025-03-05 09:07:¶
@gdha ,
A question about 2 partitions.
I used gdisk and divided the /dev/nvme0n1 to 2 partitions...
/dev/nvme0n1p1 and /dev/nvme0n1p2.
When I run the command "rear -v format -- --efi /dev/nvme0n1p1" the
command is repartitioning the /dev/nvme0n1 and 1 partition is 1GB and
the other has the entire disk.
What am I missing in order to divide the disk as I want and have control on the partitions?
gdha commented at 2025-03-05 11:41:¶
@AmosMes you may hit a small bug in the rear format code of USB disks with an already partitioned disk. As a work-around you have to partition the USB disk and format the 1st partition manually with ext3, ext4 file system. You can label it with REAR-000 afterwards with e2label. As such you have the result you want.
AmosMes commented at 2025-03-05 11:43:¶
Thanks,
and what about the bootable partition?
The rear format creates the bootable partition.
gdha commented at 2025-03-05 11:52:¶
Indeed that will not work - suppose you better use a USB stick to boot from and use the internal disk as archive target as a work-around.
AmosMes commented at 2025-03-05 12:12:¶
The problem is that I don't have that as an option.
Is there anything else to do as a workaround ?
jsmeix commented at 2025-03-05 13:56:¶
@AmosMes
regarding your question in
https://github.com/rear/rear/issues/3417#issuecomment-2696841554
My backup disk is 1 TB in size and I would like to divide it
to 2 partitions 1 is for data and the other is for the ReaR backup.
Can it be done ?
See in usr/share/rear/conf/default.conf
the section about "OUTPUT=USB"
therein the various USB_... config variables in particular
USB_DEVICE_FILESYSTEM_PERCENTAGE
https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L1158
By the way:
Why do you specify USB_UEFI_PART_SIZE="1000" in your local.conf
when the default is USB_UEFI_PART_SIZE="1024"?
I.e. what do you intend to gain with a 24 MiB smaller
size of the EFI system partition (ESP)?
I wonder if you ever read usr/share/rear/conf/default.conf?
Only FYI in general:
In theory it could be possible to prepare an already used disk
so that it is usable for ReaR but I think in practice this
needs unreasonable trial-and-error efforts compared to using
"rear format" from scratch with a pristine empty disk.
I recommend to use "rear mkbackup" only with a dedicated
disk for ReaR. This is what basically all others do so this
is proven to work reasonably well "out there in the wild".
If you use a disk where also valuable other data is stored
(e.g. a disk where already a previous backup is stored)
something might go terribly wrong when writing a subsequent
backup there (e.g. via "rear mkbackup") so in the end
all might be lost on that disk.
To be reasonably on the safe side I recommend to dedicate
at least two disks only to ReaR and use them alternating
so if one gets damaged during "rear mkrescue/mkbackup"
you still have the other one with the latest backup.
Cf.
https://github.com/rear/rear/issues/3398#issuecomment-2647990654
A quick "googling" for "1TB USB disk" shows
that ony can get one for about 50 Euros
(up to about 100 Euros for some "better" ones)
and a 500GiB USB disk for about 25 Euros.
So I wonder if it is really worth the additional risk
to use one same big USB disk for ReaR and other data
than to Keep Separated Issues Separated "KSIS"
(derived from the KISS principle)
and spend money for a separated USB disk for ReaR
(preferably two USB disks for alternating usage).
This is only my personal opinion how I recommend to do it.
Of course you should do what fits best your specific needs.
AmosMes commented at 2025-03-06 11:38:¶
Hi @jsmeix,
Your point about the USB_UEFI_PART_SIZE="1000" is valid and I will
change that so thank you for that.
AmosMes commented at 2025-03-06 11:38:¶
@gdha ,
Do you think you'll be fixing the rear format bug ?
gdha commented at 2025-03-06 13:28:¶
@gdha , Do you think you'll be fixing the rear format bug ?
Not easily done as it was designed to work on one external USB disk.
Internal disks were not directly in scope and that would make everything
more complex.
However, you could use a RAMDISK:
OUTPUT=RAMDISK
# We want our kernel and initramfs saved under /boot/ReaR and have an extention with "-ReaR"
OUTPUT_PREFIX="ReaR"
RAMDISK_SUFFIX="ReaR"
# The RAMDISK will be created under /boot/$(hostname -s)/
OUTPUT_URL=file:///boot
# Use the same IP address(es) of the this system to be activated in the rescue OS
USE_STATIC_NETWORKING="y"
# To be able to login via ssh
SSH_ROOT_PASSWORD="relax"
# We do not want a ReaR archive, therefore, use the EXTERNAL setting for BACKUP:
BACKUP=file:///your-internal-disk-mount-point
# To save space limit what we need (no firmware and only the loaded kernel modules)
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
EXCLUDE_MOUNTPOINTS=( /your-internal-disk-mount-point )
AUTOEXCLUDE_PATH=( /your-internal-disk-mount-point )
WRITE_PROTECTED_FS_LABEL_PATTERNS=( "REAR-DATA" ) # label your internal disk
[Export of Github issue for rear/rear.]