Here is my problem:
Deleted attachments from an app we're using
Attempted a restore from backup but unfortunately the app was not set up to back up needed attachments
The app is hosted in AWS on an EBS-backed volume. I would like to attempt to create a volume from an earlier snapshot which contains the needed attachment files. The question is have is, ServerA is the prod server and ServerB is the staging server, both with completely different/unique FQDNs, if I were to mount the volume from ServerA into ServerB, would that cause any problems with ServerA?
I have tested the mounting method and i know it works. I can mount the volume and then from within the instance, I can mount the volume to a virtual device and then mount that virtual device to a mount point. From there, I can access the files and copy as needed. I just don't want to mess up anything on ServerA since it contains our prod application. Has anyone done this before? Will mounting an earlier snapshot of ServerA onto ServerB cause problems for the live version of ServerA??
Sorry for the confusing explanation.
An Amazon EBS volume can only be attached to one Amazon EC2 instance at a time.
If you have created a new EBS volume from an EBS snapshot, then it is a totally separate volume and may be attached to any instance (prod/non-prod, any VPC, etc) within that Availability Zone. (You nominate the AZ when creating the Volume from the Snapshot.)
No danger will result from mounting your 'restored' volume on any instance. It will not impact your production system. Just think of it like plugging a portable USB drive into a computer -- it will not impact any other drive.
Related
I created two virtual disks for AWS EC2. One is 16G and the other is 100G.
When I connect to EC2 with puTTy it does not show the disks that I created.
Anyone know what the problem is or how to fix it? Thanks.
Make an Amazon EBS volume available for use on Linux
After you attach an Amazon EBS volume to your instance, it is exposed as a block device. You can format the volume with any file system and then mount it. After you make the EBS volume available for use, you can access it in the same ways that you access any other volume. Any data written to this file system is written to the EBS volume and is transparent to applications using the device.
Depending on your requirement you can choose two ways:
Format and mount an attached volume
Automatically mount an
attached volume after reboot
I have two amazon machine instances running.Both of them are m3.xlarge instances. One of them has the right software and configuration that I want to use.I want to create a snapshot of the EBS volume for that machine and use that as the EBS volue to boot the second machine from. Can I do that and expect it to work without shutting down the first machine.
It is well described in the AWS documentation...
"You can take a snapshot of an attached volume that is in use. However, snapshots only capture data that has been written to your Amazon EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by any applications or the operating system. If you can pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete. However, if you can't pause all file writes to the volume, you should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot.
I have amazon as well, with 3 different clusters. With one of my clusters after setting up 25 of them I realized there was a small issue in the configuration and had live traffic going to them so I couldn't' shut down.
You can snapshot the first machines volume while it's still running, I had to do this myself. It took a little while, but ultimately it worked out. Please note that amazon cannot guarantee the consistency of the disk when doing this.
I did a snapshot of the entire thing, fixed what needed to be fixed, and spooled up 25 new servers and terminated the other 25 ( easier than modifying volumes, etc ).. But you can create a new volume with the new snapshot, and attach it to an instance and do what needs to be done to get it to boot off that volume without much of a headache.
Being that I went the easy route of spooling up new instances after my snapshot was complete, I can't walk you through on how to get a running instance to boot off a new volume.
I am facing an architecture-related problem:
I have created a new environment in ElasticBeanstalk and pushed my app there. All good so far. I have set it to auto scale up/down.
My app depends on filesystem storage (it creates files and then serves them to users). I am using an EBS volume (5gb large) to create the files and then push them to S3 and delete them from EBS. The reason I'm using EBS is because of ephemeral filesystem in EC2 instances.
When AWS scales up new instances don't have the EBS volume attached because EBS can be attached to one instance at a time.
When it scales down, it shuts down the instance that had the EBS volume attached, which totally messes things up.
I have added to /etc/fstab a special line that will automatically mount the EBS volume to /data but that only applies for the instance I add the file to /etc/fstab. I guess the solution here would be to create a customized AMI image with that special line. But again, EBS can't be attached to more than one instance at a time, so it seems like a dead end.
What am I thinking wrong? What would be a possible solution or the proper way of doing it?
For some reason, I believe that using S3 is not the right way of doing it.
S3 is a fine way to do it: your application creates the file, uploads to S3, removes the file from the local filesystem, and hands a URL to access the file back to the client. Totally reasonable. Why you can't use ephemeral storage for this. Instance store-backed instances have additional storage available, mounted to /mnt by default. Why can't the application create the file there? If the files don't need to be persisted between instance start/stop/reboot then there's no great reason to use EBS (unless you want faster boot times for your autoscale instances I suppose).
I have an ec2 instance that is hosting a CentOS AMI image and the root device is EBS , however it is not EBS optimized.
I have installed a few packages on it now I want to stop and start it again , Amazon documentation says that the EBS data would be available but the instance store data would be lost.
How do I know where(EBS or Instance store) my packages are stored ? I see that package files are in /opr /var /etc directories .
Will I loose my installed packages if I stop and start the Amazon ec2 instance ?
Thanks.
When you create an EBS backed instance (with ephemeral or instance store storage, and it doesn't matter whether it's optimized or not optimized) you don't lose data in your /opt or /var or /etc directory or any of the system data. So you are safe to stop and then restart it. Keep in mind that your internal and public IP addresses change once you restart it.
The only data that you lose is if you have ephemeral volumes which are generally mounted volumes with devices like /dev/sdb, /dev/xvdb, /dev/xvdc, etc.
If you create an instance store "only" instance then you lose everything. However, you will be able to tell if your instance is this type by not having the option to "stop" it. Meaning you can only terminate it. These are the first type of instances that EC2 offered when they started and maybe up until 3-4 years ago were the only ones, so they are not used that much AFAIK unless you need an ephemeral volume as your root volume.
[Edit]
This is what it's supposed to look like for an EBS backed instance (non-optimized):
You will not lose your data if the instance is setup as EBS.
EBS optimised is another option which adds additional IOPS, useful for busy database applications, etc.
I have just launched the micro instance with Centos AMI image. I have heard that if i stop the instance then my chnages will be lost. So i have read that if i use EBS then chnages will be saved.
But Its not clear to me how to do that. I want that if i stop or restart the machine then my chnages are still there.
DO i need to chnage my hard drive to EBS. How can i do that
My Root Device is comming as EBS with 10GB EBS volume. Is that ok
Yes, the micro instances always use EBS root, so you don't have to do anything special.
If you 'stop' your instance, and later start, it's moving your hard drive to another computer and rebooting.
If you terminate your instance, your EBS drive will be fine as long as "delete EBS drive on termination" is not set on your drive.
When you use other instances, you'll have to verify the AMI type. Not all AMIs are available in all combinations:
EBS vs ephemeral
64 bit vs 32bit
PVM vs HVM (Everything is PVM except the really high-end Compute Cluster)
When you first get started in the cloud, EBS is a big deal. But as you get to be a cloud expert, you'll prefer non-EBS instances. EBS will only be used on a few servers, like your database or your syslog server. Most of your app should be stateless. Your app servers should only store their data in the database, and only write their logs to a central logging server, and only get their code from github or a package repository. So so there is no need to 'backup' your app server boxes, since they can be re-created at any time from external sources using something like Puppet or Chef.
Only your 'stateful' boxes like databases need backing up, and EBS helps there.