I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A) including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
On 28/11/2020 09:54 pm, William Unruh wrote:
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A)
including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and
sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
Different OS rev. doesn't really matter. No need to mess about with grub/mkinitrd. No changes to fstab needed.
Use rsync to mirror the root drive of A to a _directory_ on B.
rsync will work with ssh. Best way, use B to pull the root directory of
A. In that case make sure you can ssh from B to A without a password -
see ssh-copy-id. As root, obviously.
You could mount your backup disk on B at /Abackup.
rootonB: /backup $ ssh ipaddressofA # must work without password
rootonB: /backup $ rsync -avzx ipaddressofA:/ /Abackup/
-avzx = -a=archive mode, -v=verbose, -z=use compression during transfer, -x=only one file system. note the :/ after the source ip address.
rsync will make a full backup at first, then incrementally overwrite.
If you need "proper" incrementals, see --backup and --backup-dir in the rsync manual.
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A) including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used
as a spare computer for people to use.
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used
as a spare computer for people to use.
On Sat, 28 Nov 2020 18:30:41 -0500, William Unruh <unruh@invalid.ca> wrote:reapply
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used
as a spare computer for people to use.
That is not a great idea. It would require customized backup scripts to
the changes at the end of each backup as the grub config files will changeeach
time a kernel is installed or removed.
I'd just do a normal install on the backup system, and have a directory onit
for backing up the main system to, which would then be used for recovering later, if needed.
Regards, Dave Hodgins
--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.
On Sat, 28 Nov 2020 18:30:41 -0500, William Unruh <unruh@invalid.ca> wrote:
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used
as a spare computer for people to use.
Are you using the main system as a server? Which server applications?
On Sat, 28 Nov 2020 16:54:23 -0500, William Unruh <unruh@invalid.ca> wrote:modifying it
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A)
including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and
sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
What do you mean by file architecture?
Cloning the system to a new computer or even a new disk drive and then
to be bootable on that system is one thing.above since
Using it for daily backups is another thing that is contradictory to the
by definition, system files include the grub configuration files, fstab,etc.
How to properly backup any system depends on what it's running.database
Files being backed up must not be being written to, so for example, mariadb
file backups are useless if mariadb was running while file level backupswere being
created. To create useable backups either mariadb must be stopped, orutilities
built for mariadb must be used.system
What is the purpose of the backup? Is it to be able to recover the main
if needed or something else? If it's just recovery, just install Mageia onit,
use something like nfs, or sshfs to mount a directory on the remote systemand
then use rsync to backup the desired files, ensuring they are not in use atwhen
the backup is being run.
Regards, Dave Hodgins
On 2020-11-28, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Sat, 28 Nov 2020 18:30:41 -0500, William Unruh <unruh@invalid.ca> wrote: >>> Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used >>> as a spare computer for people to use.Are you using the main system as a server? Which server applications?
NFS mainly-- including the html directory to another machine which is
the web server, and including all the home directories and root
management directories.
On 2020-11-28, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Sat, 28 Nov 2020 18:30:41 -0500, William Unruh <unruh@invalid.ca> wrote: >>> Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used >>> as a spare computer for people to use.
That is not a great idea. It would require customized backup scripts to reapply
the changes at the end of each backup as the grub config files will change each
time a kernel is installed or removed.
Yes. That is what I am asking.
I'd just do a normal install on the backup system, and have a directory on it
for backing up the main system to, which would then be used for recovering >> later, if needed.
Since it is important that the server be up, I cannot wait 3 days while another computer to replace my server arrives. I want to just swap to
this backup and keep going, so that the other computers do not know what
has happened.
This might be a good time to use labels instead of UUIDs to identify partitions.
On 2020-11-29, William Unruh <unruh@invalid.ca> wrote:
On 2020-11-28, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Sat, 28 Nov 2020 18:30:41 -0500, William Unruh <unruh@invalid.ca> wrote:
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used >>>> as a spare computer for people to use.
That is not a great idea. It would require customized backup scripts to reapply
the changes at the end of each backup as the grub config files will change each
time a kernel is installed or removed.
Yes. That is what I am asking.
I'd just do a normal install on the backup system, and have a directory on it
for backing up the main system to, which would then be used for recovering >>> later, if needed.
Since it is important that the server be up, I cannot wait 3 days while
another computer to replace my server arrives. I want to just swap to
this backup and keep going, so that the other computers do not know what
has happened.
That can be done by having two installs on the backup manchine one
install that runs rsync, and a second install that is a clone of the
other machine. when the other machine fails nust boot the second
install.
There will be some requirement to maintain the grub install so that the backup can be booted.
This might be a good time to use labels instead of UUIDs to identify partitions.
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A) including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
On 2020-11-28, Chris Elvidge <chris@mshome.net> wrote:
On 28/11/2020 09:54 pm, William Unruh wrote:
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A)
including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and
sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
Different OS rev. doesn't really matter. No need to mess about with
grub/mkinitrd. No changes to fstab needed.
???? The disk names and partitions on B are entirely different from
what they are on A. On A some partitions are even on different disks,
while they are on the same disk on B. The UUIDs on B are different from
what they are on A.
Also since the machines are different, the disks and partitions are different, I surely need to have different initrd files. They preload a
bunch of junk and need to know where that junk is on the disks on B.
Finally, the location of the root directory for the mirror of A on B is different so I surely need to tell grub where to look for them.
Use rsync to mirror the root drive of A to a _directory_ on B.
rsync will work with ssh. Best way, use B to pull the root directory of
A. In that case make sure you can ssh from B to A without a password -
see ssh-copy-id. As root, obviously.
You could mount your backup disk on B at /Abackup.
rootonB: /backup $ ssh ipaddressofA # must work without password
rootonB: /backup $ rsync -avzx ipaddressofA:/ /Abackup/
Yes. There are two different disks on A and one disk on B (but different partitions)
-avzx = -a=archive mode, -v=verbose, -z=use compression during transfer,
-x=only one file system. note the :/ after the source ip address.
rsync will make a full backup at first, then incrementally overwrite.
If you need "proper" incrementals, see --backup and --backup-dir in the
rsync manual.
Yup, that I have already. The question is making sure B can be booted
pretend to be A when A developes problems. Note that otherwise B is used
as a spare computer for people to use.
On 28/11/2020 22.54, William Unruh wrote:
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A)
including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and
sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
I wouldn't it call mirror as A and B won't be identical. Simplest would
just use rsync or similar, tell which files should be copied over from A
to B. You will need to exclude any binary data installed by package
manager and in some cases including configuration files.
If you want to have all the packages to be updated in the same manner, I
do suggest you have B installed with the same version of the OS. The
tricky part is to get the all the updates and things to B from A without breaking it. Had you used btrfs (send/recieve) is had been quite simple
to do, with a reboot required to switch to the new file system.
To solve the etc issue, I would recommend you label the partitions, this
way the fstab can look identical on both machines.
Solving the grub issue, you can solve that with file system label too.
At present I am simply altering the UUID of the root partition ingrub2/grub.conf.
But it is hard to test since, when booted into the mirror of A on B, it
has the same IP and hostname (needed so that change is transparent to
all the other machines) and having two machines with the same IP (as in
a test) would be a disaster.
On 29/11/2020 20.24, William Unruh wrote:
At present I am simply altering the UUID of the root partition in grub2/grub.conf.
Think if you had used the same LABEL instead, then you wouldn't need to
tweak even if the partition setup is different on the different machines.
On Sat, 28 Nov 2020 21:00:43 -0500, Jasen Betts <usenet@revmaps.no-ip.org>wrote:
computerThis might be a good time to use labels instead of UUIDs to identify
partitions.
Thinking more about it, the uuid really only has to be unique within one
so the correct filesystem gets mounted when booting or selected by grub.
The only thing that would have to be different is the ip address.
Not trying to backup files that are being written to is still a concern, butthat
applies no matter what configuration is chosen.
On 2020-11-29, J.O. Aho <user@example.net> wrote:grub2/grub.conf.
On 28/11/2020 22.54, William Unruh wrote:At present I am simply altering the UUID of the root partition in
I want to have one of my other machines be a backup machine to main
server. I and making it a mirror of the main server, in that all of the
files are mirrored daily on it (call the mirror B and the original A)
including all the system files.
Now, I need to change /etc/fstab to reflect the different file
architecture on B from A. But I also have to alter the boot files and
sequence. I run mkinitrd on the mirror (using chroot) but my worry is
about setting up grub properly. How do I make grub see the correct
kernels to boot. (for example right now B is running Mga6 while A is
Mga7)
I wouldn't it call mirror as A and B won't be identical. Simplest would
just use rsync or similar, tell which files should be copied over from A
to B. You will need to exclude any binary data installed by package
manager and in some cases including configuration files.
If you want to have all the packages to be updated in the same manner, I
do suggest you have B installed with the same version of the OS. The
tricky part is to get the all the updates and things to B from A without
breaking it. Had you used btrfs (send/recieve) is had been quite simple
to do, with a reboot required to switch to the new file system.
To solve the etc issue, I would recommend you label the partitions, this
way the fstab can look identical on both machines.
Solving the grub issue, you can solve that with file system label too.
But it is hard to test since, when booted into the mirror of A on B, it
has the same IP and hostname (needed so that change is transparent to
all the other machines) and having two machines with the same IP (as in
a test) would be a disaster.
On Sun, 29 Nov 2020 21:27:56 +0100, J.O. Aho wrote:
On 29/11/2020 20.24, William Unruh wrote:
At present I am simply altering the UUID of the root partition in grub2/grub.conf.
Think if you had used the same LABEL instead, then you wouldn't need to
tweak even if the partition setup is different on the different machines.
LABEL or PARTLABEL will solve the /etc/fstab problem, assuming there are
no duplicate *ABELed partitions. :(
Although not so much for grub.
For LABEL to work in grub, I suggest Unruh would have a custom script
in /etc/grub.d to allow grub to boot via LABEL.
I have no clue if /boot initrd.img/vmlinuz may cause problems on different hardware.
On 29/11/2020 22.01, Bit Twister wrote:
On Sun, 29 Nov 2020 21:27:56 +0100, J.O. Aho wrote:
On 29/11/2020 20.24, William Unruh wrote:LABEL or PARTLABEL will solve the /etc/fstab problem, assuming there are
At present I am simply altering the UUID of the root partition in grub2/grub.conf.
Think if you had used the same LABEL instead, then you wouldn't need to
tweak even if the partition setup is different on the different machines. >>
no duplicate *ABELed partitions. :(
Although not so much for grub.
For LABEL to work in grub, I suggest Unruh would have a custom script
in /etc/grub.d to allow grub to boot via LABEL.
/etc/default/grub
GRUB_DISABLE_LINUX_UUID=true
GRUB_ENABLE_LINUX_LABEL=true
/etc/grub.d/10_linux
https://techpatterns.com/forums/about1575.html
https://ubuntuforums.org/showthread.php?t=1530532
On Mon, 30 Nov 2020 09:01:01 +0100, J.O. Aho wrote:
On 29/11/2020 22.01, Bit Twister wrote:
On Sun, 29 Nov 2020 21:27:56 +0100, J.O. Aho wrote:
On 29/11/2020 20.24, William Unruh wrote:LABEL or PARTLABEL will solve the /etc/fstab problem, assuming there are >>> no duplicate *ABELed partitions. :(
At present I am simply altering the UUID of the root partition in grub2/grub.conf.
Think if you had used the same LABEL instead, then you wouldn't need to >>>> tweak even if the partition setup is different on the different machines. >>>
Although not so much for grub.
For LABEL to work in grub, I suggest Unruh would have a custom script
in /etc/grub.d to allow grub to boot via LABEL.
/etc/default/grub
GRUB_DISABLE_LINUX_UUID=true
GRUB_ENABLE_LINUX_LABEL=true
Those changes by their self do nothing to improve booting by LABEL.
grub.cfg will have hard coded root=/dev/xxxxx :(
/etc/grub.d/10_linux
https://techpatterns.com/forums/about1575.html
Just as I said, custom script required. A bit more code will be needed
to scan the drive to automagically generate the root=LABEL=some_label_here
https://ubuntuforums.org/showthread.php?t=1530532
I suggest to you, modifying /etc/grub.d/10_linux is not very safe let
alone modifying /usr/lib/grub/grub-mkconfig_lib in your first link.
You have the possibility of different releases of grub having different
lines of code, worse, a grub update could install a new 10_linux and/or grub-mkconfig_lib wiping out your changes.
On 2020-11-29, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Sat, 28 Nov 2020 21:00:43 -0500, Jasen Betts <usenet@revmaps.no-ip.org> wrote:
This might be a good time to use labels instead of UUIDs to identify
partitions.
Thinking more about it, the uuid really only has to be unique within one computer
so the correct filesystem gets mounted when booting or selected by grub.
once you start copying them labels are easier than UUIDs, but yeah
UUIDs could still be used.
The only thing that would have to be different is the ip address.
backup server and restored system needn't have the same IP address.
If the original server uses static allocation in the network settingsAll static allocations, yes.
the backup copy will retain this address, the server that maintains
the backup will necessarily nave a different ip address.
Not trying to backup files that are being written to is still a concern, but that
applies no matter what configuration is chosen.
there are strategies to handle this for some domains (eg: postgresql has pg_begin_backup, after which an rsync copy done in the right order
will be usable)
Using ZFS' snapshot capability is another approach that could work.
--
Jasen.
On 2020-11-30, Jasen Betts <usenet@revmaps.no-ip.org> wrote:
On 2020-11-29, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Sat, 28 Nov 2020 21:00:43 -0500, Jasen Betts <usenet@revmaps.no-ip.org> wrote:
This might be a good time to use labels instead of UUIDs to identify
partitions.
Thinking more about it, the uuid really only has to be unique within one computer
so the correct filesystem gets mounted when booting or selected by grub.
once you start copying them labels are easier than UUIDs, but yeah
UUIDs could still be used.
The only thing that would have to be different is the ip address.
backup server and restored system needn't have the same IP address.
Agreed. The question was testing the backup. Discovering something
stupid I had forgotten in the heat of trying to get things going after a crash is not the best of times, so I would like to boot into the new
system while the server is still up. But that would mean it would need a different IP from the server for the test.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:37:27 |
| Calls: | 6,650 |
| Calls today: | 2 |
| Files: | 12,200 |
| Messages: | 5,330,761 |