Moving old TYPO3 Appliance (TurnKey 12.0) a M1.small instance to a T2.medium on the hub

So the first thing to do is see what you have and where they are. Traditionally I have always used fdisk -l for that but I recently discovered lsblk which gives a nicer layout IMO.

I don't have access to a m1.medium ATM so I'm not sure what it'll be but my guess is that it'd be /dev/xvda2. If it's not mounted already (possibly already mounted to /mnt) you'll need to mount it somewhere. /mnt is as good a place as anywhere. So assuming that my guesses are right, do something like this (adjust as necessary if I am wrong).

mount /dev/xvda2 /mnt

Then create an empty file, make it secure and make it swap. Again adjust if need be (this will create 2GB swap file).

dd if=/dev/zero of=/mnt/swapfile bs=1M count=2048
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile

To ensure that it remounts after reboot, you'll also want to add an entry (or 2) to your /etc/fstab. Something like this (the first line might already exist as per comments above; adjust as need be).

/dev/xvda2    /mnt    auto    defaults,nobootwait 0   2
/mnt/swapfile swap    swap    defaults            0   0

swapon -a

FWIW if it didn't have instance store (as per the newer t2 instances) then you would have to decide if you really need swap, or whether you'd be better upgrading to an instance with more RAM. As you pay for excessive i/o operations on EBS volumes (i/o on instance storage isn't charged by AWS), a heavily used swap could turn out to be quite expensive...

Hi Jeremy and thanks for your replay.

Yes, I know: i should have upgraded at list to TurnKey 13 for security reasons... 

But I can't do it now because this requires upgrading of TYPO3 and other web apps.

I'll do it as soon as I can.

For now I decided to move the old m1.small to a new m1.medium instance.

I did it as follow:

1. createa a snapshot of old m1.small

2. created a new server on M1.medium instance with  "Clone a new server from latest snapshot" 

3. lauched the new server

The new server was running with seemingly non problem.

But today  noticed that the new server has not swap disk configured.

Here is what I see with a "top" command:

swap: 0k total  , 0k used, 0k free

I checked the old server: the swap disk was ok there.

Do you know how to fix this the problem?

To add weight to my suggestion of updating (at least to v13.0), keep in mind that Debian Squeeze (what v12.0 was based on) is about to reach EOL (less than a month). After that it will no longer get security updates. So having that live on the internet will be a bad idea; especially on Amazon (or any other large hosting firm) as their IPs are often targeted by attackers looking for vulnerabilities.

So I recommend that you try doing a TKLBAM migration to v13.0, that will give you about 2 more years of OS level security updates (old version of TYPO3 itself may have security issues).

Keep in mind that only the v14.0+ versions are available for the newer (relatively cheaper from what I've heard) AWS server sizes. The new sizes require a differently built AMI that we did not produce for v13.0 and won't be backporting.

If you anticipate wanting your server running beyond the next 2 years then I suggest that you look at doing the upgrade to v14.0 asap. It will possibly save you money and will give you OS security updates until early 2020. Actually you may even find that you can do the TYPO3 version upgrade on v13.0; then use TKLBAM to migrate that to v14.0?!

[update] Oops, I just realised that you specifically wanted a t2.medium. To make v12.0 run on t2.medium you would need to build your own AMI somehow. That would be much more work than updating TYPO3 IMO.

Adding it to fstab isn't enough... You'd actually have to recreate the swap file on every boot...

In that case it's probably better to remove the swap fstab entry and have a script that runs on boot to recreate the swap file and enables it.

You could either write a service to do that (i.e. the service checks for the swap file, if not there creates it, turns swap on and exits). Or a cron job...

I have found on AWS documentation that swap volumes are included by default only for instances with low RAM (m1.small, c1.medium). So, you are right about that, m1.small don't have a swap volume.

I created a swap file on the instance store as suggested by you.

It works fine but I have an other question:

as for AWS documentation, data on instance store volume is lost when the instances are stopped

(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#...)

So, in such a case, do I have re-create the swap file by hand?

Or may be is there a way to automatically create it at boot time of the instance.?

Thanks again for your help.

Unless it's only occasionally swapping you may actually be better off just going for a larger server (with more RAM) than using a swap on your EBS volume. It will certainly run much better.

Although FWIW while trying to find some info on what the I/O costs might be, it seems that there is no additional I/O costs on SSD drives. If you want higher IOPS then you payu extra for the high IOPS SSD. It seems that the I/O is only charged separately when using Magnetic EBS volumes. Have a look here and see if you agree with the way that I'm reading it...

Also AFAIK the Hub will provision SSD EBS volumes by default. Regardless it would pay to double check that in the AWS console IMO.

WRT TKLBAM, you are right, although adding an exclusion to the tklbam.conf is really easy. Have a loog at the TKLBAM docs.

An other solution could be to put  the swap file on the root partition ( / ).

I have enought disk space to do it.

In such a case  the problem will be backup:

every time tklbam does an incremental backup the full swap file (4GB) will be backed up becouse the file will result different from previous day.

Isn't it?

So I think I'll try using a script who runs at any boot to create and mount the swap file.