It's been a while since I've used NetApp, and so I can't answer with absolute authority, but I can provide an explanation for this type of behavior.
This sounds like it's operating very similar to how Linux's LVM operates. Lets say you have a 1TB physical disk with 100% of it mapped to an LVM volume group. Now you create a 100GB logical volume on that volume group. You do some stuff, put some files on it, etc. Then you create a snapshot of that logical volume. Now any files (blocks really) that are modified on the logical volume are copied so that the snapshot will have access to the original data. But you can also take this snapshot and mount it up like a normal volume. If you mount it, you've now got 2 100GB filesystems mounted. But the 2 filesystems share the same data (physical volume blocks) until that data is changed on one of them.
So what the NetApp is likely doing is letting you access those snapshots through its /backup/.snapshot
directory. When analyzed, each snapshot looks like the same size as the original volume.
This may seem like an oddity, but it's perfectly legal (in terms of NFS, kernel, etc). When you run df
, your system makes an NFS call to say "how big is this filesystem", in which the remote system can respond however it wants. Then when you do a du
, your system makes an NFS call to say "how big is this file", upon which the remote system can respond however it wants.
You can also do similar (but not the same) things with sparse files. The file is said to be taking up more space than it really is.
These days, there are lots of advanced ways of saving space on filesystems. The questions of "how much space do I have" or "how much space does this file take up" don't always have simple answers. You can have things like snapshoting, de-duplication, transparent compression, etc.