Manage AWS Cost Using Nimesa 4 months ago

To manage cost the first approach organization take is to power on/off the resources in non-business hours. It is not difficult to write a simple schedule to power on/off the resources at a specific time. There are many things that a simple script/scheduler cannot do. Business will need the following in addition to just Power on and off feature of the scripts.

  • Grouping – Not all resource needs to be powered on and off at the same time. There should be grouping based on business needs
  • Policy Based – Easy to suspend schedules when the team needs the resource. Resume the schedule once the job is over.
  • On Demand operations- Initiate an on/off operations outside the schedule
  • Reporting – Generate reports that give insight into the cost saving of the policy
  • Dashboard – Provides overall cost savings with the policies
  • Ease of use – Provides a simple UI that is usable by non-developers
  • Consistency – Every business unit takes their own approach and difficult to create a uniform approach across the company

In this blog, I will go over how Nimesa helps in solving the above challenges.

Creating Schedule

To create a power management schedule, select “SLA Policy” -> “Power Management” option. Nimesa offers multiple options like creating a schedule just to “Power ON” or “Power OFF” or both “Power ON and OFF”. Admin can group the resources based on Tags or he can pick the instances individually.

Once the policy is saved he can see the approximate savings in $ based on the resources he has selected.

  Managing the Schedules

Admin can pause the schedule when they don’t want the schedules to be applied.


They can also trigger on-demand operation to turn on or off the resources in the policy using “Run Now” option.

As you can see Nimesa is very simple to use and provides centralized policy based power management. You don’t need to maintain scripts to keep up with the changes in your environment and AWS public APIs.

About Nimesa

Nimesa is an enterprise-class Application Aware data protection, cost management & copy data management Solution for applications running on AWS. It uses native AWS capabilities like EBS snapshots capabilities to automatically protect the environment. Nimesa provides simple policy based lifecycle management of snapshots and clones of EC2 instances

Automate Backup of EC2 instances using AWS snapshots 4 months ago

AWS provides the capability to take the snapshot of EBS volumes, but there is some manual effort involved in the process which can result in human error. First approach companies take is to automate using scripts. With ever-growing resources in the infrastructure, it would be difficult to keep the scripts up to date to support the company needs. There is a need for robust automation that can be configured once and forgot.

It is very critical for the business to protect their data on regular basis, and EBS snapshots are an important part of the strategy. If you are running scripts, it would be very difficult to make sure the scripts are running consistently. Someone needs to verify/update the scripts, when there are changes to EC2 instance, like removal/addition of EBS volumes.

What if the script failed and it was detected only now? It is important to make sure everything is running as per the SLAs of the business requirement.

Nimesa offers flexible snapshot policies where say, if the business wanted to protect their business-critical instances on an hourly basis and would like to keep 1 week worth of snapshots, whereas for test and dev instances take a daily snapshot and retain for 2 weeks. Email notification is sent for all successful/failed operations with relevant details. Nimesa helps in bringing back the instances from the snapshot instantly when the EC2 instance is not in the desired state.

In this article, we will see how Nimesa can be used for automating snapshots for EC2 instances and related EBS volumes on a regular basis

First Step is to create application policy with required retention. In Nimesa go to “SLA Policy” menu and select “Application policy”.

Create a new “Schedule policy” from “SLA Policy” menu. In this example, we have created a fourth hourly schedule.

Create a new backup group by selecting the required instance and associate Application Policy and Schedule policy created in the previous step.

Our dashboard gives a comprehensive view of the number of instances in the account, how many of them are protected and are they meeting the business SLAs of snapshot schedules like an hourly snapshot. In case any of the backup schedules fails automatically it is flagged in the dashboard.

About Nimesa

Nimesa is an enterprise-class Application Aware data protection & copy data management Solution for applications running on AWS. It uses native AWS capabilities like EBS snapshots capabilities to automatically protect the environment. Nimesa provides simple policy based lifecycle management of snapshots and clones of EC2 instances

Contact Nimesa @ sales@nimesa.io

Restore AWS EC2 instance using Nimesa 4 months ago

In the previous blog, we saw how to use Nimesa to protect the data at a periodic interval that meets organizations SLA needs. Protecting the environment is just one part of the story, a company needs a different level of restore options for different scenarios. Manual restore of data is not impossible in AWS but it’s very time-consuming. IT admin needs to find the associated volumes and find the snapshot, create volume from the snapshot and recover the data. Once it’s done he also needs to delete the unused volumes so it does not add to the cost.  The whole process can be automated but IT admin needs to write a script and also maintain the script. Restore also involves different scenarios which you will be seeing below.

