Well, I actually went through all this a few weeks back and here's where I currently stand:<br><br>I installed mythbuntu 8.10 on a fresh 40GB drive with an empty 250G harddrive on an old machine that I wanted to become my permanant backend host. It's a weak machine, 0.5G RAM, AMD Athalon 850 MHz, so I wasn't sure it was going to work in the first place, but I thought if this machine has any life left in it, it's as a server. I unplugged my current backend from my network and plugged the "new" backend in, which had the same host name as the old one. I ran through the Mythbackend setup and did a preliminary investigation of how this thing would handle life as a backend. I was able to set up two simultaneous HD recordings from my HDHR and play one back on my dedicated frontend, with CPU to spare (I think top was something like 0.55 or so). I was pleasantly surprised, so I decided that this was going to work. I went ahead and made a backup of my database using the handy scripts (just had to fight a little with the numerous text files that myth seems to sprinkle about, all with the same information in them). I then move my 160G drive with all my current recordings on them to the new backend, dropped the database that I had created to run my preliminary test, and used the restore script to move my current database to the new backend. If I recall correctly, all I had to change was the storage groups to reflect what I had set up in fstab for my media drives (I just have them mount to /myth/drive1 and /myth/drive2).<br>
<br>So, at this point, I had my database moved over to the new machine, and I had copied my existing media over to the 250G drive with the default storage group pointing to it. The original backend harddrive is unaltered, and the 160G drive is in the new machine, but not being used, just in case I need to throw it back in the original backend and abort the project. I fired up the frontend, and had to struggle a bit to get it working. I'm not real experienced with mythbuntu, but I believe there was a bug when trying to assign a static IP, it kept reverting back to DHCP. So that took a while to get sorted out. (solution: run through the updates. Looks like it was fixed since Mythbuntu 8.10). The second issue I ran into was the password for the MySQL database. I had changed the password just before doing all of this work on my old backend to mythtv from the random one that was assigned when I installed. I'm not sure where I got out of whack, but I think I left the frontend running and connected as I changed the password on the backend, so it was trying to connect with the old password rather than the new one. I'm don't understand how the frontend stores details of the UPNP servers it finds, but even after changing that password on my frontend and successfully connecting, I still have an issue occasionally where it reverts back to the old one. Even though I have selected "Save these backend details" and/or "Save these database details". Either way, so long as the IP on the backend is right, I did not generally have trouble. I was able to see all my recordings, and everything looked great.<br>
<br>Then it all went down hill. Every couple of nights, I would try to watch TV and find that the backend had crashed. I missed recordings, my WAF plummetted since it happened once while I was away on business. The first few times, I chalked it up to a cheap router I was using on the new backend. I switched to a better router, no problems for a few days, I thought the problem was fixed. But then on Friday, I came home, found the backend had crashed again. I re-booted, but the backend will not load X, I just get a command line. I decided to just go back to the original backend hardware, maybe there's some bad RAM or a hardware issue with this backend, but I have no way to use the backup and restore scripts in order to move the database back to the original hardware. So, I've lost a few weeks of the recordings the new backend did manage to make, but the system is stable again. Luckily, the way I did the move, reverting was easy (just plug the 160G drive back in and put the old backend back on the network). <br>
<br>Another thing I overlooked in my overly optimistic test was the effect of commercial flagging. When that's running, and a recording or two started, I think that's what was killing my backend. A couple times I was able to run top with things were about to crash and I could see mysqld and commflag hogging all the CPU and top reported a load of 6.xx at one point!<br>
<br>So, I thank all that chimed in. Even though my attempt was unsuccessful, I was able to revert back without losing much thanks to your help (keep the original system drive, don't change the hostname, the information on storage groups*). <br>
<br>Overall, it's not too difficult to do a migration given the scripts, and if you can leave your original system hard disk and media drive untouched during the move, reverting back is easy, even in the face of catastrophic failure. If I did it again:<br>
1. I would not bother with using such an old machine, just use something you trust (and test while running commflag + transcode + anything else you may be running while live if there's any question of the CPU power required)<br>
2. pay more attention to the frontends and make sure they're not running while doing any maintenance on the backend (I think this polluted something on my frontend causing connection issues with the db password)<br>3. run through the update on the fresh OS install first thing to try to avoid getting dinged by a peripheral issue like the changing IP setting (which was just an annoying issue to track down that was really unrelated to the myth migration)<br>
<br>I still want a nice fresh installation of mythbuntu as a backend, so I'll probably end up doing this again sometime. Now that I've gone through it once I realize it's not *that* big of a task. Again, thanks to the list for the help. You guys rock and so does myth.<br>
<br>* As for the storage groups, the thing I didn't understand when reading about them on the wiki is that you can put several different mount points in a storage group. So, it's easy if you just use "default" to add new storage, just mount the drive in fstab and then add the mount point to the default storage group. I thought each storage group corresponded to one mount point, so I was confused how this was going to help me.<br>