> From: Mark Woodward [mailto:[email protected]] > > 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?
Well, I have no idea what you have in mind, but ... I usually solve this problem by backing up onto standard file shares of some kind. If it's a cifs share on a windows server, I simply set the ACL's to allow only Jane to access Jane's backup directory. If it's Apple, I create separate shares which are only accessible by their owner. And so on. > 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? Well, yes. But of course, it's desirable if it's based on a pre-existing credentials system such as AD. > For compression, a user can specify a level 1-10, 1 is no compression, > and 10 is full. This is a low-priority request, basically irrelevant to anything, but I'm an idealist so I like to promote. I think it's desirable to allow a choice of compression algorithm. LZO is always so fast that it effectively removes large sequential repeated patterns (such as zero-filled files) but LZO will never become processor bound, because it's just so darn fast, and generally pretty wimpy compression. But good whenever you have really fast IO channels, because it'll never slow you down and sometimes speed you up. Gzip/Zip seem to be industry standard, and as far as I can tell, they have no discernable advantage and should be antiquated. Bzip2 is also often used, and it always loses to LZMA, so I think bzip2 should be retired. LZMA (7-zip, XZ) if you set level-1 compression, is both faster and stronger compression than any level of gzip or bzip2. End result is: The only compressions I ever use are lzop and xz -1 (and 7-zip) > Sparse files are interesting. I hadn't thought of those. Not sure how to > handle them. Got a suggestion? Not really. It's something a filesystem either supports, or doesn't. For example, if you have a sparse file inside a ZFS filesystem, and you do an incremental ZFS send... Then ZFS is intelligent enough to instantly identify and send only the changed blocks. No scanning or anything. However, there is no such functionality in NTFS, EXT3/4, HFS+, or most filesystems... In most filesystems... Let's suppose you have a disk which will read 500Mbit/s (which is a typical 7200rpm sata drive.) If you simply read a non-sparse file from start to end, then of course it will take some amount of time, based on the speed of the disk. But if you read a sparse file from start to end, then the filesystem will generate zero-fill for all the sparse sections, and it does this faster than the disk could have read real data. I'd estimate about 10x faster. So unless your filesystem has a way of providing an index of the sparse sections of a file (which no filesystem does, AFAIK)... And unless you're using ZFS Send... The best alternative is to simply read the whole sparse file from start to end, as fast as possible. And this is NOT fast, even in a sparse file. Oh well. The world stinks!!! > 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. FYI, easier said than done. Just so you know. Yes, it's possible (just look at dropbox, and ifolder, and sugarsync...) but I have to assume there are tricks and unreliability issues and booby traps, or else there would be more products out there capable of doing that. _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
