> all efforts other than solving the 30 day file retention limit
Trust me, that message has come through loud and clear! :-) We are going to do some analysis to see if we can afford it, but we'll need at least a week or two to figure that out.
Trust me, that message has come through loud and clear! :-) We are going to do some analysis to see if we can afford it, but we'll need at least a week or two to figure that out.
It should be a /more privileged/ instruction to delete / replace / modify already stored files. This could prevent a backup service on a compromised system from removing remote backups. (Assuming the administrative information was kept secure using other means.)
Ideally I'd like to be able to manually assign privileges to sub-accounts.
* Modify: resume uploads older than 24 hours
* Modify: remove/delete
* Modify: change storage (filestream/parameters/metadata etc).
* Append: create new buckets
* Append: add a new file to a bucket
* Append: add a new /version/ of a file in a bucket.
* Append: add metadata
* Read: all list operations
* Read: all download operations
A simplified customer UI might bundle those operations together, but some advanced way of providing finely grained privileges should be created.
Edit: Fixing formatting.
A way of improving the storage size might be to allow the user to white-list (with some defaults) folders more likely to have 'third party' files (E.G. C:\\Windows, C:\\Program*, /usr/) either excluded if they're on a list of common files or de-duplicated with a public list of common files (and check-sums). It would be useful to add-on programs and scripts if that list were public, and if a way of cloning those files in to a discounted pool were possible by 'uploading' them again (to ensure the customer actually /has/ that file and thus presumably the right to restore it).
Speaking of which -- possibly simple feature request -- when a files' entropy suddenly goes high from low, alert the user and keep the files longer.