Hello, If you don't make use of the BitFolk backup service then you might want to skip this. Those who have backups set up have dedicated some of their disk space to the backups. The stuff they asked to be backed up is backed up and multiple levels of snapshots are simulated using hardlinks. Access is via read-only NFSv3. I provide only read-only NFS access because: a) I don't want people to be able to corrupt their backups; and b) I don't want people using it for general purpose file storage Unfortunately people do from time to time end up having things backed up that they don't want backed up. Backing up a very large set of files that were only temporarily needed, for example. Once the content has been backed up once it can be difficult to get rid of because the entire point of having multiple levels of snapshots is that deleting the data won't delete it from all of the historical snapshots. In many cases we are talking 6 months of storage here. The problem comes when the amount of stuff backed up exceeds the amount of disk space set aside for backups, and the customer wants things removed from the backups in order to bring them back under quota. This is at direct odds with my desire for them not to have write access to their backups. I also have a stronger desire to not have to poke about in people's data, though. [1] Unless anyone can think of any clever compromises, how about this?: I'll delete entire snapshots for you on request. If you back up MASSIVE_FILE and then a day later delete it, its presence in snapshots might be like this: /hourly.0 not present /hourly.1 present /hourly.2 present . . /daily.0 present /daily.1 not present If I deleted every snapshot between hourly.1 and daily.0 inclusive then hourly.0 would become a delta to daily.1, neither of which would include MASSIVE_FILE, thus greatly reducing disk space usage. This has the advantages that it means I don't have to poke about in your files, since a whole snapshot can be treated as an opaque blob of data for my purposes. It also could be automated reasonably easily. The obvious downside is that it's a pretty blunt tool; if the customer leaves MASSIVE_FILE being backed up for a long time then potentially all their backups will need to be nuked. Thoughts? Cheers, Andy [1] "hi support, I have accidentally backed up 42GiB of extreme stoat porn onto your backup server, please can you go in and delete anything that looks like that so my backups can work again, thanks." -- http://bitfolk.com/ -- No-nonsense VPS hosting Q. How many mathematicians does it take to change a light bulb? A. Only one - who gives it to six Californians, thereby reducing the problem to an earlier joke.