Disaster Recovery in Action: Why Planning Ahead Matters

By: RPI Tech Connect   September 24, 2024

When disaster strikes, is your organization ready to respond? In today’s episode of RPI Tech Connect, Senior Technical Consultant Siva Ramamurthy shares his insights into the world of disaster recovery (DR) planning. From unexpected hardware failures to cyberattacks, disasters can happen at any moment, and without a solid plan in place, the impact on your ERP and connected systems can be severe.

Tune in to hear Siva’s real-life accounts of organizations that failed to prepare, learn how cloud ERP systems like Infor CloudSuite are evolving to protect businesses, and discover actionable steps to develop and test your own disaster recovery plan. Whether you’re well-versed in DR or just getting started, this episode offers expert insights to help you protect your systems and maintain business continuity, even in the most dire situations.

Interested in listening to this episode on another streaming platform? Check out our directories.

Meet Today’s Guest, Siva Ramamurthy

Siva Ramamurthy is a Senior Technical Consultant with over 20 years of experience in technical leadership, project and program management, systems analysis, development, and maintenance with specialization in the Healthcare Payer domain, ERP, and web-based applications. Siva has an extensive background working with business users to elicit and document requirements while creating optimal solutions and designs.

Siva brings a powerful combination of programmer knowledge with project management acumen to his clients. He is a full stack ASP.NET/SQL Server Web Developer as well as an exceptional communicator with the ability to positively influence outcomes, particularly in difficult situations.

Prior to joining RPI, Siva managed multi-national delivery teams with over a decade of work experience, both in the US and in India. His projects have used the onsite/offshore model, waterfall, prototyping, and iterative models. He is also a Certified Scrum Master through the Scrum Alliance and has his PMP certification through the Project Management Institute.

Meet Your Host, Chris Arey

Chris Arey is an experienced B2B marketing professional with nearly a decade of working in content creation, copywriting, SEO, website architecture, corporate branding, and social media. Beginning his career as an analyst before making a lateral move into marketing, he combines analytical thinking with creative flair—two fundamental principles required in marketing.

With a Bachelor’s degree in English and certifications from the Digital Marketing Institute and HubSpot, Chris has spearheaded impactful content marketing initiatives, participated in corporate re-branding efforts, and collaborated with celebrity influencers. He has also worked with award-winning PR professionals to create unique, compelling campaigns that drove brand recognition and revenue growth for his previous employers.

Chris’ versatility is highlighted by his experience working across different industries, including HR, Tech, SaaS, and Consulting.

About RPI Tech Connect

RPI Tech Connect is the go-to podcast for catching up on the dynamic world of Enterprise Resource Planning (ERP). Join us as we discuss the future of ERPs, covering everything from best practices and organizational change to seamless cloud migration and optimizing applications. Plus, we’ll share predictions and insights of what to expect in the future world of ERPs.

RPI Tech Connect delivers relevant, valuable information in a digestible format. Through candid, genuine conversations and stories from the world of consulting, we aim to provide actionable steps to help you elevate your organization’s ERP. Whether you’re a seasoned professional or new to the ERP scene, our podcast ensures you’re well-equipped for success.

Tune in as we explore tips and tricks in the field of ERP consulting each week and subscribe to RPI Tech Connect below.

Transcript

Chris Arey (00:02)

Failing to plan is planning to fail, especially true in the realm of software. Stick around as we explore this concept and what organizations can do to better equip themselves when disaster strikes.

Chris Arey (00:03)
When your system is working as intended, all is well. It’s when the unexpected strikes and your team must pivot into recovery mode that you find out how prepared you really are. The concept of disaster recovery isn’t new. It’s existed for hundreds of years, whether due to natural events or cybersecurity attacks. When disaster hits, you need to be prepared because failing to do so can lead to lost revenue and unhappy customers. So,

What does a disaster recovery plan look like in the world of ERPs? How do you go about forming one? And what happens if you don’t have one in place? Today on RPI Tech Connect, we’re going to find out. Our special guest is none other than senior technical consultant, Siva Ramamurthy. Siva, welcome to the show.

Sivakumar Ramamurthy (00:55)
Hey Chris, how are you? Thank you for having me.

Chris Arey (00:58)
Absolutely, so happy to have you on the program. I know that this is a very important topic to you. before we explore all that, I’d love to hear more about your journey as a consultant and your background. So what can you share with us?

