On 12/17/2010 09:46 AM, Edward Ned Harvey wrote: >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Mark Woodward >> >> My question for you guys is what do you *want* in a backup. We've all >> used these feature laden things that are out there, 99% of which is >> pointless. What are "must haves?" What is something you've wanted but >> can't find? What are features that are most pointless and why? >> > There are different requirements for laptops and servers. > > Laptops: > Run frequently (minimum once daily), silently, in the background, low enough > priority that users don't generally notice or care. Does not need to scan > the entire filesystem to see which files have changed. It may seem obvious > now, but must run while the OS is running. Must be able to exclude files > and directories (even filetypes, etc)... Backup to remote server. The > remote server must have sufficient security as to prevent Jane from reading > Tarzan's backups. And ability to do baremetal restore. Ability to browse > the backup to retrieve a specific file or subset of files. Compression goes > without saying. Simple for users to restore their own stuff without IT > help. > The permissions to keep Jane from reading tarzan's files is an interesting one. Its obvious when said, but didn't occur to me. It's a potentially difficult problem. Would merely matching the user name to the owner of the files be enough or would you also require full group access?
So, to get access to a backup set, you would need a user to be created for you by an admin (or some audomated tool, I'm not sure) and then you would only be able to see the files which you own. Would that be OK? For compression, a user can specify a level 1-10, 1 is no compression, and 10 is full. I also support encryption, although one has to compress before encrypt or compress doesn't work. > Bonus features, not requirements: Able to run over WAN. Able to > efficiently handle sparse files, such as guest VM's efficiently. > Centralized management, so administrators can quickly see how recently > somebody's backup was successful... And even threshold alerts if somebody's > backup hasn't run in a week or something like that... > Sparse files are interesting. I hadn't thought of those. Not sure how to handle them. Got a suggestion? > Servers: > Actually, most of the above applies for servers too. The main difference is > assigning priorities to the various aspects listed above. Like, for > example, I consider it an absolute requirement that servers are able to > backup the whole filesystem without scanning the whole filesystem for > changes, but on a laptop, that might be acceptable if only it's able to > complete fast enough. But on a server, if you don't have instant snapshots > etc, there is just absolutely no way possible to finish any significantly > sized backups in a reasonable amount of time. > In version 1.0 I'm stuck, its a fail walker. Next version I'm thinking of using OS specific file access monitoring for incremental backup and access logging. > Beyond this, I think I'm rambling. > _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
