Karl - I haven't done this so I don't know if it will or will not work but maybe.  The documentation for migrating the appliance version of SMG to a new server to run with the non-appliance version has steps to back up and restore the database ans QMS.  You could take this concept and backup the data on your current vastorage disk and restore it to the new vastorage area on the new disk.  

The document in question is here - https://www.novell.com/documentation/secure-messaging-gateway24.3/secure-messaging-gateway/data/t4ommc1terms.html#t4omn4rrrd7x

Check out the section titled Backing up Databases and read through the transferring and restoring of the data.

Pam

Here is another thread: community.microfocus.com/.../replacing-a-old-smg-server. If I remember in the the right way there is an option to replace an existing smg if you install a new one. This option has been added last summer.

However Pam mentions how to migrate from appliance to rpm version which will be a smarter way according to future releases.

Karl,

Have a look at SMG 24.3 Deployment Considerations. There is a section that explains the disk configuration in the appliance. At the same time, the appliances have an issue that can cause a disk to become corrupted. The details are explained in SMG devices are mounted using Device ID.

Karl67 said:

I would like to just add a third disk, move /vastorage over to the new disk and then get rid of the second damaged disk.

/dev/sdb1 is mounted (or should be mounted) at /vastorage which is the main repository of SMG data. Any data written to /vastorage resides on /dev/sdb1. When you say you want to move /vastorage to a new disk, you are really saying you want to copy the contents of /dev/sdb1 to a new disk.

The easiest way to make a copy of the disk is to just make a copy of the .vmdk file but if there are integrity issues with the original disk, there will be integrity issues on the copied .vmdk file. You can use the Linux dd command to copy /dev/sdb to a new device but the result will be the same.

If you "umount /vastorage" then run "e2fsck /dev/sdb1" and it comes back clean, there is no point in trying to move /vastorage to a new disk.

See Cannot check nor repair disk errors on the SMG appliance. It explains an issue I encountered very similar to what you are describing.

Kevin,

the odd thing is that the VMDK, where SDB1 resides on , must have been damaged in a way which hinders Veaam from backing up that second disk. That is what caught my attention.

I moved the whole VA to a new storage with the exception of this damaged VMDK, which could not been moved or repaired by any Veeam- or vSphere-tools. No way.

e2fsck -n /dev/sdb1 worked with the result "clean", that is where my idea of just copying the data came from. I just need the linux-commands for this.

Regards

Karl

Karl67 said:

the odd thing is that the VMDK, where SDB1 resides on , must have been damaged in a way which hinders Veaam from backing up that second disk. That is what caught my attention.

I don't know how Veeam does its backups. If you are backing up the whole VM, it should just backup changes to the virtual disks.

Karl67 said:

I moved the whole VA to a new storage with the exception of this damaged VMDK, which could not been moved or repaired by any Veeam- or vSphere-tools. No way.

If you shutdown the appliance and tried to copy the VM or just the VMDK files, there is no reason why they wouldn't copy. From VMware's perspective, it is just copying files. It shouldn't care what is in those files. 

If you didn't copy the contents of /dev/sdb(1), you didn't copy any of the SMG data so the destination would not be a complete SMG system.

Karl67 said:

e2fsck -n /dev/sdb1 worked with the result "clean"

"e2fsck -n" access the disk in read only mode so it wouldn't have repaired anything. If the result is "clean", there is nothing wrong with the disk.

It's impossible to sort out what actually happened from the information you have provided. I can envision a sequence of events that could account for the observed behaviour...

The appliance mounts the disks by device ID (/dev/sda1, /dev/sdb1, etc). SUSE cautions against mounting devices by device ID and instead recommends mounting my UUID. See the documents I referenced in my earlier post.

Devices are assigned a device ID based on the order in which the OS discovers them. As such, devices cannot be guaranteed to have the same device ID each time the system boots. If a device is assigned the incorrect device ID it can be mounted at the incorrect mount point or perhaps not at all. This is not just a possibility but actually happened to my appliance and was verified by SUSE. One of the symptoms is that /vastorage is empty. This behaviour has been observed on other appliances too.

If /dev/sdb1 failed to mount at /vastorage, /vastorage would appear to be empty and could explain why Veeam was unable to back it up.

The first thing I would do to ensure this doesn't happen (again?) is to ensure your devices are mounted by UUID. The instructions how to do this are provided in a link in SMG devices are mounted using Device ID.

Kevin,

Kevin Boyle said:

If you shutdown the appliance and tried to copy the VM or just the VMDK files, there is no reason why they wouldn't copy. From VMware's perspective, it is just copying files. It shouldn't care what is in those files.

and this copy/movement/backup/converting of the VMDK-file corresponding with SDB1 fails, even with shutdown VA, that is why I need to move the VA to a new storage. Asap.

Kevin Boyle said:

If /dev/sdb1 failed to mount at /vastorage, /vastorage would appear to be empty and could explain why Veeam was unable to back it up.

/vastorage is not empty, /dev/sdb1 mounts, e2fsck shows "clean", SMG is running.

I need to get the data of /vastorage to a new disk.

I do not see, how a change towards UUID would help here with my problem?

Regards

Karl

Karl,

I think some things are being missed in long posts so let's take things one at at time.

Karl67 said:

and this copy/movement/backup/converting of the VMDK-file corresponding with SDB1 fails, even with shutdown VA, that is why I need to move the VA to a new storage. Asap.

If you tried to copy a VMDK file using the VCSA or directly from the ESXi server and it failed, what error message did you get?

Karl67 said:

/vastorage is not empty, /dev/sdb1 mounts, e2fsck shows "clean", SMG is running.

It sounds like everything is good...

Karl67 said:

I need to get the data of /vastorage to a new disk.

so... why is this necessary?

Karl67 said:

I do not see, how a change towards UUID would help here with my problem?

It would likely resolve your problem if the disks are not mounted at the correct location.

The main reason why you should should mount by UUID is to prevent the disks from being mounted at the incorrect location or not at all (again?).

If you need to move the data to a new disk, then:

1. shutdown your smg
2. mount the offending disk on a new linux os, opensuse 15.6 in recovery mode would be fine, or a live version of it works as well.
3. mount old disk in the opensuse os to something like /mnt/oldsmgdata
4. create your new disk and mount as /mnt/newsmgdata
5. run command: rsync -aHAXv /mnt/oldsmgdata/ /mnt/newsmgdata
   this uses rsync to copy as archive with all attributes and rights intact, and in verbose so you can watch it all fly by if that amuses you.
6. shut this temp suse down
7. note the mapping/numbering of the existing drive on SMG
8. remove the old smg data drive from your smg vm, attach the new smg data in in place, making sure it's mapped properly depending on your virtualization software

This is similar steps we use when doing things such as moving /var from root drive and putting on its own dedicated drive.

caveat, if your data is damaged, this won't help.  You'll need to follow steps Kevin Boyle is helping you with to repair the drive