#1158 Issue closed: USB_RETAIN_BACKUP_NR not effective when using extra data partition on USB device (OUTPUT=USB)¶
Labels: needs sponsorship, no-issue-activity
dwerner1 opened issue at 2017-01-09 19:18:¶
- rear version
Relax-and-Recover 2.00 / Git - OS version
Debian GNU/Linux testing (stretch) /etc/rear/site.confis empty,/etc/rear/local.conf:
BACKUP=NETFS
OUTPUT=USB
USB_DEVICE=/dev/disk/by-label/REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-DATA
- I'm using legacy BIOS and a gpt partition table!
I'm using an extra data partition on an external USB device, here is the
output of parted /dev/sdb print
Disk /dev/sdb: 32.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 1600MB 1600MB ext3 primary legacy_boot
2 1601MB 32.0GB 30.4GB xfs primary
I have set USB_RETAIN_BACKUP_NR=2 but the rescue environment folders
sum up in the REAR-DATA partition
drwx------ 7 root root 111 Jan 9 19:56 .
drwx------ 3 root root 24 Jan 9 11:45 ..
drwxr-x--- 2 root root 45 Jan 9 11:48 20170109.1143
drwxr-x--- 2 root root 45 Jan 9 19:40 20170109.1937
drwxr-x--- 2 root root 45 Jan 9 19:44 20170109.1941
drwxr-x--- 2 root root 45 Jan 9 19:50 20170109.1947
drwxr-x--- 2 root root 45 Jan 9 19:58 20170109.1955
In the REAR-000 partition, everything looks good
drwx------ 4 root root 4096 Jan 9 19:55 .
drwx------ 3 root root 4096 Jan 9 11:43 ..
drwx------ 2 root root 4096 Jan 9 19:47 20170109.1947
drwx------ 2 root root 4096 Jan 9 19:55 20170109.1955
gozora commented at 2017-01-10 08:17:¶
Hi, @dwerner1
Reason for this would be simple, looks like ReaR does not have cleanup
of other that REAR-000 partition implemented.
Relevant code can be found in
/usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh near line
130 so you can experiment with it.
I can have a look once I'm home later today ...
V.
dwerner1 commented at 2017-01-10 08:23:¶
Hi @gozora
Thanks! I'll have a look at that
jsmeix commented at 2017-01-10 08:44:¶
I am very much against to implement more and more
advanced backup management features into ReaR.
Reasons:
ReaR is not meant to be a backup management software
cf. "Relax-and-Recover versus backup and restore" at
https://en.opensuse.org/SDB:Disaster_Recovery
Having more and more advanced backup features in ReaR
makes it more and more labor-intensive to maintain ReaR
because each feature needs continuous attention, testing,
and work to keep it up to date.
In contrast ReaR is meant to be relatively easily extensible
by additional selfmade scripts when a particular user needs
special additional functionality.
In this case it is about backup management features when
using a extra data partition on USB device.
Because plain removing of old backup directories should
work independent of creating the new current backup
I think it should work to add a script named either
usr/share/rear/output/USB/Linux-i386/295_remove_outdated_dirs.sh
or
usr/share/rear/output/USB/Linux-i386/305_remove_outdated_dirs.sh
that would run - as needed - either directly before or directly after
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh
jsmeix commented at 2017-01-10 08:47:¶
By the way:
On first glance I think the USB_RETAIN_BACKUP_NR
implementation in a 'create_extlinux' named script at least
looks unexpected - I would expect a separated script for
the separated task to remove outdated backup directories?
dwerner1 commented at 2017-01-10 08:47:¶
I do understand what you mean, I have actually already a script at hand for handling older rescue environments
gozora commented at 2017-01-10 08:53:¶
Hello @jsmeix,
I am very much against to implement more and more
advanced backup management features into ReaR.
and
I think it should work to add a script named either
usr/share/rear/output/USB/Linux-i386/295_remove_outdated_dirs.sh
or
usr/share/rear/output/USB/Linux-i386/305_remove_outdated_dirs.sh
that would run - as needed - either directly before or directly after
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh
I'm confused, isn't adding new scripts into ReaR same as adding new
features to existing ones?
What does "advanced backup management features" include?
jsmeix commented at 2017-01-10 08:55:¶
@dwerner1
only out of curiosity:
Why do you use GPT plus an extra data partition
on a only 32GB small USB device?
As far as I know (and according to what I wrote in default.conf)
traditional MBR should work up to 2TB
and simple ext3 should work up to 4TB
so that for a 32GB USB device the "rear format" default
of MBR and a single ext3 'REAR-000' labeled partition
should "just work".
gozora commented at 2017-01-10 08:57:¶
@jsmeix I'm just guessing, but maybe @dwerner1 is preparing for
something bigger ...
Remember
https://github.com/rear/rear/issues/1105
?
dwerner1 commented at 2017-01-10 08:58:¶
@gozora ;-) yes indeed!
The stick is my testing environment - the productive system is an
external USB DAS device 16TB of size (RAID1) I plan to have a REAR-000
ext3 partition of ~ 1 TB, and a 15TB xfs REAR-DATA partition
jsmeix commented at 2017-01-10 09:09:¶
@gozora
I meant new scripts that are added by a particular user
only on his particular systems but not included in the
general ReaR upstream code.
From my point of view "backup management features"
include basically all what exceeds plain making a backup
during "rear mkbackup" and plain restore during "rear recover"
cf. "Relax-and-Recover versus backup and restore" at
https://en.opensuse.org/SDB:Disaster_Recovery
Strictly speaking I would wish things like
NETFS_KEEP_OLD_BACKUP_COPY
and USB_RETAIN_BACKUP_NR would have
never been accepted in the ReaR upstream code.
But as those features are there we now have to deal
with perfectly valid user requests when those features
do not work well in this or that circumstances.
I.e. the request of @dwerner1 to make USB_RETAIN_BACKUP_NR
also working with a separated data partition (more generally to make
it working based on the BACKUP_URL value) is perfectly valid
from a ReaR user's point of view.
But I fear this could lead to an endless sequence of requests
to enhance ReaR to manage the backups which could
pervert ReaR into unmaintainable bloatware.
dwerner1 commented at 2017-01-10 09:10:¶
My kind of use of rear in this case might be a little spurious or not common, I'm not 100% sure anymore if I'm going the right way. The location of the server, this rear implementation is meant for, is a very remote area in northern europe. There are just a few people who have access to the machine, but almost no knowledge of Linux server administration. They shall be able to recover the server from scratch to a state, where the machine can be accessed remotely again. ReaR in my eyes is just perfect for that scenario. Does anyone of you think different?
gozora commented at 2017-01-10 09:26:¶
@jsmeix
I meant new scripts that are added by a particular user
only on his particular systems but not included in the
general ReaR upstream code.
This explains a lot, thanks. (especially "only on his particular systems"). From my experience I think that adding script to ReaR is a bit clumsy. You need to know what stage is launched and when. Maybe I've missed it, but don't we have something like ReaR pre and post backup scripts?
I.e. the request of @dwerner1 to make USB_RETAIN_BACKUP_NR
also working with a separated data partition (more generally to make
it working based on the BACKUP_URL value) is perfectly valid
from a ReaR user's point of view.
Fully agree here.
@dwerner1 Yes, you've chosen road nobody was walking before you, so it will not be that smooth. But to my opinion your choice uncovered at least one general bug so it was worth it. Apart from that I have a feeling that you are not far from making all this work.
dwerner1 commented at 2017-01-10 09:31:¶
It was a little bumpy ride the recent three weeks with rear ;-) But with your and @jsmeix support it was even fun! I'm now pretty satisfied with the current setup and current git version
jsmeix commented at 2017-01-10 09:41:¶
@dwerner1
don't worry - compared to my first attempts with ReaR
it seems your's have been actually quite smooth.
And your input helped already improve ReaR.
Many thanks for that!
If you have selfmade scripts that make USB_RETAIN_BACKUP_NR
work for you with a separated data partition I would very much
appreciate it if you could provide them to us (e.g. attach them
to this issue) so that we could have a look what works for you.
dwerner1 commented at 2017-01-10 09:44:¶
@jsmeix
Oh yes, I plan to publish my script! It's just still a bit rough and untidy at the moment. When I install that finally, I'll definetely publish this here together with my experiences during the implementation
jsmeix commented at 2017-01-10 10:06:¶
@gozora
I fully agree that "adding script to ReaR is a bit clumsy".
I think the main problem with adding selfmade scripts is
that ReaR works very much based on the idea of workflows
which are longer sequences of things that are done where each
step may depend in various ways on all its predecessor steps.
This can make it complicated to add a script "in between"
because one has to know exactly what the actual
state of the workflow is at a particular position
to find the right position in a workflow where a particular
additional functionality (i.e. a new script) can be added.
Cf. my currently unsuccessful attempt to spilt the current
huge "recover" workflow into well separated generic parts, see
https://github.com/rear/rear/pull/1091#issuecomment-263819775
and
https://github.com/rear/rear/issues/987
Therefore I have in my mind the idea of "tasks"
where each task is a well separated generic part
that is useful on its own and that can run on its own.
For example the "recover" workflow consists basically
of those well separated generic tasks:
- setup the disk layout (i.e. prepare storage)
- store the payload (e.g. restore a backup)
- install the bootloader
Currently ReaR has so called "stages",
see the SourceStage function in lib/framework-functions.sh
but those "stages" are not what I mean with "task"
because a stage is not useful on its own
and it cannot run on its own.
Basically a task is bigger than a stage abut usually
a task is smaller than a workflow (except minimal
workflows like format, mkbackuponly, restoreonly).
jsmeix commented at 2017-01-10 10:09:¶
During "rear recover" we have
PRE_RECOVERY_SCRIPT and POST_RECOVERY_SCRIPT
and during "rear mkbackup" we have
PRE_BACKUP_SCRIPT and POST_BACKUP_SCRIPT,
see "custom scripts" in default.conf.
gdha commented at 2017-01-10 13:39:¶
@dwerner1 Why not using a dedicated NAS/NFS server to archive the backup/archives of your Linux systems in the far remote data center? I always prefer this above USB (USB is ok for stand-alone systems IMHO).
dwerner1 commented at 2017-01-10 13:57:¶
@gdha
That's a justified argument! It's a server hosting five vibrant virtual
machines and it has a large data throughput. Each rear -v mkbackup
will most likely create images of currently ~ 2 to 3TB of size. The DAS
is connected via USB 3.1 Type C and provides an enormous higher
connection speed compared to NAS/NFS. It's also a demand by the company
I work as a freelancer for, that the disaster recovery images reside in
close geographical neighbourhood to the server. The server mainly
collects, analyzes and temporarily stores data from wind turbines and
measuring devices in a far remote renewable energy test field. The
internet connection to this place is far from stable and reliable, the
machine has to be recoverable locally without any need of network
connection!
dwerner1 commented at 2017-01-10 14:16:¶
To make my occupational background a bit more transparent - I'm a civil engineer, located in Cologne, Germany. I frequently work for companies in the green energy sector. I've been working as a JAVA developer for fifteen years and I also have a deep passion for Linux servers since 1996. (I started with Caldera Linux ;-) ) That's a rough overview, I'm fifty years old by the way... So, I'm definitely not the typical Linux Admin, but quite addicted to it.
gozora commented at 2017-01-10 14:22:¶
@dwerner1 really interesting case.
- Do you plan to store backup of all servers on one single DAS?
- Are servers that will be backed up same or at least similar HW?
- 2 to 3 TB that is quite lot of data, why so much? Are some databases included?
dwerner1 commented at 2017-01-10 14:29:¶
@gozora
- Do you plan to store backup of all servers on one single DAS?
It's by now only one host, another might be added in the future. For the time being the main interest is, to be able to restore the VM's quickly
- Are server that will be backed up same or at least similar HW?
Yes, exactly the same hardware structure
- 2 to 3 TB that is quite lot of data, why so much ? Are some databases included?
Yes, quite a few DB's. I'm not the admin of the VM's, I guess there are ~ 15 databases running, most of them Oracle
gozora commented at 2017-01-10 14:39:¶
Yes, quite a few DB's. I'm not the admin of the VM's, I guess there are ~ 15 databases running, most of them Oracle
I'm not DB expert, but with the small experience I have, you should not do "live" backup of running database. Maybe you should consider splitting backup tasks like:
- ReaR to make backup/restore of bare OS
- Run database backup separately with dedicated tools
jsmeix commented at 2017-01-10 14:44:¶
Regarding huge ReaR backups see my opinion at
https://github.com/rear/rear/issues/1006#issuecomment-248862040
In general regarding huge backups have a look at
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc
how one could get backup and restore much faster
on sufficiently powerful systems.
Since ReaR 2.0 I would in any case split the backup
of the basic system from any other "optional" backups
(like databases) to be more on the safe side in case of a
real disaster recovery so that you could get the basic system
recovered fast and then do the other "optional" backup restores
in a more relaxed way.
Even if you do all backups with ReaR I would keep
separated backups separated so that I am more
flexible with a possible recovery/restore.
Imagine only a database gets corrupted.
You won't need to do a whole system recovery.
Only a plain restore of that database should be sufficient.
Then it should be more fail safe and faster when
the backup of that database is separated.
jsmeix commented at 2017-01-10 14:51:¶
I think using 'usb' to have backups and ISO on a local disk
without any need for networking is a valid request.
Currently using multiple backups for ReaR is not supported
on local disks but the more I learn about the use case of
@dwerner1 the more I think about whether or not
ReaR should support it in the future?
dwerner1 commented at 2017-01-10 14:51:¶
@gozora, @jsmeix
I understand what you mean! There are DB backup processes running inside the VM's. The background of my approach is rather based on the fact that - in case of disaster - and ( not rare ) no connection to the outside world at the remote location - the people up there, who have not much linux experience - shall be able to recover, not only the OS, but also all VM's and actually the complete environment they had been using just before the 'imaginable' crash.
dwerner1 commented at 2017-01-10 14:55:¶
A little 'data loss' is not as problematic, as the machine 'not being' recoverable locally and possibly standing still for days!
jsmeix commented at 2017-01-10 15:04:¶
@dwerner1
only FYI in particular regarding "the people up there, who have
not much linux experience - shall be able to recover",
see
"Let's face it: Deployment via the recovery installer is a must"
at
https://en.opensuse.org/SDB:Disaster_Recovery
dwerner1 commented at 2017-01-10 15:14:¶
"Let's face it: Deployment via the recovery installer is a must"
at
https://en.opensuse.org/SDB:Disaster_Recovery
Yes I understand! They will be trained for that! 'The people up there' are mostly engineers and technicians with a profound idea and interest for Linux & OpenSource - and some of them, even have collected experience in good old UNIX days. Since they switch every three months, it's a bit of training work and establishing scenario HOWTO's for that .. for me!
Sometimes I feel like I need to find a solution for Robinson Crusoe's island ... but he had no network access at all ;-) only Friday
jsmeix commented at 2017-01-10 15:25:¶
Some hard facts regarding my
https://github.com/rear/rear/issues/1158#issuecomment-271594904
Currently using multiple backups for ReaR is
not supported for things like
OUTPUT=USB USB_DEVICE=/dev/disk/by-label/REAR-000 BACKUP_URL=usb:///dev/disk/by-label/REAR-000
with etc/rear/basic_system.conf and
etc/rear/home_backup.conf as in
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc
because after
usr/sbin/rear -C basic_system -d -D mkbackup
and a subsequent
usr/sbin/rear -C home_backup -d -D mkbackuponly
one gets on the REAR-000 medium
rear/e205/20170110.1618 rear/e205/20170110.1618/backup-home_backup.log rear/e205/20170110.1618/backup-home_backup.tar.gz rear/e205/20170110.1614 rear/e205/20170110.1614/backup-basic_system.log rear/e205/20170110.1614/kernel rear/e205/20170110.1614/syslinux.cfg rear/e205/20170110.1614/initrd.cgz rear/e205/20170110.1614/rear-e205-mkbackup-basic_system-4931.log rear/e205/20170110.1614/backup-basic_system.tar.gz
which is essentially the same issue as in
https://github.com/rear/rear/issues/1145
cf.
https://github.com/rear/rear/issues/1141#issuecomment-269963775
jsmeix commented at 2017-01-10 15:32:¶
Regarding support for multiple backups
also for BACKUP_URL=usb I created right now
https://github.com/rear/rear/issues/1160
dwerner1 commented at 2017-01-10 15:43:¶
Puuh! I didn't expect to kick something off like this issue .. But I really appreciate you support, review and ideas @jsmeix , @gozora , @gdha !
gdha commented at 2017-01-10 16:01:¶
@dwerner1 Are you coming to FOSDEM? Cologne is not that far from Brussels - we have a devroom where everybody of the current ReaR team will be available...
dwerner1 commented at 2017-01-10 16:10:¶
@gdha
Since I now know that you all are gonna be there - I seriously have started planning to come!
gozora commented at 2017-01-10 16:23:¶
Questions questions questions :-).
I have another one:
I understand what you mean! There are DB backup processes running inside the VM's.
Where is this DB backup currently stored?
And maybe a hint;
Sometimes when I don't have luxury of my backup server being available,
I'm using "round" backup scenario where I do backups as follows:
- server1 -> server2
- server2 -> server3
- server3 -> server1
Didn't you consider something like this (maybe a bit more bulletproof)?
V.
dwerner1 commented at 2017-01-10 16:46:¶
Where is this DB backup currently stored?
Currently these backups are 'backuped' via Samba up to the host and various external USB devices. I'm not responsible for these backup procedures. This host has grown in two years and not been initially setup by me. My add to this machine was a KVM/Qemu based environment for running 2 Ubuntu based VM's and 3 Windows server VM's (Running engineering specific stuff, measurement procedures, SQL .. and so on) It was my main task to shift former physical Windows servers into KVM based VM's. The two Ubuntu machines just entered the boat recently.
And maybe a hint;
Sometimes when I don't have luxury of my backup server being available, I'm using "round" backup scenario where I do backups as follows:
server1 -> server2
server2 -> server3
server3 -> server1
Didn't you consider something like this (maybe a bit more bulletproof)?
Too be honest - when I had built the machine from scratch - I had at least taken in mind what you mention here ;-)
gozora commented at 2017-01-10 17:07:¶
I'm starting to get a better picture here...
There are two possible ways how you can continue from here:
You plan to either:
- Launch ReaR on VM HOST and backup all available data including VM guest virtual disks. Then in case of disaster, recover HOST and (hope that VM guest disks are consistent) and start guests.
or
- Launch ReaR in each VM GUEST separately + launch ReaR on VM HOST (backup OS relevant data). In case of disaster, restore VM HOST first and then restore VM guests.
Which one is closer?
V.
dwerner1 commented at 2017-01-10 17:23:¶
@gozora
That's a valuable mind input! I have been closer to point 1 before. But
since today I'm getting closer to point 2 .
Point 2 is 'a bit' more work for me ... I have to think about that way
for a while before I can invest in that
Launch ReaR in each VM GUEST separately + launch ReaR on VM HOST (backup OS relevant data). In case of disaster, restore VM HOST first and then restore VM guests.
Am I right? This is exclusively for the Ubuntu VM's, isn't it? I haven't missed the publishing of ReaR for Microsoft Windows? ;-)
gozora commented at 2017-01-10 17:40:¶
@dwerner1
Well, yes at least to my experience you should not make backup of things that are running (complex DBs, VM, etc ...). You might be lucky and everything goes fine, but I really doubt that ;-). My recent experience when running backup/restore of OS where just a small mysql DB running was "Failed to start MySQL" message.
For that ReaR for MS windows topic, currently I'm working on new backup
method called BLOCKCLONE which should be able to do backups regardless
on filesystem used. NTFS backup using ntfsclone will be part of it.
You can check
https://github.com/rear/rear/issues/1078
if you want to read more about it.
For your case however (having windows in KVM VM) all you need to do is
to shutdown Windows and backup its VM disks I guess.
Hopefully after @jsmeix https://github.com/rear/rear/issues/1158#issuecomment-271517756 it will be accepted by upstream ;-)
V.
jsmeix commented at 2017-01-11 09:46:¶
@gozora
I do look forward to your new BLOCKCLONE backup method!
New backup methods match perfectly well how ReaR is meant
to be used, cf. my planned extraordinary ZYPPER backup method
https://github.com/rear/rear/issues/1085
New backup methods are no backup management features.
In contrast if you would implement special advanced
backup management features for the BLOCKCLONE
backup method, then I may not like it.
But all that totally depends on whether or not features
are needed to make a backup method work normally
or if a feature is not actually needed to be inside ReaR
because the admin can do the same on his own also
outside of ReaR like cleaning up of outdated backups.
jsmeix commented at 2017-01-11 09:47:¶
@dwerner1
I look forward to seeing you at FOSDEM 2017, cf
https://fosdem.org/2017/schedule/track/backup_and_disaster_recovery/
dwerner1 commented at 2017-01-11 09:48:¶
@gozora
I fully agree with you about the most likely inconsistent DB's after a potential machine recovery. The people who run these DB based applications, say that they can handle that with their own backups. So I'm quite happy not to have to deal with this issue ;-)
dwerner1 commented at 2017-01-11 09:49:¶
@jsmeix
I have decided to come at least for Saturday 4th ! Looking forward to
see the ReaR team there!
gozora commented at 2017-01-11 10:00:¶
@jsmeix
In contrast if you would implement special advanced
backup management features for the BLOCKCLONE
backup method, then I may not like it.
I'd really appreciate if you could have a short took on
https://github.com/gozora/rear/tree/block_clone
and tell me what do you think about it.
I'm afraid that there might be some "backup management features" which
are not very well solved. Especially the partitioning code :-( (which is
not mandatory to use).
It is working piece of code currently but I have that gut feeling that
it can be done better...
Thanks
V.
jsmeix commented at 2017-01-11 11:20:¶
To keep separated issues separated I made a new issue
"New kind of "backup" method: BACKUP=BLOCKCLONE"
https://github.com/rear/rear/issues/1162
gozora commented at 2017-01-11 11:22:¶
Thanks @jsmeix !
jsmeix commented at 2017-01-11 11:50:¶
@gozora
of course not only mandatory stuff for a backup method
is acceptable in ReaR. Above I meant that all what is
"needed to make a backup method work normally"
should be perfectly well inside ReaR.
I only like to keep all that zillions of optional "nice to have"
advanced thingies out of ReaR that can be as well done
by the admin on his own outside of ReaR.
gozora commented at 2017-01-11 12:04:¶
@jsmeix understood ;-)
jsmeix commented at 2017-01-12 11:16:¶
@dwerner1 regarding your
https://github.com/rear/rear/issues/1158#issuecomment-271824261
"The people who run these DB based applications, say that
they can handle that with their own backups":
I wonder why DB data needs to be in the ReaR backups at all?
When "rear mkbackup" is run while the DB is active, then
(with probability one
https://en.wikipedia.org/wiki/Almost_surely)
the DB data in the ReaR backup will be inconsistent
so that a restore of that DB data does not make sense
because after restore of that DB data the DB won't work
so that one of the DB's "own backups" would have to
be additionally restored to make the DB work again
in a consistent way (with some loss of data).
Therefore I think you can exclude DB data from the ReaR backup
(cf. BACKUP_PROG_EXCLUDE and BACKUP_ONLY_EXCLUDE
versus BACKUP_PROG_INCLUDE and BACKUP_ONLY_INCLUDE).
To get one of the DB's "own backups" restored automatically
during "rear recover" one could use POST_RECOVERY_SCRIPT.
What I think what should happen during "rear recover"
is the recovery of the plain operating system
plus all application software (i.e. the DB software)
but without DB data and then via POST_RECOVERY_SCRIPT
the DB data would be restored from one of the DB's "own backups"
so that after reboot the recreated system would start
with the DB working again in a consistent way but
with some loss of DB data (since the DB's "own backup").
dwerner1 commented at 2017-01-12 14:06:¶
@jsmeix
Yes, I understood! I have started excluding the DB files from the rescue environment. Putting them back into the recovered system with POST_RECOVERY_SCRIPT is a very useful hint, many thanks!
jsmeix commented at 2017-01-12 14:45:¶
@dwerner1
an even further idea:
Perhaps you can talk with "the people who run these DB based
applications" that they could care about the restore of the DB data
from one of the DB's "own backups"?
What I mean is that "rear recover" results the plain
operating system plus all application software
(i.e. the DB software) but without DB data.
Then after reboot the recovered system runs on its own
in its own native mode - instead of whatever
possibly limited mode of the ReaR recovery system.
When the recovered system runs again in its own native mode
the DB cannot start because there is not yet any DB data.
In this case it is perhaps possible that the DB related software
(e.g. whatever DB startup script) can detect that there is
no DB data and then it does a restore of the DB data
from one of the DB's "own backups" so that finally
it can successfully start the DB.
What I have in mind is that for example in the ReaR
recovery system there are basically no services running
so that when the DB data restore would need some
services (you wrote about things like Samba)
it may not be easily possible to restore the DB data
from within the ReaR recovery system.
In contrast I assume that when the recovered system
runs in its own native mode all needed stuff to restore
the DB data is up and running so that DB data restore
from within the normal running system would "just work".
In other words:
I recommend to let ReaR do only what ReaR is designed for:
A really fast recreation of the basic operating system.
But keep any sophisticated additional work out of ReaR
and let that be done by individual other tools where
each one is designed for each particular special task.
jsmeix commented at 2017-01-18 08:35:¶
@dwerner1
FYI:
I think I have some general good news regarding backup on USB
(but nothing changed regarding this particular issue):
See
https://github.com/rear/rear/issues/1166
and
https://github.com/rear/rear/issues/1164
I would recommend that you update to the current ReaR GitHub master
and test if the enhanced backup on USB behaviour makes it work
better for your particular use case.
Regarding this particular issue
(enhance USB_RETAIN_BACKUP_NR functionality):
I will not do that because I am in general against functionality
in ReaR that deletes files because I think the user's files
(in particular his backups) are sacrosanct so that ReaR
should not do anything with existing backups. I think it is
the user's own personal task to deal with his backups.
gdha commented at 2017-08-16 09:35:¶
@dwerner1 Can this issue be closed as there are more then enough answers
in it already...
The last remark of @jsmeix about enhance USB_RETAIN_BACKUP_NR
functionality is quite clear I would say.
dwerner1 commented at 2017-08-16 11:09:¶
@gdha
If you could give me a couple of days, I would publish a little script
here I'm using since January now. It initiates rear with OUTPUT=USB it
handles a number of backup files, deletes oldest and so .... nothing
gigantic but possibly useful for someone
github-actions commented at 2020-07-02 01:33:¶
Stale issue message
[Export of Github issue for rear/rear.]