Sivakumar Ramamurthy (01:14)
Sure, yeah. I’m a senior consultant, technical consultant at RPI, and I primarily work on Cloud Suite implementation and support projects for multiple clients. I also do a lot of reporting projects using the spreadsheet server technology and other reporting, info reporting tools. I’ve been with the consulting world, in the consulting world since 1999.

And I played various roles in the SDLC. So developer, tester, PM, you name it, I have done it. Started off as a developer in the Microsoft world, eventually becoming a full stack developer in the .NET and SQL Server technologies. Then I ended up doing more of architecture and design of custom applications, I’ve led multinational development teams and support teams in the past. I’ve also worked as a senior business system analyst, project manager, and program manager in the healthcare, finance, and retail domains. In my previous job, I was a practice director for the Info Practice that had Lawson and Infor capabilities and offerings. So I’ve seen a few things in my life. So yeah.

Chris Arey (02:45)
Just a couple there. Well, thank you again for sharing that with us. I’d to talk more about what disaster recovery is and the importance of it. So let’s go ahead and get into that. I’m hoping maybe we can start by you making, if you wouldn’t mind, explaining why disaster recovery is so important.

Sivakumar Ramamurthy (03:13)
Sure, yeah, I can start with basically defining what it is. Simply put, it’s a plan of action that’s already defined in detail and documented and tested, emphasis on tested, that are needed to be taken when an outage, application outage, in other words, disaster strikes, an IT department or an application. What is a disaster?

Disaster can be like a physical one, flood, maybe war, or any cables getting disconnected and whatnot, as simple as that. Could be hardware failures, and then as I said, power outages, environmental issues, rioting, and whatnot. Disaster can also strike because of software issues.

We recently saw one with the crowd strike, right? So that’s also, that could be a cause. Another major cause can be because of a cyber attack, which is becoming all the more no common in recent years. So in short, any event that causes any disruption to your IT operations, normal IT operations, or a specific system would be.

Chris Arey (04:14)
Yeah.

Sivakumar Ramamurthy (04:41)
Be considered as a disaster.

Chris Arey (04:43)
Yeah. So there’s, there’s a number of different ways that, you know, disaster can manifest and the way that it affects your, your systems. Obviously you need to be prepared on how to address those, those concerns as they happen. And I’m sure like, depending on the type of disaster, there’s probably different protocols for responding to them. Is that, do you agree with that?

Sivakumar Ramamurthy (05:06)
That’s correct, yes.

Chris Arey (05:08)
All right, you know, disaster recovery, it’s this concept that’s been around for a while, but I’m sure throughout the years and over time, especially as software has evolved, that there’s been this evolution in what disaster recovery looks like. So, you know, what is, how has that evolved from your perspective?

Sivakumar Ramamurthy (05:29)
Sure, yeah. So as you rightly pointed out in the beginning of the call, disaster recovery steps of planning has existed in one form or the other since a long time.

And in the initial days of computers and servers, it could have been as simple as backing up your data on a regular basis on a tape, then a floppy, I mean those were standard procedures. Yes, I know. Yeah, yeah. So people used to back it up and kind of label it and store it in a locker in the office or put it in a floppy and whatnot. then came the CDs and the DVDs and whatnot. So those were the earlier days. And then people wanted to know as technology grew,

Chris Arey (06:01)
Taking me back. Taking me back to the early days.

Sivakumar Ramamurthy (06:28)
OK, the DR planning and the infrastructure around that has also grown and kept up. Now we have concepts like multi -location data centers.

If one location goes down because of any reason, becomes inaccessible, you have other locations where your application is, then you have a lot of redundancy, not only hardware and servers, but also in network and resources, IT resources who actually maintain this.

You have concepts like the failover servers, right? That kick in as soon as there is a failover. This is far cry from the days when backups were being taken locally on a tape or a floppy disk. So we have come a long way and we are still evolving and technology is definitely as the technology improves as we have systems which are kind of, you linked over the internet and new concept coming. The world is also kind of evolving and trying to keep up.

Chris Arey (07:37)
Yeah, sure. I definitely think there’s been some development there from physically storing data on a hard drive or paper documents in a file cabinet to now in the cloud, for example, and these multi -location data centers that you mentioned. There’s fail safes that are in place that when something goes down, there’s something else that you can fall back on. that right?

