Copy images from dead 1.2.0 server to new 1.4.0 server
-
@george1421 We are looking at 8 images, though some may not need to be transferred. I am able to recreate their path’s in /image/ and they do have descriptive names so I know the operating system. The problem to me is that when I look at the images in the FOG web interface, they say “No valid data”. Is this a symptom of having the wrong image manager or image type?
-
@ECRTechZ Just be aware that the bit size and capture date is only populated at the time of image capture. If you migrate the files from another server this count and date will be nil. That is normal.
I think the developers were working on an agent to scan the image store and update the image size in the web gui. I’m not sure where that was in the development timeline. But for now if the byte count is zero for migrated images that is normal.
-
@george1421 Excellent! I’m glad to hear it. Saves me a couple hours of creating images. However, given I do not have the original settings for the images. Do I have to just guess what the Image Manager and the Image Type were? Or is there a good way to tell?
-
@george1421 The “image size” service has been implemented for a while now, but it only works in regards to “Size on server”, not the size the disk needs to contain.
-
@ECRTechZ AFAIK There isn’t a solid way to tell. If the original file dates are before FOG 1.2.0 was released then its probably a PartImage format. If after 1.2.0 was released then maybe a partclone as the first test.
The developers may know by looking at the names of the files in each directory. But its probably going to be a long day testing to find just the right mix.
You may be able to move the database files to the new server and mount them with mysql. I’ve never done it this way, but it may be possible to get at the image data.
-
@ECRTechZ For 1.2.0, images captured during it will be simply “partclone gzip”. The “split” file system should also work due to how it builds the data structure. That said, while knowing the image manager is important, the feature to change the manager didn’t arrive until later on in the 1.3.x series. Specifically it was including with 1.3.5. This feature is more towards telling the server how to capture the image (though is used to help with deploying the image.) If you migrate your images over, more than likely the “defaults” during the definition creation will be fine.
-
@Tom-Elliott said in Copy images from dead 1.2.0 server to new 1.4.0 server:
The “image size” service has been implemented for a while now
Well I wonder where I’ve been all this time Well done!!
-
@Tom-Elliott @george1421 Alright, I’ll just copy the images over and see if they work with the defaults (Given the technician before me, and knowledge of the company I imagine most of them are). Both of you were a great help!
-
@ECRTechZ This is probably what you’re looking for: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
-
@Wayne-Workman The problem with those articles is that they assume the old server is accessible. In my case, it’s dead. I recovered the images and manually created their image definitions in the new server. I’m just hoping they are the defaults. Looking at the files they seem to be though. The only other thing I can think to do is do what @george1421 said and try to mount the old database in the new server and export it, as I have the old servers database. I’m going to try to image a computer using my manually created definitions this week and hope it works.
Thanks for the help!
-
@ECRTechZ said in Copy images from dead 1.2.0 server to new 1.4.0 server:
The problem with those articles is that they assume the old server is accessible.
The guide only requires that ssh is accessible. The web interface can be nonfunctional. If you don’t have ssh, then yeah the only thing to do is mount the disk on another box as you’ve done and just copy the needed things from it.