Replies: 4 comments 5 replies
-
|
First, use/switch to the containerized version of Uyuni. |
Beta Was this translation helpful? Give feedback.
-
|
how i can switch ? |
Beta Was this translation helpful? Give feedback.
-
|
you should check Basically you need a new machine for the container server and a password-free SSH connection between that machine and the existing server. Once the migration is done, you just change the IP of the new machine to match the old one. There is known issue that prevents only changing the DNS. |
Beta Was this translation helpful? Give feedback.
-
|
Hi
Sorry for jumping on hsh-it’s message, but is there any more detailed documentation for migrating an established Uyuni server to a container as the linked page seems very short for what feels like it will be a potentially complex and difficult procedure?
Something that might answer questions like:
“Build a new server” – what OS? What disk space? I assume 64bit.
“Kubernetes or Podman” – which is best? How should we inform ourselves if we need to make a choice? We’re use docker and nobody here has used K8s or Podman before.
What from the existing configuration will work? Will repos be copied over or regenerated? Will paths stay the same?
What can I expect to see at the end of migration? How long will it take?
We use spacecmd a lot for scripting, will that work on the host? I’m assuming not unless Uyuni tools are installed, so how would we migrate this?
Sorry again, not usually a complainer and I love this project and want to continue supporting it. But this migration feels very pushed and I don’t feel like I’m at all informed. This given help page is like a stub reminder for someone that already knows, rather than the step-by-step guide I’d like before moving mission critical software like this.
It's entirely possible I’ve missed something that explains all this and I’d love to know about it if so!
Thank you and everyone else that is working hard on this project. I’m not anti-change and I do appreciate the reasons for containerisation, I’d just like to be properly prepared before setting out.
S
From: Cedric Bosdonnat ***@***.***>
Sent: Monday, July 29, 2024 9:55 AM
To: uyuni-project/uyuni ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [uyuni-project/uyuni] Backup strategy for Uyuni Server (Discussion #9109)
you should check mgradm migrate podman command. You can also refer to the help page for migration<https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation-and-upgrade/container-deployment/uyuni/server-migration-uyuni.html#_migrating>.
Basically you need a new machine for the container server and a password-free SSH connection between that machine and the existing server. Once the migration is done, you just change the IP of the new machine to match the old one. There is known issue that prevents only changing the DNS.
—
Reply to this email directly, view it on GitHub<#9109 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7AIN5MFX3TV6KT63MYHL6TZOX7ODAVCNFSM6AAAAABLP46BVOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJXG42TAMA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
For now there is nothing else, but that's a PR away 😉
The new server is about the same specs than the one to migrate. The container host requires a bit more RAM as there is no swap there, but that's all the difference.
This is an opened question and really depends on your skills and what you want. If you never played with Kubernetes, better stick to podman. We also are still actively working on the kubernetes version: I would only pick it for testing purposes. We tested it on k3s and recently found some issues there. I have tested it with rke2 a long time ago, but never tried the other kubernetes distros.
podman is almost a drop in replacement for docker: you won't feel that much difference. There are even distros that ship a
Yes repos, database and most of the configuration files are copied over. The good thing is that you can run a
The autoinstallations trees paths are changed but the trees are copied in the container too. All the data and configurations are copied in the container volumes.
That highly depends on the DB and repos sizes. We have added a
The infos are spread in the whole documentation, but it's a valuable feedback that you bring here. Of course we are somehow special users and may be a bit narrow scoped at times. |
Beta Was this translation helpful? Give feedback.
-
|
Cedric – thank you very much for taking the time to answer my somewhat worried questions. Your info is greatly appreciated.
From: Cedric Bosdonnat ***@***.***>
Sent: Tuesday, July 30, 2024 3:14 PM
To: uyuni-project/uyuni ***@***.***>
Cc: Simon Avery ***@***.***>; Comment ***@***.***>
Subject: Re: [uyuni-project/uyuni] Backup strategy for Uyuni Server (Discussion #9109)
Hi Sorry for jumping on hsh-it’s message, but is there any more detailed documentation for migrating an established Uyuni server to a container as the linked page seems very short for what feels like it will be a potentially complex and difficult procedure?
For now there is nothing else, but that's a PR away 😉
Something that might answer questions like: “Build a new server” – what OS? What disk space? I assume 64bit.
The new server is about the same specs than the one to migrate. The container host requires a bit more RAM as there is no swap there, but that's all the difference.
For Uyuni you can choose the host OS as long as it has podman 4.5 or later. We test it on Leap Micro 5.5 and Leap 15.5, but I see no reason to not work for other OSes.
“Kubernetes or Podman” – which is best?
This is an opened question and really depends on your skills and what you want. If you never played with Kubernetes, better stick to podman. We also are still actively working on the kubernetes version: I would only pick it for testing purposes. We tested it on k3s and recently found some issues there. I have tested it with rke2 a long time ago, but never tried the other kubernetes distros.
We’re use docker and nobody here has used K8s or Podman before.
podman is almost a drop in replacement for docker: you won't feel that much difference. There are even distros that ship a docker alias for podman.
What from the existing configuration will work? Will repos be copied over or regenerated?
Yes repos, database and most of the configuration files are copied over. The good thing is that you can run a mgradm migrate podman command on the new a server and assess it before switching. The migration is not destructive and only stops the source server to avoid files and DB corruption.
Will paths stay the same? What can I expect to see at the end of migration?
The autoinstallations trees paths are changed but the trees are copied in the container too. All the data and configurations are copied in the container volumes.
How long will it take?
That highly depends on the DB and repos sizes. We have added a --prepare flag for the migration commands to minimize the source server unavailability. Basically you would just it once with prepare to sync the bulk of the files and run it a second time to only sync what changed. Under the hood the sync is done by rsync.
We use spacecmd a lot for scripting, will that work on the host? I’m assuming not unless Uyuni tools are installed, so how would we migrate this?
spacecmd is installed in the container. You can run it from the host using mgrctl exec -- spacecmd.
Sorry again, not usually a complainer and I love this project and want to continue supporting it. But this migration feels very pushed and I don’t feel like I’m at all informed. This given help page is like a stub reminder for someone that already knows, rather than the step-by-step guide I’d like before moving mission critical software like this. It's entirely possible I’ve missed something that explains all this and I’d love to know about it if so! Thank you and everyone else that is working hard on this project. I’m not anti-change and I do appreciate the reasons for containerisation, I’d just like to be properly prepared before setting out.
The infos are spread in the whole documentation, but it's a valuable feedback that you bring here. Of course we are somehow special users and may be a bit narrow scoped at times.
—
Reply to this email directly, view it on GitHub<#9109 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7AIN5ILA4BXI24K7UXBKALZO6NSPAVCNFSM6AAAAABLP46BVOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJZGE2DGOI>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
What is your suggestion for DB backup? |
Beta Was this translation helpful? Give feedback.
-
|
DB is not the only thing to backup: it contains pointers to the downloaded RPMs, so you should backup both at the same time. Wouldn't it be wiser to plan some maintenance windows and copy all the volumes at that time? You can still add volumes by adding a |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, that's exactly what I meant! |
Beta Was this translation helpful? Give feedback.
-
Hello dear community!
I would like to use a backup strategy and would like to ask you for advice.
The goal is to be able to quickly restore the Uyuni server and download the repositories from the internet. So that the server itself including the configuration is backed up (urbackup or barcuda or rsync) but not the repositories. I can load them again quickly.
Which folders and files do I need to back up? Or do you have another idea of how I would like to implement a backup strategy? How do you do it?
Translated with DeepL.com (free version)
Beta Was this translation helpful? Give feedback.
All reactions