Backup space for your VPS clients?
With the new central backup pending release for next week a few ideas have been flying around the office. Someone suggested a backup space feature.
The general idea would be FTP (plain/TLS) on a per client basis. You can define the amount of space, transfer speeds and IP's allowed to connect to the space (default to VPS ips) from within SolusVM. This would then allow you to supply the space as a complimentary service with vps or even charge for it as an extra.
Other options could be explored like SFTP and rsync but security would need to be looked into first.
We know some data centers already offer these sort of services to dedicated server customers (OVH etc..) but thought it might be a good idea for the lowend VPS providers who don't want to backup there own customers VPS.
Would you use it?
Comments
This sounds like a good idea. I assume this will be in addition to the 'central backup' as we know it now where the whole VM is backed up? Would be useful for things like database backups etc
Once the original solus backup system brought down a few nodes due to it looping I put my own rsync + ftp servers in place and offered all customers backup space on them, so this sounds like a nice way to automate it all.
Happy to offer any input you might want based on 2 years of running ftp+rsync for VPS customers.
@soluslabs - Absolutely! We would definitively use this feature! Also, I like SolusVM 1.14 allot and the Bootstrap client area template is a God sent feature. Keep up the good work guys!
It's a great idea.
This is something we offer with our plans for free, with 3rd party panel, additional costs of running and etc. Having it integrated in the svm panel would be great.
What do you use at the moment if I may ask?
I will add in my usual gripe, do not add support load to me, whatever solution you decide, make sure I can give the end user access so they can create backups on their own.
I know many won't or fail to grasp the concept, but as long as I can have them able to do it on their own, getting them to drink the water is not my problem as long as there a path to show them the water.
And for the love of Brian... test it, test it then test it again on an environment that even comes close to simulating a live node under heavy use.
Why
Forgive my poking, but I think these statements should be swapped. It's not even like FTP is the more convenient or reliable option. Certainly not the most secure.
For once I agree with @jarland
An API would be nice so we can bill for such space
Yes thats correct.
Great. Drop a ticket in next week if you don't mind.
Maybe you misunderstand this feature. The client would have access to there space. They would need to use it how they wish.
So it's easier to secure a host offering sftp and rsync than ftp?
Looks promising.Waiting to test ...
FYI this was only an idea. It not even coded yet. Although it's not a massive task!
In few cases do I find the words spelled out to accurately display the difference, but here I find it absolutely relevant:
FTP = File Transfer Protocol
SFTP = Secure File Transfer Protocol
There are many ways that you could go about it, but FTP is both the least secure transfer method mentioned and the most unreliable as well. Sure FTP is mostly fine but the others are significantly better. The setup process on your end should be different, but not so much as to justify spending the time configuring FTP over SFTP.
SFTP vs FTP: https://www.ccs.uky.edu/machines/sftp.html
SFTP is the secure version of FTP. To my knowledge, FTP (plain) sends the username and password in clear-text. There are obviously ways to encrypt this (FTPS) but basically the easiest way is probably just to have SFTP (most of the time works with just the SSH Daemon).
Applying limits to functionality of SFTP is also not difficult. With our April fools promotion I did just that, and I didn't even know how to do it 15 minutes before.
You have the wrong end of the stick. I am talking about host security not the data transfer security.
Slower File Transfer Protocol
Also, if the node/master only needs to talk to your storage host, /etc/hosts.allow comes to mind to make ftpd just as secure
You're already creating shell accounts on the host nodes to use a java console, I wouldn't think this would be terribly difficult for you to narrow in functionality.
Preferably don't use FTP, but use SFTP or similar (as said before). If you are going to use FTP, then at the very least only allow TLS, and not unencrypted.
But would require a vast amount of testing. We would most likely use the Match functions in OpenSSH 5
Just a thought, in the end the idea is a good one I think.
We would do the ftp configuration on the backup servers and enable TLS as default with a self signed certificate out of the box.
Good idea. This option is available with XenVZ/OpenITC control panel almost half decade and it works exactly the way Timmy would want it - everything is done with control panel without need to open support ticket.
Monthly data transfer quota: 93.75GB
FTP server(s) available:
XXX.datacentre.newcastle.XXXXXXXXXXXXXX.co.uk
FTP password:
(optional setting): FTP over Explicit TLS/SSL - available last time when I checked it.
Use rsync...
10/10 would use.
eh? I thought the S stand for SSH not Secure.
SSH FTP results in secured file transfer - http://en.wikipedia.org/wiki/SFTP