Here are some of the scenario encountered by the organization when they have to restore

  • One straightforward scenario is the whole instance got deleted or entered into an undesired state user needs to restore the whole instance.
  • One of the EBS volumes got corrupted. In this case, an admin would like to quickly replace the volume with a volume from a stable snapshot
  • Few files got corrupted (Like database files, which are big in size) where he would like to recover back those files. In this  admin would like to have the volume from the consistent snapshot presented to the EC2 instance where he can use the native tools to restore the files/applications

Let us see how Nimesa can help in restoring the above scenarios and get the restore completed in Minutes.

In Nimesa, select the backup group and select the appropriate backup select “Restore” option

Full Instance Restore:

Select Full restore option and proceed with the restoration. This will restore the volumes from the snapshot and delete the original detached volumes. Additionally, you can enable postscripts and execute scripts in the instance once the volumes are restored and attached with the instance

 

Single Volume Restore:

For cases where only single-volume needs to be replaced by the volume from the snapshot select volume restore. Nimesa catalogs all the EBS volumes that are associated with an EC2 instance as part of every backup. We can pick the volumes from the list that needs to be restored.

Side by Side Volume Restore:

In case, where the user wanted to manually restore the files within the EC2 instance they can opt for Volume Mount capability where a new volume is cloned from the Snapshot and attached to the instance. This option will add cost post manual restore the cloned volume needs to be deleted.

About Nimesa

Nimesa is an enterprise-class Application Aware data protection & copy data management Solution for applications running on AWS. It uses native AWS capabilities like EBS snapshots capabilities to automatically protect the environment. Nimesa provides simple policy based lifecycle management of snapshots and clones of EC2 instances

Change EC2 instance type with minimal downtime 4 months ago

There are many reasons where you would like to change the instance type.  Some of the scenarios are like a load to the system is high and you would like to increase size for performance and there are situations like your machine is underutilized where you would like to reduce the size to save cost. In this blog, we will see how Nimesa can help you in changing the instance type with minimal downtime.

AWS allows modifying the EC2 instance type from CLI as well as AWS console. Follow the following steps to manually change instance type.

  • In AWS console identify the EC2 instance for which instance type needs to be changed
  • Power Off the EC2 if it is Powered On
  • Select “Instance Settings” -> “Change Instance Type” from Action menu.
  • Select the required type and Apply
  • Power On the instance

Nimesa supports protection of AWS Instances backed by EBS volumes. It is advisable to take a snapshot of the EBS volumes before changing the instance type. In case if there are issues with the instance coming up, snapshots can be used to restore the instance back. Nimesa’s clone feature can be leveraged here to change the instance type verify the new instance and then discard the original instance.

Use Nimesa to backup the instance.

Select the instance and the backup and select clone option. select the instance type in clone instance properties and proceed with the clone. This will create a new instance from the snapshot with the specified instance type. Now you can verify the instance, once everything is working original instance can be discarded.

 

This downtime can be eliminated if the machines are part of ELB. Power off the instance which needs to changed disassociate the elastic IP. Clone the instance from the Snapshot using Nimesa to the new cloned instance associate the elastic IP of the original machine, add the instance to load balancing group.

About Nimesa

Nimesa is an enterprise-class Application Aware data protection & copy data management Solution for applications running on AWS. It uses native AWS capabilities like EBS snapshots capabilities to automatically protect the environment. Nimesa provides simple policy based lifecycle management of snapshots and clones of EC2 instances

Automating DR tasks using Nimesa 4 months ago

Disaster Recovery (DR) is a process that helps you prepare for any kind of unwanted disaster. Cloud platforms like AWS are well suited to meet your DR needs. The organization needs a DR plan that could be periodically tested and should scale with the growth of the data. In this article, we will discuss how to use Nimesa to achieve DR in AWS.

Traditionally organizations were creating Datacenters around the world to keep a backup of the critical data and servers. Amazon has datacenter around the globe with 18 regions and 55 Availablity zones. Just having regular backups will not be sufficient to protect you against the disaster. For setting up a DR plan first need to arrive at the RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

RTO:  It is the time required to bring the environment up and running or in other words how long your company can be offline without incurring a significant financial loss.

RPO: It is the amount of data loss a company can incur with respect to time. This determines the frequency of the backup. In AWS as all services are pay as you use more aggressive backups will add cost to your bill

When we talk about DR, there are various options available for achieving different levels of DR on AWS including Pilot Light, Hot Standby, and Multi-site setup.

Backup and Restore:  It is a simple, straightforward, cost-effective method that backs up and restores data as needed. There is no standby copy, time to bring back the environment will be time-consuming.

Pilot Light:  This method replicates required data based on the RPO and keep minimal infrastructure up and running and bring the environment when required.

Warm Standby: In this method minimal fully functional standby is kept operational in case of DR complete environment can be brought up with seamlessly with minimum downtime.