Sivakumar Ramamurthy (08:00)
Yeah, in fact, there are systems where as soon as there is a failure, you have redundant systems that just come up. And for the end user, it’s just seamless. In fact, it’s almost 100 % uptime for the giant, say, e-commerce providers and all. They cannot afford to be down for even a few seconds. It’s loss of business. So there are no.

Chris Arey (08:25)
Yeah.

Sivakumar Ramamurthy (08:28)
Systems which are almost 100 % of time. There’s never 100 % like 99 .9 % or whatnot, but it’s almost 100%. And that disaster recovery is seamless to the end customer. Yeah.

Chris Arey (08:43)
They can’t even tell when one thing goes down and the other comes up to support it. That’s what you want too, right?

Sivakumar Ramamurthy (08:47)
That’s right, yeah. That’s the ideal situation, but again, real life is far from ideal as we saw recently.

Chris Arey (08:57)
Yeah. So we’re talking about disaster recovery in the world of ERPs. like enterprise resource planning systems, they’re big. And a lot of times there’s other like point solutions that are connected to that core software. So is it probably a good idea to have like your DR plan should be able to support those third party connections too? like, what is, you know, how do these things connect and what does that process look like?

Sivakumar Ramamurthy (09:26)
Yeah, thank you for mentioning that. I think you’re right. mean, one is your core ERP for which, obviously, that’s your core business ERP, and then you need to have a disaster recovery plan. But if you have other systems that you own, not necessarily the third party systems, which you may not own, but you may integrate, your DR you know, exercise or the plan should include all the systems that you own that work and interact with the DR with the sorry with the ERP.

Then you should also make sure that your third party application providers have their own DRs so that if there is an issue there, your business is not disrupted.

And then again, your DR plan should include testing of those integrations in case of a DR, in case of a disaster at your end or at the third party end. But to answer your question, your DR plan should include your ERP and all the systems that interact with your ERP and that you own.

Chris Arey (10:48)
That makes sense. You’re running a business, you’ve included these other applications to support your main objectives. It follows then that if you’ve got a plan in place for when disaster strikes, that you should be accounting for all the tools and software that you’re using.

Sivakumar Ramamurthy (11:06)
That’s correct, yes.

Chris Arey (11:08)
Okay, so we’re talking a lot about now what disaster recovery is, what should be included in a plan. I’m hoping now we can maybe pivot and talk a little bit more about the process for creating a DR plan and maybe the team that’s involved with kind of managing and executing that plan when and if they need to use it.

So could you talk about the process for that, Siva?

Sivakumar Ramamurthy (11:37)
Sure, yeah. So I mean, to keep this discussion kind of simple, let’s take a scenario where you have a Lawson installation, and your application and your databases are on the virtual machine. So in this scenario, the first thing that you would do is identify, obviously, all the systems that you own and that you host on the VM or third party, whatever the case may be.

And list out all the stakeholders. So who are your technical stakeholders and who are your business stakeholders? So as an example, in this system, you would have a Windows Server Admin. And this person or a team, depending on the size of your organization, would actually be maintaining the VMs and the servers.

Then you have Database Administrator or the DBA team itself. Again, depending on the size of the organization, could be a single person or a team. In most cases, a DBA would be a different resource than a Windows administrator. Then you have the application administrators. It’s the loss of administrator who on a day -to -day basis do the installation and maintenance of the application. So those are an important stakeholder. Then the application owners.

It’s the business stakeholders, the people. They are the most impacted. They are the non -technical resources, but they are the most impacted in case your loss and system goes down or your ERP system goes down. They are needed to provide inputs as to how long they can wait to get the system back. So that’s one of the parameters that you take into consideration when you plan a DR.

And they are also important to do the testing when the systems are back up. So those are the people. Then your team would, your disaster recovery team would have a project manager. And this person would be responsible for bringing all the stakeholders together, planning the meeting, documenting the steps needed in the DR plan. And eventually this person would lead.

Chris Arey (13:58)
Yeah.

Sivakumar Ramamurthy (14:03)
The DR testing also. And apart from that, then you have the IT head or the sponsor of the DR project itself. It could be an IT director, or it could even be a CIO, however, depending on the size of the organizations. So that’s how you basically start talking about this, set up a team. Then it doesn’t end there.

So once the team comes and meets, they basically have to know each stakeholder will be providing their steps that are needed to bring a system back in case of a disaster. And this should be documented. And the stakeholder is clearly identified.

