Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Qlikview Files Backup Strategy

Hello All,

We are trying to implement Qlikview solution for our reporting needs. We will be having incremental loads using QVD files. So we will be having both QVW and QVD files holding current data. In such cases, is it required to take back ups of both files? Can anyone who has experience with similar case can share or suggest backup strategy?

These QVD files may reach to 2-3 GB.

Any reply is appreciated.

Thanks,

Amey

1 Solution

Accepted Solutions
johnw
Champion III
Champion III

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.

View solution in original post

5 Replies
johnw
Champion III
Champion III

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.

Not applicable
Author

Hi John,

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.

Thanks,

Amey

johnw
Champion III
Champion III

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.

Bill_Britt
Former Employee
Former Employee

You could also save the QVW without data to reduce space.

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
Not applicable
Author

Thanks bbt and John for your replies. Those are really useful !