Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi All,
the backup and restore procedure for QNP includes stopping the Web Server, Engine and Scheduler services.
https://help.qlik.com/en-US/nprinting/February2020/Content/NPrinting/DeployingQVNprinting/Backing-up...
This creates downtime.
We are running in a 24/7 global environment, there is no 'night'.
Are there other ways than the procedure using Qlik.Nprinting.Manager.exe to reliably backup and restore QNP repository, without downtime for the backup?
The automation script by @Daniel_Jenkins is of course a great help, but it also stops services.
https://community.qlik.com/t5/Qlik-NPrinting-Documents/Qlik-NPrinting-17-x-Repository-Backup-Batch-F...
Hi,
At the moment the official procedure requires you stop the services. This is the only supported way until the development team will change it and test the new version. I already asked to check this but it is not a task that can be done in few minutes, it will must be scheduled and managed and I don't know if, at the end, a procedure with all services running is feasible on all Qlik NPrinting installations.
Then if you want, at your risk, you can run a backup without stopping the services. The backup file will be generated and maybe in your scenario this will work but we cannot warranty it will with a non standard procedure. If you decide to do this I strongly suggest you to periodically test the generated backups by doing a restore on a sand box installation and testing it. Or you could run a daily backup without stopping the services and a weekly by stopping the services in a moment where you plan to have low traffic.
If you open the generated zip you will see that there is the repository dump but there are also many other files. So also those files must be backuped correctly.
I hope this helps,
Ruggero
As far as I know backup requires services to be stopped as the repository must be in stable/not used state to create snapshot.
@Ruggero_Piccoli - am I right?
thanks
Lech
Hi,
The documented procedure is the only one officially supported at the moment. I strongly suggest to follow this procedure.. Stopping other services warranties you that no new information are written during the backup/restore process and that files are not allocated.
Than, if you want, you can run the backup with all services running. The backup file will be created without service stop. You are doing something not supported so you should test a restore every fixed time period on a Qlik NPrinting test installation with at the same version of the production one.
Best Regards,
Ruggero
I understand why the services must be stopped.
I just don't understand that it is necessary.
I have worked with many different applications and databases over the past 30 years, and never have I had to stop db usage to make a backup.
It's hard to imagine that a product like PostGre would not be able to provide such basic functionality.
Transactions assure consistency.
If a transaction is uncommitted at the time the backup starts, then it isn't in the restore point. But that's perfectly fine. At least you have a working consistent database after restore. Other databases I've worked with then have other means of restoring up to the last transaction after a backup. I'm just really surprised PostGre does not.
I suppose we will have to live with it then.
Using a more advanced database system for the repository is not an option at this point in time.
Hi,
Maybe PostgreSQL has that kind of feature, but, at the moment, the Qlik NPrinting developers suggested to stop all other services a part the PostgreSQL one to do the backup. As I told you can run a backup with all services running also if it is not the official procedure.
Thanks for your suggestions, I will open an internal conversation to understand if it is possible to update the backup procedure in order to avoid stopping other services.
Best Regards,
Ruggero
Ah, OK. I see your point.
I would be very interested in hearing what exactly is the risk with not stopping them.
What could potentially be lost and under what circumstances?
In our case, the system under backup is a production system. There is no development of reports, only end-users collecting their report output and maybe making the odd subscription (if authorized) or doing an On-Demand (if authorized).
We can organise our daily report generation sequences in such a way that they do not interfere with the backups.
We would have multiple generation sequences and multiple backups (one after each sequence). As it is 24/7 worldwide it is never night, but at the same time it is always night somewhere. So we will be generating per region throughout the day on various schedules.
The report development is in Dev/QA system, and finished/accepted reports are then promoted to production. This is not something to occur regularly.
Hi,
At the moment the official procedure requires you stop the services. This is the only supported way until the development team will change it and test the new version. I already asked to check this but it is not a task that can be done in few minutes, it will must be scheduled and managed and I don't know if, at the end, a procedure with all services running is feasible on all Qlik NPrinting installations.
Then if you want, at your risk, you can run a backup without stopping the services. The backup file will be generated and maybe in your scenario this will work but we cannot warranty it will with a non standard procedure. If you decide to do this I strongly suggest you to periodically test the generated backups by doing a restore on a sand box installation and testing it. Or you could run a daily backup without stopping the services and a weekly by stopping the services in a moment where you plan to have low traffic.
If you open the generated zip you will see that there is the repository dump but there are also many other files. So also those files must be backuped correctly.
I hope this helps,
Ruggero