Their backups should also be identified because a particular stakeholder could be either out of office or busy with other things. So you need to see who are the stakeholders who can be reached in case of a disaster and their backups as well.

Yeah, apart from these steps, you should also have details on who can declare a disaster. So not everyone can just say, hey, if a particular feature of the application is not working, you don’t call a disaster. Yeah, right? I mean, could. my god, I know I tried to save something and my entry did not save. I don’t call it a disaster.

Chris Arey (15:29)
Ha! That’s a great point, actually.

Sivakumar Ramamurthy (15:45)
It’s actually a bug in the application. So there are protocols to identify what a disaster is and which individual or a set of people can call a disaster. So that’s also important. So those things are documented. And then that’s tested. But there are a couple of parameters that I want to identify that are very important.

Chris Arey (15:48)
Yeah.

Mmm.

Sivakumar Ramamurthy (16:15)
Those are recovery time objective and recovery point objective. So there are two critical parameters. One is the recovery time objective, as the name states. It’s the time that the system can be down, before which the disaster should be recovered. For some business, it has to be near real time. But in other cases, if there is a disaster.

Chris Arey (16:37)
Yeah.

Sivakumar Ramamurthy (16:43)
You may be able to wait for a few hours, maybe even a couple of days. So that is an important parameter that needs to be considered when you actually plan a DR. Depending on that, you will need to plan for the infrastructure, whether it’s a cold DR or a warm DR or a hot DR. And then there is a cost implication associated to that.

The second parameter is the recovery point objective. This is how, basically in simple words, is how frequently you should be taking backups of your data. How much data is OK to be lost in case of a disaster? For example, if you are taking backups on a nightly basis, so you took your backup at 1 AM yesterday and your disaster strikes at

Chris Arey (17:20)
Mmm.

Sivakumar Ramamurthy (17:42)
2 PM. That means any data entered between that time will be lost because you have the backup going back. So again, that’s something that is discussed with the stakeholders. If they say, hey, that’s not acceptable, then it may be even a few minutes. You may be taking backups every few minutes, or it could be a mirror database, depending on your requirements. In short,

Chris Arey (17:47)
Yeah.

Sivakumar Ramamurthy (18:10)
It’s just not taking database backups. It is just a step in the whole disaster recovery planning. So I suggest.

Chris Arey (18:19)
Yeah, you mentioned some really great points there and a lot of things to consider too. And it sounds like depending on the type of organization you’re running, there’s probably some compliance requirements there too. We’re like, you can’t be down for more than X amount of time and your whatever like policy or practice you have in place for in turn that any data that’s lost is like, how are you going to address that? That’s a missing data. It sounds like it could be good. Pretty.

Sivakumar Ramamurthy (18:43)
Yep.

Chris Arey (18:47)
Pretty catastrophic there, quickly, you know?

Sivakumar Ramamurthy (18:49)
That is correct. mean, data is now raised, you know, the main thing, right? And yeah, you have to be up as soon as possible. And those are the parameters you need to consider.

Chris Arey (19:02)
So throughout all this, we’ve been talking a lot about testing. And I think it’s an important component of this DR plan because it’s one thing to document your plan and appoint a team and have people processes in place, but it’s another thing to actually run a fire drill and see how things go and see how quickly you can operate. So how would you go about, I guess, defining that testing process? What does that look like?

Sivakumar Ramamurthy (19:31)
Yeah, thank you for raising it. Yes, this is, think, one of the most important step that I would stress. Without this, your DR planning is actually incomplete. So once you have a DR plan, it’s important to put this plan to test and make sure that all the kinks are removed. No, it works fine. Till you do a DR test,

It is just on paper. So a DR testing or a fire drill is a mock drill, which mimics a DR situation. This is a planned one. And you basically bring all the stakeholders and run through all the steps that are in your DR plan.

Take notes the first time you’re probably going to find issues in your steps. Maybe there are steps that are missing. Maybe there are steps that didn’t have the dependencies listed out. Maybe you tried reaching out to some stakeholders you couldn’t. This is a learning opportunity for you. You take notes, you meet, do a lessons learned review, and fix the DR plan. You rinse and repeat.

Till you have a working plan. So that’s key. This step, I keep talking about this step a lot with my clients because this is a step I’ve seen gets neglected or people, once they meet and have a DR plan, they kind of assume that this will work. But we have seen in many DR drills that there are steps missing or there is an opportunity to improve.

