Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
AWS EC2 Instance File Backup?
I have a windows EC2 server that I need to implement file level backup. I have the product Backup Assist. In my previous server, I used to backup to a NAS RAID system. Now, we are using Amazon EC2 instance and I am wondering where I can backup to? I feel if I attach an S3 (?) storage drive that I could backup to this drive. If the server fails, wouldn't I be able to detach the S3 drive and attach it to another server to recover files? Any suggestions appreciated, but please be very clear, I am not an expert with servers or Amazon.
Thanks!
Thanks!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
S3 is not a drive. There is no native NAS support. Using S3 directly as a mounted file system is possible, although not recommended, as there are very little 3rd party stable drivers for windows.
You have 3 options.
1. Mount EBS volumes and use them for backup. EBS volumes work like SAN storage and must be unmounted and remounted to use the backup,
2. Use EFS volumes. Amazon EFS is NAS as a service.
3. Use a complete backup cloud service, like JungleDisk or Cloudberry.
You have 3 options.
1. Mount EBS volumes and use them for backup. EBS volumes work like SAN storage and must be unmounted and remounted to use the backup,
2. Use EFS volumes. Amazon EFS is NAS as a service.
3. Use a complete backup cloud service, like JungleDisk or Cloudberry.
Hi,
If you are just looking to backup the data then store your data on EBS Volume. You can then backup these volumes using the Snapshot feature which will take a copy of the volume and store it on AWS S3 for high durability backup (99.999999999%). If you drive fails you can restore from this snapshot onto another EBS volume and re-attach to your EC2 instance.
It would be worth you creating an AMI of your server once it has been built too. That way if your EC2 instance fails completely you can restore it from your AMI (Amazon Machine Image) quickly and easily.
Please see links below for more information on EBS Volumes, Snapshots, and AMIs.
EBS Volumes: https://aws.amazon.com/ebs/details/
Creating a snapshot: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Restoring a snapshot to an EBS Volume: http://docs.aws.amazon.com/storagegateway/latest/userguide/RestoringSnapshotEBS.html
AWS AMIs: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html
hope this helps,
Cheers,
Stu...
If you are just looking to backup the data then store your data on EBS Volume. You can then backup these volumes using the Snapshot feature which will take a copy of the volume and store it on AWS S3 for high durability backup (99.999999999%). If you drive fails you can restore from this snapshot onto another EBS volume and re-attach to your EC2 instance.
It would be worth you creating an AMI of your server once it has been built too. That way if your EC2 instance fails completely you can restore it from your AMI (Amazon Machine Image) quickly and easily.
Please see links below for more information on EBS Volumes, Snapshots, and AMIs.
EBS Volumes: https://aws.amazon.com/ebs/details/
Creating a snapshot: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Restoring a snapshot to an EBS Volume: http://docs.aws.amazon.com/storagegateway/latest/userguide/RestoringSnapshotEBS.html
AWS AMIs: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html
hope this helps,
Cheers,
Stu...
Thank you both for your responses!
My goal is two-fold. To recover from a failed server and to recover an individual file in case of corruption or needing to rollback to an earlier version. I think combination of your suggestions would work well...
@shalomc I will look into EBS and EFS. I think I would want to be able to unmount and remount the drive in case of failure, right? That way I could move to another server.
@Stu - thanks. I did create an AMI and will do so after significant changes to our server. But how often can I take a snapshot? Can a snapshot be schedule to be created every night and keep the most 5 current (or something like that). It seems that an AMI is more useful than a snapshot as the AMI will recreate the entire server and a snapshot only the XXX?
It's all a bit new to me... I appreciate the help!
My goal is two-fold. To recover from a failed server and to recover an individual file in case of corruption or needing to rollback to an earlier version. I think combination of your suggestions would work well...
@shalomc I will look into EBS and EFS. I think I would want to be able to unmount and remount the drive in case of failure, right? That way I could move to another server.
@Stu - thanks. I did create an AMI and will do so after significant changes to our server. But how often can I take a snapshot? Can a snapshot be schedule to be created every night and keep the most 5 current (or something like that). It seems that an AMI is more useful than a snapshot as the AMI will recreate the entire server and a snapshot only the XXX?
It's all a bit new to me... I appreciate the help!
Hi,
Your AMI should typically be your OS and any apps that you install and then create that as the AMI. Your data should not really be included in your AMI. AMI's are great when you come to deploy more of the same server to potentially scale out using autoscaling should any issues occur with your primary server.
You should keep your data seperate to your AMI as best practise. You can take a snapshot of your EBS volume as often as you like pretty much (up to 10,000 snapshots of an EBS). These snapshots are incremental too.
You can schedule your snapshots with some scripting, take a search on google for 'scheduling aws snapshots' and you should find some help there.
Cheers,
Stu...
Your AMI should typically be your OS and any apps that you install and then create that as the AMI. Your data should not really be included in your AMI. AMI's are great when you come to deploy more of the same server to potentially scale out using autoscaling should any issues occur with your primary server.
You should keep your data seperate to your AMI as best practise. You can take a snapshot of your EBS volume as often as you like pretty much (up to 10,000 snapshots of an EBS). These snapshots are incremental too.
You can schedule your snapshots with some scripting, take a search on google for 'scheduling aws snapshots' and you should find some help there.
Cheers,
Stu...
Thanks again Stu.
My data is in SQL Server on a separate server using the managed database option, so that's not an issue. I am only focused on the OS and files. The files are the code of the website and user files that are uploaded (PDF files, Logos, Images).
So, if I understand correctly, I would use my backup AMI to recreate the server (in the event of a failure) and then apply the latest snapshot to bring it up to date. Do I have that right?
On a side note, could you peak at the attached image. Should I have any concern that the AMI that I originally used to create my server is now no longer available or restricted or something? I have since created several AMIs from my own server, these should be completely usable right?
Thanks again!
AMI.png
My data is in SQL Server on a separate server using the managed database option, so that's not an issue. I am only focused on the OS and files. The files are the code of the website and user files that are uploaded (PDF files, Logos, Images).
So, if I understand correctly, I would use my backup AMI to recreate the server (in the event of a failure) and then apply the latest snapshot to bring it up to date. Do I have that right?
On a side note, could you peak at the attached image. Should I have any concern that the AMI that I originally used to create my server is now no longer available or restricted or something? I have since created several AMIs from my own server, these should be completely usable right?
Thanks again!
AMI.png
There are subtle differences between AMI and snapshots.
An AMI is a bootable image, the AWS version of a vmdk file.
An EBS is a block level device, that can be mounted by operating systems. It is not bootable. An EBS can only be mounted by a single server at a time. Snapshots of EBS can be mounted on another server.
An EFS is a file level device (like NAS), It can be mounted by multiple servers as a shared drive.
To have an effective recovery strategy you need first to define 2 time frames:
The recovery time objective (RTO) is how long can the service be down.
The recovery point objective (RPO) is to what point in time you have to restore your service, or in simpler words - how much time loss of data is acceptable.
I understand that you use Amazon RDS for a database, so lets talk about the application server.
An AMI is an excellent starting point, and an AMI should be created on every major change to the server configuration.
Question is how do you want to deal with minor configuration changes, and whether there is other stuff like log files that you need to think of.
Like I said earlier - the EBS snapshot must be mounted to be used. This makes using EBS snapshots limited to data volumes, as it is less suitable for the main volume.
In practical terms - you have the C: volume with the OS, settings, IIS etc, and in addition you create a E: volume where you place things that change more often like code. E: is on a separate EBS, which can now be used as a basis for snapshots.
Remember that snapshots = money. A hundred snapshots/month will cost you.
An alternative is the "base pie + filling recipe" method, which is excellent if you don't care about logs, and can define all parts of the application.
The pie base can be bought ready at the grocery, and it is your AMI.
The filling is a list of additional ingredients - like your code and IIS settings - that can be applied to a ready AMI.
You place your code on Amazon S3 or on github or on EFS, write a bootstrap script that fetches and install everything, and use AWS CloudFormation or AWS OpsWorks or Chef or Puppet or Ansible to configure a perfect server.
CloudFormation will be easiest to set up, but given a good bootstrap script you don't even need CloudFormation, just bundle it on your AMI and run it manually.
Of course, you can simply use Backup Assist and save to EFS. But where is the fun?
An AMI is a bootable image, the AWS version of a vmdk file.
An EBS is a block level device, that can be mounted by operating systems. It is not bootable. An EBS can only be mounted by a single server at a time. Snapshots of EBS can be mounted on another server.
An EFS is a file level device (like NAS), It can be mounted by multiple servers as a shared drive.
To have an effective recovery strategy you need first to define 2 time frames:
The recovery time objective (RTO) is how long can the service be down.
The recovery point objective (RPO) is to what point in time you have to restore your service, or in simpler words - how much time loss of data is acceptable.
I understand that you use Amazon RDS for a database, so lets talk about the application server.
An AMI is an excellent starting point, and an AMI should be created on every major change to the server configuration.
Question is how do you want to deal with minor configuration changes, and whether there is other stuff like log files that you need to think of.
Like I said earlier - the EBS snapshot must be mounted to be used. This makes using EBS snapshots limited to data volumes, as it is less suitable for the main volume.
In practical terms - you have the C: volume with the OS, settings, IIS etc, and in addition you create a E: volume where you place things that change more often like code. E: is on a separate EBS, which can now be used as a basis for snapshots.
Remember that snapshots = money. A hundred snapshots/month will cost you.
An alternative is the "base pie + filling recipe" method, which is excellent if you don't care about logs, and can define all parts of the application.
The pie base can be bought ready at the grocery, and it is your AMI.
The filling is a list of additional ingredients - like your code and IIS settings - that can be applied to a ready AMI.
You place your code on Amazon S3 or on github or on EFS, write a bootstrap script that fetches and install everything, and use AWS CloudFormation or AWS OpsWorks or Chef or Puppet or Ansible to configure a perfect server.
CloudFormation will be easiest to set up, but given a good bootstrap script you don't even need CloudFormation, just bundle it on your AMI and run it manually.
Of course, you can simply use Backup Assist and save to EFS. But where is the fun?
Premium Content
You need an Expert Office subscription to comment.Start Free Trial