I'd think in terms of what would happen if you lost one or the other.
If you lost the QVW but not the QVD, you might have the data, but it isn't accessible until you rewrite a QVW to retrieve it and display it. The time to write all that code again is very expensive compared to the cost of disk space. So back up your QVWs.
If you lost the QVD but not the QVW, in trivial cases it would be easy to rebuild the QVD - binary load the QVW, and write out all the tables as QVDs. But for that to work, you must have at least one QVW that reads in the ENTIRE table and does NO manipulation of it. In almost all cases in our shop, we manipulate the data as we read it in, we skip fields we don't care about, date ranges we don't care about, and so on. There would be no way to recover the raw data from any of the QVWs. So back up your QVDs.
If you really, really can't afford the space, you could probably drop all the data from the QVW before backing it up so that you were only storing the important bits - the script, the objects, the macros, that sort of thing. I'm not sure exactly how you'd go about doing that cleanly and easily, but I'm sure it could be done. But even then, I'd think the extra trouble would cost you more than just buying more disk space.
I am not personally involved in our backup strategy, so I don't know what it actually is, and I may be missing a clever way to save storage space.
Thanks for your advice. I understood now that backing up QVW is a must. I believe we will be mostly scheduling jobs to incrementally load QVDs and then another job to refresh dashboards referring to those QVDs (I hope we will be creating dashboards simply referring to specific fields in QVDs instead of creating QVDs with limited fields from source tables). In that case, if a QVD gets corrupted, I can just create another one as we have backups of all data warehouse tables. And then just manually refreshing associated QVWs should do the trick.
In that case, backing up QVDs looks like overhead. We will surely have space to hold at least one backup of QVW.
Let me know if I'm thinking in right direction.
Ah, yes. As long as you can always rebuild the QVDs from the QVWs that create them and the underlying databases, then there's probably no strong reason to back up the QVDs. If you lose one, rebuild it.
On the other hand, one of our incremental QVDs takes us about four hours and a lot of database overhead to rebuild from scratch. In a case like that, you might still want to back up the QVD so that you aren't down for four hours and slamming the database if someone accidentally deletes it. On the other hand, a file like this is very large, so wastes the most space to back up . So for a case like that, I'm not sure there's a clear best answer.