Chris Arey (21:01)
Yeah.

Sivakumar Ramamurthy (21:27)
Another important reason why you do this is once you have a working DR plan, when you do a DR test exercise, you time it. When you time it, you know how long it’s going to take for you to bring the systems back up in case of a disaster. That is like a baseline.

That way you know if the systems go down for real in the future, you can say more predictably when they will be back up. Sometimes if you don’t test it out, you would not know how long these steps take. In real, they may look very simple on paper, but when you may end up spending a lot of time in it, and you may end up seeing issues as you do it. So what I would say is let’s never skip this step.

Chris Arey (22:17)
Mm.

Sivakumar Ramamurthy (22:27)
And this should happen at regular intervals of time in any organization. So I’ll end this question with saying, if you sweat more in peace, then you bleed less in war. So that’s my philosophy.

Chris Arey (22:44)
Yeah, that’s awesome. I love that. That’s a, you had one sentence to summarize what we’re talking about here. It’s that line, you know, I think that really captures it. So thanks for that. And, know, you’re talking about testing and even like just taking the time to really like get it, your recovery response, like process to the place you want it is going to, is going to, I think, save you in the end. When you look at that,

Crowd strike incident, you know, they’re calling it one of the biggest outages in history and You know over eight point five million systems crash. They estimate over ten billion dollars. It’s like they had a plan in place but Whatever happened like they I guess I didn’t account for they could have tested more or had more up I guess maybe more checkpoints along the way to kind of like continuously work at that

Sivakumar Ramamurthy (23:20)
Yeah.

Chris Arey (23:39)
At that plan because it’s not a set it and forget it type activity it sounds like. It’s something that really needs to be prioritized like ongoing. Is that correct?

Sivakumar Ramamurthy (23:48)
That is correct. So any releases that’s done, obviously, there are release plannings and whatnot. In spite of all the great systems that we have, checks and balances, you still had that. So just imagine not having any plan, and you have issues. And I can definitely give examples as we talk. You would have basically be

Chris Arey (24:03)
Yeah.

Sivakumar Ramamurthy (24:17)
Starting from scratch. So those kinds of incidents are wake -up calls. For all of us, if you don’t have one, you have to start thinking about the DR steps and what.

Chris Arey (24:24)
Yeah.

You had such a great point you may mention that too. It’s like they say that the crowd strike incident It was fixed within hours, which is pretty quick but like because a lot of these things needed to be fixed manually like the trickle -down effect and you’re mentioning like if you don’t have any plan in place like You know those those statistics I mentioned earlier with the millions of computers outage and the billion dollars in lost funds. It’s like That could have been so much worse if there was nothing in place. So like

Sivakumar Ramamurthy (24:58)
Far worse. Yep.

Chris Arey (25:01)
It really hits home and demonstrates the point that like, need to be, you need to be, you need to have something in place and you need to be working at it all the time. So we talked about that. I’m wondering now, in your experience, being a technical consultant in all these roles you’ve had throughout your career, is there anything you can share from the road of consulting?

Sivakumar Ramamurthy (25:04)
That’s correct.

Yes, definitely. I I’ve seen in my career more than once issues that we have faced when DR plans have not been in place. I’ll share with you a couple of incidents without going into details. We had a Lawson client on prem. They were on Lawson for many years.

They were owning the servers. Those were physical servers. They used to take backups of their data in tape. This is many years back. And they thought they were all set. But as I said, DR planning is just not taking backups. It’s actually testing your process of recovery end to end to make sure they work.

Chris Arey (26:05)
Yeah.

Sivakumar Ramamurthy (26:22)
So unfortunately, there was a hardware issue on their production database server. And they went down. And they could not fix the hardware issue. And they couldn’t even recover the tapes that they had back onto another database. So the whole process of recovering data from the tape was never tested.

Did they have the backup? Yes, that’s checked. But did they test it out? And this is a real story. And they were actually down for weeks. And they lost a lot of data also. This is one example. Another incident, that client was on a third party hosting. And they had multiple servers and whatnot, but they did not have a DR plan.

Chris Arey (26:58)
My…

Sivakumar Ramamurthy (27:22)
Again, backups were being taken regularly. But since they did not have a DR plan, the hosting provider had an outage, again, it was a hardware. I think it was a network issue. Again, they took a few days to recover. Then there was a hardware failure. So basically, multiple things went wrong. They were production down for a few days. Because again, we didn’t have a plan. which was tested and not Listed out anything on paper.