Multi-Site Solution: Also known as a Hot Standby, this method complete environment is replicated along with data, application and kept running in two or more regions. In the case of DR, everything rerouted automatically with almost zero downtime. But running the environment in multiple regions will incur the cost.

If you need a Higher SLA, automate using Nimesa DR policy and make EBS snapshots available in multiple regions.

Automating DR tasks using Nimesa

DR Policy Creation:

Create a protection policy specifying the primary retention, regions where snapshots need to be copied, and secondary retention. As part of this policy, I have selected 2 regions.

Backup Group Creation:

Identify the critical resources, create a backup group specifying the policy and the schedule. Backup jobs get scheduled at the specified time and after a successful backup, a backup copy job is triggered to copy the snapshots to the specified region.


Job progress shows snapshots that are successfully copied to different regions

Restore:

Select the backup and execute a clone operation. Specify the region on which to be cloned and cloned instance properties. Nimesa will find the suitable image launch the instance and replace the root and the data volumes from the snapshot.

Select the region on which the instance to be restored. Nimesa will automatically pick the compatible AMIs and list. A company can keep a copy of the AMIs in the DR region to have an accurate match.

Additionally, settings like type, VPC, and Elastic IP can be associated with the cloned instance. If this is a test drill expiry can be set and the instance will be automatically deleted after the stipulated time.

Restore Job completed successfully.

 

About Nimesa

Nimesa is an enterprise-class Application Aware data protection & copy data management Solution for applications running on AWS. It uses native AWS capabilities like EBS snapshots capabilities to automatically protect the environment. Nimesa provides simple policy based lifecycle management of snapshots and clones of EC2 instances

 

Recover your datacenter instantly from Ransomware attack (ofcourse without paying) 5 months ago

Recently, An Indiana hospital paid a ransom of $55,000 to get rid of ransomware that had infected its systems and was hindering operations. when attackers breached the network of Hancock Health, a regional hospital in the city of Greenfield, Indiana.

Hancock Health CEO Steve Long said the hackers are believed to be in eastern Europe and may have used a type of ransomware called SamSam,

SamSam encrypted files and renamed them with the phrase “I’m sorry”, according to a local newspaper who broke the news.

The hospital said that despite having backups it opted to pay the ransom demand of 4 Bitcoin, which was worth around $55,000 at the time the hospital paid the sum. Hospital management told local press that restoring from backups was not a solution as it would have taken days and maybe even weeks to have all systems up and running. Hence, they decided to pay the ransom was quicker.

What is Ransomware

Ransomware is a type of malicious software from cryptovirology that threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid. Ransomware is different from other attacks that it’s all about storage.

The hacker’s application locks up your storage by encrypting it and more advanced malware uses a technique called cryptoviral extortion, in which it encrypts the victim’s files, making them inaccessible, and demands a ransom payment to decrypt them and you either unravel the rogue code’s encryption or start learning about blockchain technology and shipping bitcoins into the ether.

Today, ransomware is one of the biggest cyber threats, according to McAfee Labs and Trend Micro. Rapid digitization of consumers’ lives and enterprise records will increase the cost of data breaches drastically. To avoid becoming a victim, users take action to protect their Computers. But waiting ( RTO ) could cost you money, hassle, and negative publicity.

Backup admins should have periodic backups and good data protection with great RPOs and lesser RTOs to survive these attack

Protecting your data from Ransomware

In case of cloud environments ( VMware / AWS ) this is much easier to recover but many times a simple traditional backup app doesn’t provide sufficient defence against ransomware because those applications will backup only the application data of your machine.

Another big concern about ransomware is traditional backup stores their backup on the media server, as they would be susceptible to the same attacks that go after the systems they’re backing up.

If you have a good copy of backup ( recovery point with the pre-ransomware copy of the data) you can recover your data but you still need everything related to operating system settings, application, application settings and the configurations to get up and run again in the production.

Is this sounds like it will take a lot of time to bring back production machine?

Introducing Nimesa

No, With Nimesa, A Best data protection technique which can help business by cloud-based disaster recovery, backup up data and replicate to another site. In case, ransomware blocks you on-prem data you can recover from another site.

 

As Nimesa backups based on the snapshot (snapshots are read-only ). Nimesa helps you recover the data from the good backup copy in minutes.

Nimesa backups the Virtual Machine by taking the snapshot of the Virtual Machine and the volume of datastore ( underlying storage snapshot capabilities) in case of VMware, it creates the snapshot of the Instance volumes in case AWS cloud. In both these cases, Nimesa replicated the snapshot to another site configured by user underlying storage / AWS EBS capabilities.

In case of an attack or data loss user has the option to recover the whole machine or individual disk or even the SQL database inside the Virtual Machine. Nimesa provides data protection with smaller RPO and faster RTO.

 





Your applications run in: