[GRLUG] VPS, multiple partitions?

[Dave Chiodo]

Ok, I have a VPS server, and it was installed with an "all on one
filesystem" partition scheme. I recently decided to pursue changing this,
and had the below exchange with the support department at the company that
provides my VPS. I beleive they use "Xen" as their VPS service.

Is what they are telling me legit? It sounds like BS to me. Why should I
not be able to partition the virtual HD any way I want, and if they are
baking up an image of the entire virtual HD, why should any changes I make
to it prevent their backup from being able to put it back the way it was?

Anyway, here's the gist of the exchange, any tips, advice, correction, or
support appreciated.


*--------------------------------*
*M**e:*
*Do you keep automatic full system backups of all VPS?*
*
*
*If so, I'd like to confirm when the most recent backup was taken of mine. *
*
*
*I am planning on shrinking the root partition in the next few days to
allow multiple separate partitions and would like to make sure I have a
fallback in case of some catastrophic failure.*
*
*
*If not, would it be possible to request a system image backup be taken
before I proceed with this?*
*---*
*Support:*
*Hi, I can look up the backup dates for you but I should mention first that
alternate partition layouts on the VPS are not supported by the system.
Altering the partition table will result in data loss if you attempt to
resize the server later to a different package or if you do an OS reload /w
backup option.*
*---*
*Me:*
*
Are the backups you take partition based? or whole-disk based?

Is it possible to do a user level data and configuration backup, and then
do a system reinstall with different sizes?

Could I have the storage space that is allocated to me split into two
virtual drives, rather than one?

I am seeking to make the system less vulnerable to an errant process
filling up the drive and preventing normal operation.

I find it hard to believe that a commercial VPS would not allow/support
proper *nix partitioning.
---
support:
Sorry I have to answer no to all of your questions. The VPS system does not
support partitioning, multiple disks, or different sized backups. Our
dedicated servers do support fully configurable disk subsystems as there is
no virtualization there and you have "bare metal" access.
---
me:
I'm unsure how to interpret the answer "No" to this question:

Are the backups you take partition based or are they whole-disk based?

In other words, does it take an image of the virtual /dev/xvda which is
presented to my system? Or does it do something else?

Are the backups taken sufficient to completely recreate the VPS from
scratch, even if I completely erased it (accidentally or otherwise)?
---
support:
I believe the backups use snapshots of the disk's partition. I'm unsure
what will happen if the default partition layout is changed, it may screw
up the backups as well. I would need to ask engineering in the morning to
find out for sure. It's less elegant but instead of partitioning the disk
you could use loop devices to create separate mount points. If you are just
concerned with an app filling up the disk another solution is to enable
disk quotas and set a hard quota for the user your app runs under so it
cannot fill the disk.
---
me:
loop mounts would not be useful, nor would quotas, as I wish to protect
against even *system* apps filling the disk up.

In fact, I'd like to be able to consider mounting the root fs read-only.

Please forward this ticket to engineering/sysadmins for detailed
information on how backups work, as well as clarification regarding
partitioning.

I still find it VERY difficult to believe that any professional VPS
software would not allow for proper unix filesystem partitioning.

"everything on one filesystem" is something one expects on a noob
installation on their dual-boot home PC, NOT on a server.
---
support:
Sorry we're unable to support this type of configuration. Most VPS do not
support this unless they are running under full hardware virtualization
which is slow performance.
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20130313/360f4346/attachment.html>