Chris Arey (27:59)
Yeah. Your disaster recovery plan is more than taking backups. that’s, that’s, shouldn’t laugh because you know, people had to learn the hard way here, but man, you know, and today’s with all the software and tools and resources available now for kind of making sure that there’s a fail safe in place. You would just hate to be in a situation like that where like all you had was backups and.

Sivakumar Ramamurthy (28:03)
Yeah, that’s the correct.

Yeah.

Chris Arey (28:26)
It don’t even work! It sounds like that first story you had there that the backup didn’t even do what it needed to.

Sivakumar Ramamurthy (28:31)
Correct. mean, they had the backup, but they didn’t have a means to restore it back. yeah, and I mean, the sad thing is I was the applications guy and I could do nothing because it was a hardware failure. Okay. And they had to go to the vendor to get a different piece of hardware, which was not available. The whole stress was on the applications and the database team, wherein they did not contribute to it, but we were trying to help.

Chris Arey (28:35)
I see. Ugh.

Sivakumar Ramamurthy (28:59)
But we couldn’t really do anything without a working backup. So that was sad. was all quite stressful for the stakeholders as well as for the other IT people who were involved.

Chris Arey (29:13)
Got it. Okay. Well, hey, listen, we’re getting close to time here. So I want to thank you again for all the great insights you shared so far. Before we wrap up, I’d like to ask my guests if you could offer today’s audience one piece of advice regarding today’s topic. So for us, that’s disaster recovery. What would be your one actionable takeaway for them?

Sivakumar Ramamurthy (29:36)
Yeah, thank you. Yeah, I think one takeaway for everyone, regardless of where you are in the organization, in the hierarchy, is if you’re a stakeholder in an application or multiple applications, check if that application and the dependent systems have a DR plan in place. And find where it is. Check when was it revised last.

And if there was a DR test done, if yes, when was the last time it was done? If it was more than one year, then you know you need one DR testing exercise. And you raise it as a red flag to your management, to your manager, whosoever needs to know that this is a big risk to the organization or for the applications that you are a stakeholder in.

That is one. The second one is no Yeah, I mean that that’s the one that’s where you start basically. So yeah.

Chris Arey (30:40)
You have a… Okay. You got something else you want to share there? I haven’t had two takeaways, but if you’ve got something that you just got to get out there, I encourage you to share it.

Sivakumar Ramamurthy (30:49)
Yes, I would say if you see, and I would say go ahead and recommend a DR plan at least once a year if nothing has changed.

But if things are changing, like if your application topology is changing, if you making changes to your integrations, adding additional applications in your application suite, or if there is a major change in your IT stakeholders or non -IT stakeholders that also warrants a DR testing exercise because you need new people to learn the steps. And also, if there is a change in the application topology, your DR plan needs to keep up. So that’s my second takeaway. But the first one is where you start. And that’s the critical one.

Chris Arey (31:37)
Yeah, no, I thank you for sharing that. You don’t know what’s going on unless you look under the hood. And once you do, you need to take steps towards improving your recovery plan there. And RPI consultants assists with developing recovery plans. Yeah, that’s something you’ve helped with here.

Sivakumar Ramamurthy (31:58)
Yes, we can definitely help clients who are, say, if you’re on Lawson, on -prem, or hosted by a third party. We can definitely help you come up with a DR plan if you don’t have one. We can work with your PMs to identify your stakeholders, like the DBAs and your server administrators, the third party hosting providers.

If no, we can work with all of them. Come up with a plan, we can also help lead the DR, not testing exercise. But if, yeah, and if you already have a plan and a team, we can also come in as just application, you know, from an application point of view to kind of fill in that gap, if you have.

Chris Arey (32:35)
Awesome.

Awesome. Thanks for providing some insight there. And for those of you listening in, if you need help with disaster recovery, we encourage you to reach out. Thanks again for tuning in today. If you have questions about today’s segment or cloud suite or disaster recovery, please email us at podcast@rpic.com. Again, that’s podcast@rpic.com. This is RPI Tech Connect and I’m your host, Chris Arey. We’ll see you next time.

Sivakumar Ramamurthy (33:16)
Thank you. Bye bye. Thanks for having me.