There are number of inefficiencies that complicate S3 installation backups. One of them is the fact that save_brm utility called on cluster shutdown doesn't save oidbitmap file.
Here is a simple failure scenario that demostrates this:
1 Install MCS on S3
2 Remove all meta files in /var/lib/columnstore/storagemanager/metadata/data1/systemFiles/dbrm
3 Call mcs cluster stop or save_brm directly
In the end there will data saved on either cache or S3 + .meta files that describes EM files on S3. See the output taken after step 3.

[root@mcs1 dbrm]# pwd

/var/lib/columnstore/storagemanager/metadata/data1/systemFiles/dbrm

[root@mcs1 dbrm]# ls -la

total 32

drwxr-xr-x 2 root root 4096 Jan 27 03:14 .

drwxr-xr-x 3 root root 4096 Jan 27 02:04 ..

-rw-r--r-- 1 root root  247 Jan 27 03:14 BRM_saves_current.meta

-rw-r--r-- 1 root root  246 Jan 27 03:14 BRM_saves_em.meta

-rw-r--r-- 1 root root   63 Jan 27 03:14 BRM_saves_journal.meta

-rw-r--r-- 1 root root  244 Jan 27 03:14 BRM_saves_vbbm.meta

-rw-r--r-- 1 root root  241 Jan 27 03:14 BRM_saves_vss.meta

-rw-r--r-- 1 root root  237 Jan 27 03:14 SMTxnID.meta

MCS complains on its next startup about non-empty EM and lack of oidbitmap file. The suggested solution is to save oidbitmap to save oidbitmap.meta file.