Big backup in S3 backed root

Conph1g's picture


The backup is made in the root not mnt drive and it only just fits

- How do I redirect backup away from the 9Gb root drive 

- If I use a symbolic link, does (ephemeral) /mnt survive a restart or reboot? or will I have to attach an EBS and fstab it? Would either of these restore?

- Will I need to reconfigure Duplicity /tmp as in Restoring from a large (7GB+) backup fails



Alon Swartz's picture

We deployed a tweak for this a while ago, which mount binds /tmp to /mnt/tmp so you can take advantage of the ephemeral storage.

The tweak is applied to all newly deployed servers, but if you need to apply it manually to a running server then it should be something like this:

mkdir -p /mnt/tmp
chmod 777 /mnt/tmp/
chmod o+t /mnt/tmp/
cp -ar /tmp/* /mnt/tmp/ >/dev/null 2>&1 || true
mount --bind /mnt/tmp /tmp

Ephemeral storage should survive a reboot, but not a start-stop (ebs backed).

If you would like the mount binding to happen automatically on reboot / start-stop, the following should help (note that you don't need to do this on newly launched instances:


#!/bin/bash -e
# mount bind /mnt/tmp (ephemeral storage) on /tmp

is_mounted() {
    mount | grep -q "^\$1 on \$2 "
    return \$?

# skip if already mounted
is_mounted /mnt/tmp /tmp && exit 0

mkdir -p /mnt/tmp
chmod 777 /mnt/tmp/
chmod o+t /mnt/tmp/
cp -ar /tmp/* /mnt/tmp/ >/dev/null 2>&1 || true
mount --bind /mnt/tmp /tmp


I hope the above helps...

Conph1g's picture

I think that covers it and goes the extra mile too.  I'll also add a couple of paranoia options for overbackup

-- thanks for being comprehensive, responsive and......



Eric Wheeler's picture

I was trying to figure out where /mnt/tmp was created at boot time and stubled across this article.

Binding /mnt/tmp on /tmp is great for a bit more performance on the ephemeral side, great idea! (I've always wondered about using flashcache or bcache to write-through-cache ephemeral->ebs, but thats off-topic).

You might consider mounting the ephemeral storage on /mnt as noexec,nosuid.

This is good practice for /tmp in general and it blocks certain attack vector classes and increases Linux server security.  I've seen many attacks get in with weak 1777 dirs, I can't wait to see distros noexec'ing their 1777's by default.  I've yet to see a case where this breaks a system. 

my $0.02 :)


Post new comment