Better support for reading RDM XMLexports to supplement breakglass scenarios
0 vote
Crowdstrike Friday has exposed operating systems and kernel-level software like antivirus as potential single points of failure, causing outages that DR plans may not have adequately prepared for.
We are being asked to enhance the break-glass part of our DR plan to make it more resilient. Everyone in the infrastructure team has hardware-encrypted USB thumb drives they keep with them whenever possible that have exports of RDM/DPS passwords in encrypted zipfiles for maximum portability. Additionally, they have a “portable app”-ish copy of RDM on the USB they can run locally (RDM is usually a published app run out of the datacenter). On a scheduled basis, we run exports via PowerShell to create team-specific backups of just what they should have access to, using all the parameters to include all available data, including attachments and documentation. The issue is how to read the exported RDM file.
Ideally, RDM would be able to natively open an RDM XML export. However, when we add a data source of XML and point it to an 80MB RDM export file, the file is truncated to 5MB and all of the documentation and attachments are gone. Opening an XML backup in RDM would not be a data destructive event. If we create a SQLite data source and import it, we have the attachments but we do not have the documentation tab, However, importing the 80MB RDM file can take 20 to 30 minutes, which would be rather stressful amount of time during a DR.
In summary, we’d love a way for RDM to be able to read an RDM XML export in a read-only, break-glass way that showed all properties, including attachments and documentation.
Hello,
Thank you for the feedback. I will have to check with our devs, but I think the easiest thing to modify in this case would be to improve the SQLite database to support documentation. While I say it's the easiest, it doesn't mean it's simple and there may be limitations to SQLite that I'm not aware of.
Allowing to read the RDM file directly in read-only mode wouldn't be too complicated when it comes to the entry data, but attachments/documents and documentation would be more difficult, which is why it's not the first solution I would focus our efforts on.
Additionally, the performance of the import you've mentioned doesn't seem to normal to me. I imported a 20mb file (~300 entries, multiple documents) and it took less than 15 seconds to import everything. I assume it mainly has to do with what your export contains. Could you give me more information about the data you're exporting?
Regards,
Hubert Mireault