import /images from another fog install without access to it
-
Hi, need help as all my images are out of reach…
here is the thing
I have lost access to my old fog server install (VM installed on a dead disk) but still keep all my images on a .vdi
I have installed another fog server on a new VM (now in a RAID disk :)) and added that old .vdi as a new storage node (i can see the storage on fog dashboard) but Fog server can not see the images as I can not access my old database
Is there any way to recover those images and be able to manage them in my new fog server?
thank you!
-
@doc Ok you will have to rebuild the database a little from the raw data, a little from your best guess, and the rest from luck.
On the old disk the files should be in a /image directory (or partition root) on the imported virtual disk.
Did you connect this disk in linux to the FOG server?
The first step is doing that.
The next step is to decide if you will leave these raw image files in this virtual disk or move them?
Once we know that we can work out a plan to get things connected for you.
Also having an output of these commands posted here in this thread would be helpful.
df -h
lsblk
-
@george1421 , thanks a lot for your support
yes, I have connected this .vdi to my new Centos Fog server and is detected as /dev/sdb and mounted at /mnt/sync as a 20T drive
if I explore that disk I can see all the folders containing the images done before
This disk worked as a second storage node on the previous install and the idea is to keep it like that. In fact, that is what i have done, now I can see on the dashboard both nodes (default and sync) but i only plan to use the second node for imaging.
I cannot access my system until tomorrow
thank you
-
@doc Ok then you are most of the way there.
One comment, you can also mount /dev/sdb1 over the top of /images (you will need to copy a few files first) to make the extra disk transparent to FOG. This would also allow your to expand the vmdk to add additional storage to FOG without messing with the OS disk.
OK so you have the disk mounted and you can see it within the FOG ui. So what you need to do is make new image definitions using the current path and image name of your image #1. Its OK if the raw image files already exist, creating the image definitions only make the place holder in the database.
You will need to make your best guess for target os, The encryption stuff is only looked at during image capture, make your best guess there. During image deployment FOS Linux just reads the compressed file and decompresses regardless of how it was compressed during image capture.
-
@doc As George said it’s best/easiest to mount that .vdi (/dev/sdb1) directly into /images directory so you don’t have to mess with FOG settings. As preparation you might want to run the following commands and post output here so we can give hints on necessary steps to make this work:
ls -al /images ls -al /mnt/sync
-
Hi, Here you have
[root@fog sync]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 8.7M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/centos-root 20G 3.0G 18G 15% / /dev/sdb1 17T 1.9T 15T 12% /mnt/sync /dev/sda1 1014M 150M 865M 15% /boot /dev/mapper/centos-images 26G 33M 26G 1% /images tmpfs 379M 0 379M 0% /run/user/0
[root@fog sync]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 50G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 49G 0 part ├─centos-root 253:0 0 20G 0 lvm / ├─centos-swap 253:1 0 3.9G 0 lvm [SWAP] └─centos-images 253:2 0 25.1G 0 lvm /images sdb 8:16 0 18.1T 0 disk └─sdb1 8:17 0 16.5T 0 part /mnt/sync sr0 11:0 1 1024M 0 rom sr1 11:1 1 1024M 0 rom
[root@fog sync]# ls -al /images/ total 4 drwxrwxrwx. 4 fogproject root 61 Oct 29 18:09 . dr-xr-xr-x. 21 root root 4096 Oct 29 18:50 .. drwxrwxrwx. 3 fogproject root 46 Oct 29 18:09 dev -rwxrwxrwx. 1 fogproject root 0 Oct 29 18:09 .mntcheck drwxrwxrwx. 2 fogproject root 30 Oct 29 18:09 postdownloadscripts
[root@fog sync]# ls -al /mnt/sync/ total 4 drwxrwxrwx 37 fogproject root 4096 Oct 27 15:04 . drwxr-xr-x. 3 root root 18 Oct 29 17:43 .. drwxrwxrwx. 2 root root 113 Mar 5 2021 centos2021_sync drwxrwxrwx. 2 root root 222 Oct 27 15:03 corp_HP_manu drwxrwxrwx. 8 fogproject root 178 Oct 27 15:04 dev drwxrwxrwx. 2 root root 266 Mar 1 2021 grafi06 drwxrwxrwx. 2 root root 266 Sep 8 09:51 grafi18_AZK drwxrwxrwx. 2 root root 266 Sep 23 15:22 grafi19_AZK drwxrwxrwx. 2 root root 266 Mar 5 2021 grafismo0 drwxrwxrwx. 2 root root 266 Feb 18 2021 grafismo03 drwxrwxrwx. 2 root root 266 Feb 16 2021 grafismo04 drwxrwxrwx. 2 root root 266 Feb 18 2021 grafismo05 drwxrwxrwx. 2 root root 266 Mar 5 2021 grafismo08 drwxrwxrwx. 2 root root 266 Feb 12 2021 grafismo09 drwxrwxrwx. 2 root root 266 Mar 4 2021 grafismo10 drwxrwxrwx. 2 root root 266 Apr 14 2021 grafismo11 drwxrwxrwx. 2 root root 222 Oct 27 14:15 grafismo_oct2021 -rwxrwxrwx. 1 fogproject root 0 Feb 8 2021 .mntcheck drwxrwxrwx. 2 fogproject root 38 Feb 8 2021 postdownloadscripts drwxrwxrwx. 2 root root 266 Mar 15 2021 qc02 drwxrwxrwx. 2 root root 266 Mar 15 2021 qc03 drwxrwxrwx. 2 root root 266 Feb 22 2021 QC_MEDIA drwxrwxrwx. 2 root root 113 Jun 28 15:32 resolve01_azk drwxrwxrwx. 2 root root 222 May 14 17:20 vfx06 drwxrwxrwx. 2 root root 266 Apr 21 2021 vfx07 drwxrwxrwx. 2 root root 266 May 12 11:38 vfx12 drwxrwxrwx. 2 root root 113 Jun 24 20:19 vfx15 drwxrwxrwx. 2 root root 116 Jun 24 15:56 vfx15_legacy_maya drwxrwxrwx. 2 root root 113 Sep 14 17:02 vfx18_3d2021 drwxrwxrwx. 2 root root 89 Mar 15 2021 vfx19 drwxrwxrwx. 2 root root 89 Mar 15 2021 vfx20 drwxrwxrwx. 2 root root 113 Apr 14 2021 VFX2021_nvidia_def drwxrwxrwx. 2 root root 113 Jul 26 10:52 VFX2021_update_Julio drwxrwxrwx. 2 root root 113 Jul 7 15:45 vfx25 drwxrwxrwx. 2 root root 266 Apr 14 2021 vfx28 drwxrwxrwx. 2 root root 113 Apr 23 2021 vfx31 drwxrwxrwx. 2 root root 246 Feb 11 2021 win10test_pxe drwxrwxrwx. 2 root root 222 Feb 9 2021 z8_win_prestamo
as /mnt/sync and /images have the same folders (dev & postdownloadscripts and .mntcheck) it should be ok to just mount /dev/sdb1 on /images, right?
should I undo the 2nd node config on fog before?
FYI, on the previous install, i had /sync as a 2nd node also, so maybe I should keep it like that to match the same paths when creating the images???
thank you
-
@doc said in import /images from another fog install without access to it:
as /mnt/sync and /images have the same folders (dev & postdownloadscripts and .mntcheck) it should be ok to just mount /dev/sdb1 on /images, right?
That is what I would do to have a clean nice setup.
should I undo the 2nd node config on fog before?
FYI, on the previous install, i had /sync as a 2nd node also, so maybe I should keep it like that to match the same paths when creating the images???That’s the other route you can go. Either way should work but this is more prone to errors in general. But if you’ve set it up this way already you might just go this way. If you know the right places to change all the settings (/etc/exports, web UI) you can switch from one to the other as you like.
-
@sebastian-roth done, /dev/sdb1 mounted on /images
now, the 20T drive is on the default storage group
I create images on fog with the same names as the ones on /images (the old ones) but is keeps saying that its size is 0.00B
-
@doc said in import /images from another fog install without access to it:
but is keeps saying that its size is 0.00B
That’s fine. The size is only updated whenever the image is being captured again. Don’t worry about it and just start deploying those existing images to hosts.
-
Well, as you said, naming the images as their previous names worked!
I have lost the hostnames registry and groups, but at least I have recovered the images
Thanks a lot for your support, much appreciated
Best
-
@doc Having backups would have saved you some pain, but you can rebuild it.
Understand this memory is vague, but I seem to recall if the fog client is installed on your target computers, when the fog client checks in, the registration will be created, but in a pending state, where you need to authorize the client in the FOG Web ui. If it still works that way, this may be a way to rebuild the registrations without much pain. The other options may be to add the hosts via a csv file into the host table, there may be a web ui option to import hosts too. You will at least need hostname and mac address.