This object is in archive!
Extend existing email archival to allow storage on S3
Needs Feedback
Hi Folks,
Email archival is great. I've just been playing with this recently for a client that needs to be able to store all email for 7 years.
What would be cool (since web server disk is expensive but S3 disk is cheap) is to specify an alternative storage location for email archives. ie. S3 or other drive.
I checked in the forums but it was suggested I post a FR.
Eric.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
How do you propose that this be made available? There are many significant aspects of this feature request which are left open and undetermined.
Of course the feature request could be limited to only extending remote backups to Amazon S3. However, I would wager that there are individuals whom would prefer to send email archives to their own custom remote locations which may not be Amazon S3.
If custom backup destinations are permitted (similar to the fashion they are with the new backup system), how should they be deployed?
Are there concerns with letting the cPanel end-user supply their own custom transport logic? (For the new backup system, you must have root access to supply a custom transport)
Should the available custom transports be managed exclusively by root (the server owner) to ensure customers can't deploy custom transports themselves?
Are there concerns of bandwidth consumption? As it stands, the bandwidth usage through this mechanism, given its nature, would NOT be trackable and therefore potentially allow users to incur significant bandwidth/traffic costs to the server owner.
Allowing end-users to setup custom remote deployments like this is not something we've generally deployed in the past, otherwise limiting this to the server owner's resources (like the new backup system). Therefore, we need to see significant discussion and feedback here (please don't limit your input just to the questions I've posed above) so that we can find out exactly how server owners would plan to want to use and offer this feature.
How do you propose that this be made available? There are many significant aspects of this feature request which are left open and undetermined.
Of course the feature request could be limited to only extending remote backups to Amazon S3. However, I would wager that there are individuals whom would prefer to send email archives to their own custom remote locations which may not be Amazon S3.
If custom backup destinations are permitted (similar to the fashion they are with the new backup system), how should they be deployed?
Are there concerns with letting the cPanel end-user supply their own custom transport logic? (For the new backup system, you must have root access to supply a custom transport)
Should the available custom transports be managed exclusively by root (the server owner) to ensure customers can't deploy custom transports themselves?
Are there concerns of bandwidth consumption? As it stands, the bandwidth usage through this mechanism, given its nature, would NOT be trackable and therefore potentially allow users to incur significant bandwidth/traffic costs to the server owner.
Allowing end-users to setup custom remote deployments like this is not something we've generally deployed in the past, otherwise limiting this to the server owner's resources (like the new backup system). Therefore, we need to see significant discussion and feedback here (please don't limit your input just to the questions I've posed above) so that we can find out exactly how server owners would plan to want to use and offer this feature.
How do you propose that this be made available? There are many significant aspects of this feature request which are left open and undetermined.
Of course the feature request could be limited to only extending remote backups to Amazon S3. However, I would wager that there are individuals whom would prefer to send email archives to their own custom remote locations which may not be Amazon S3.
If custom backup destinations are permitted (similar to the fashion they are with the new backup system), how should they be deployed?
Are there concerns with letting the cPanel end-user supply their own custom transport logic? (For the new backup system, you must have root access to supply a custom transport)
Should the available custom transports be managed exclusively by root (the server owner) to ensure customers can't deploy custom transports themselves?
Are there concerns of bandwidth consumption? As it stands, the bandwidth usage through this mechanism, given its nature, would NOT be trackable and therefore potentially allow users to incur significant bandwidth/traffic costs to the server owner.
Allowing end-users to setup custom remote deployments like this is not something we've generally deployed in the past, otherwise limiting this to the server owner's resources (like the new backup system). Therefore, we need to see significant discussion and feedback here (please don't limit your input just to the questions I've posed above) so that we can find out exactly how server owners would plan to want to use and offer this feature.
How do you propose that this be made available? There are many significant aspects of this feature request which are left open and undetermined.
Of course the feature request could be limited to only extending remote backups to Amazon S3. However, I would wager that there are individuals whom would prefer to send email archives to their own custom remote locations which may not be Amazon S3.
If custom backup destinations are permitted (similar to the fashion they are with the new backup system), how should they be deployed?
Are there concerns with letting the cPanel end-user supply their own custom transport logic? (For the new backup system, you must have root access to supply a custom transport)
Should the available custom transports be managed exclusively by root (the server owner) to ensure customers can't deploy custom transports themselves?
Are there concerns of bandwidth consumption? As it stands, the bandwidth usage through this mechanism, given its nature, would NOT be trackable and therefore potentially allow users to incur significant bandwidth/traffic costs to the server owner.
Allowing end-users to setup custom remote deployments like this is not something we've generally deployed in the past, otherwise limiting this to the server owner's resources (like the new backup system). Therefore, we need to see significant discussion and feedback here (please don't limit your input just to the questions I've posed above) so that we can find out exactly how server owners would plan to want to use and offer this feature.
Replies have been locked on this page!