Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to work on a standard configuration for a set of EC2 instances running ubuntu 12.04. These servers are going to be primarily web servers for a Ruby on Rails application. When you configure a new large instance, you are given a primary of 8GB and then ephemeral storage of 400 GB that is mounted to /mnt.

It seems logical to me to move some directories that have a potential for growth off to the /mnt directory, I was specifically thinking of /var/www and /var/log.

My question is two-fold:

  1. Is this a good idea or are there pitfalls that I cannot see?

  2. If this is a good idea, how should I go about configuring this. I do have the ability to configure new instances and down our old instances. My concern is over long term configuration, I am not necessarily concerned about downtime.

I am a developer with some experience in devops, but mounting drives is something I have not faced before, so explicit directions would be greatly appreciated.

share|improve this question
up vote 1 down vote accepted

I don't know what you keep in /var/www, but the contents on my servers definitely can't be described as "ephemeral", which I understand to mean "could go away any time, and I don't much mind". If that's not what amazon means by "ephemeral", I apologise.

As for /var/log, if you don't care about the log data at all, don't collect it in the first place.

If you do care about it, but can't afford to hold it in primary storage very long, then this isn't a mounting issue so much as a log management problem. I'd be inclined to use logrotate, if it's available to you, and configure it to move old logs out to /mnt every week or so. That way, the old logs are there (until the ephemeral storage goes away), but the current log is safe on primary storage.

A logrotate recipe like

/var/log/foo {
    olddir /mnt
    rotate 1000
    /etc/rc.d/init.d/fooservice restart

might be of use, at least as a template.

share|improve this answer
Thanks, the term "ephemeral" seems to be what people call the extra drive on a ec2 instance, it was not a reference to the data. The data in /var/www can be pulled at any time. I don't care about the logs after a certain amount of time, but I do care about them initially. I already have log rotation configured. Thanks I had not considered moving the rotated logs on a cron... that hold promise and reduces complexity, which I like. – Geoff Lanotte Dec 13 '12 at 14:46

What you are planning is similar to what I do for all of my instances but I also include /var/lib/mysql and most of the /etc/{apache2,mysql,php} directories as well. I do that so I never lose my configurations when an instance terminates for whatever reason.

  1. It is an excellent idea in that you will never lose your data. As I mentioned, if the instance goes down you will retain that information and simply need to mount it to a new instance.

  2. The easiest way to do it is to simply move those directories to the EBS volume and then create symlinks to them at their original location.

share|improve this answer
Thanks, but can you just move the files if there are open connections to them? – Geoff Lanotte Dec 13 '12 at 14:54
No. You will need to stop the service(s) (apache for the locations you mentioned), move the files, create the symlinks, and then restart the service(s). – Daemon of Chaos Dec 13 '12 at 15:21

If the data (on the filesystem) that the application accumulates is valuable then ignore the 400GB complimentary storage and mount an EBS volume. Otherwise...

The answers depend (a) on your application, and (b) "spot", or "reserved" instance, but

1) Yes it's a good idea because, obviously, you're less likely to run out of disc space. Whether that is likely depends what your rails app does, but just for separation and clearly defining what's "yours" and "mine" I tend to put all "my" stuff on /mnt. There is no need to mount it manually. That's done just cd mnt and off you go. There's a little fiddling with permissions which you won't have any problem overcoming.

But of course this space is "ephemeral" so it dies when the server does, which leads us to my second qualification...

2) "spot" or "reserved" instance?

If you have a spot instance, then you have to accept that there is a chance, remote as that might be, your maximum price will be outbid and the server will be unexpectedly terminated. That will pose a problem if the data on the server has value.

But! if you're paying the premium for a "reserved" instance, which (I've not read all the fine print disclaimer ;-/) means the threat of your server being unexpectedly terminated, and the application's accumulation of data, is very substantially reduced. You might be able to schedule a periodic backup (to S3?) and sleep very easy without the added expense of an EBS.

If long term, as stated, minimal downtime (and risk) is the goal. So you'd rather pay a little bit more than muck around saving pennies, then ignore /mnt and get very familiar with how to create and mount an EBS volume. Put all your stuff there. That way you can reboot the server without loosing sleep. That stuff will not disappear and it will not "take a while" to get things back to where they were before whatever disaster occurred to require cycling server instances.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.