application-aware backup for 3.70 native db?

Nazzy

We have Navision 3.70 with native database on 2003 R2 server (virtual machine). I am wondering if native db takes advantage of "application-aware" backup technology in today's backup solutions such as "Veeam Backup & Replication" or "Shadowprotect SPX". I ask because we are using Shadowprotect SPX which has application-aware backup for 2003 server, but Veeam does not (they dropped "app-aware backup" support for 2003 server in v10, latest version). We are considering moving to Veeam backup solution due to the many additional features it provides, but the question about app-aware backups for 2003 server may be a hard-stop if Navision 3.70 native database uses it. Note: Veeam can backup 2003 VM image no problem, just not app-aware.

I had previously assumed "application aware" backups applied to 3.70 native db (to quiesce the database and commit cache before the backup such as with Exchange Server and SQL server) but now I'm not sure. If app-aware backup does not apply to 3.70 native db, then it's a non-issue and we can move over to the Veeam product.

Any insight on the question "Does 3.70 native db use application-aware backup technology?" is appreciated. Thank you.

vaprog

Nazzy wrote: »

You said anything other than hotcopy is not guaranteed that a restore of FDB would work. I wonder why do you believe that?

That is how this database is designed.
There's one other way to get a guaranteed consistent backup: All connections to the database closed and the server service stopped. This makes sure data on disk is consistent.

A backup takes time to read all the files belonging to a database. If the database management system writes to the database (pseudo-)concurrently, the image is not an snapshot at one moment. Therefore one part of the file might be inconsistent with another part, which has been backed up at a slightly different moment. You need to freeze the image on disk at one moment in tome during the entire backup of all the files belonging to the database.

Hotcopy works similarly to what the volume shadow copy service would do, but internally in the database.
Newer databases usually support VSS in a way that they get a chance to make the image on disk consistent, then tell VSS to carry on, and then they can carry on themselves. The VSS service then redirects all write operations to the shadow copy. After the backup has finished, the changed data from the shadow copy is stored to it's original destination.
The native database is much older than VSS and does not support it.

Veeam's Application-Aware backup relies on VSS. See Application-Aware Processing

muca

today's backup solutions such as ...
>>>>>>>>>>>>>>>>>
Why You want not use hotcopy.exe ?
You can find it in directory where Your native server is installed

Nazzy

muca wrote: »

today's backup solutions such as ...
>>>>>>>>>>>>>>>>>
Why You want not use hotcopy.exe ?
You can find it in directory where Your native server is installed

We already use hotcopy to backup database file, but that's not the point of this topic. I want to know if 3.70 native db can make use of application-aware backup technology during FULL system backup, not just database file via hotcopy.

If not, then we can switch to Veeam without issue.

kylehardin

Hotcopy is the only way to make sure you have a consistent (meaning all transactions committed) backup. If you use any external backup tool other than hotcopy, you are not guaranteed that a restore if the FDB will work.

Hotcopy to some networked backup directory Or another directory on the same server, doesn't matter. Then 10 minutes later, use Veeam or whatever you want to do your "real" scheduled backup of the whole VM / server/ whatever. But you must have that hotcopy step to make sure that a full disaster recovery restore will actually result in a working NAV FDB.

Nazzy

kylehardin wrote: »

Hotcopy is the only way to make sure you have a consistent (meaning all transactions committed) backup. If you use any external backup tool other than hotcopy, you are not guaranteed that a restore if the FDB will work.

Thanks for the insight. You said anything other than hotcopy is not guaranteed that a restore of FDB would work. I wonder why do you believe that?

From a technical standpoint, can you clarify why Veeam or Shadowprotect, two very-well known and usable backup solutions, may not guarantee a good backup/restore of the .FDB file? The technical reasons are what I'm looking for.

kylehardin

Let's say you were using SQL as your NAV database storage, and that is running in a VM. And in this example you are using Veeam. Part of your automated Veeam backup is the SQL backup, because Veeam knows about SQL. It knows how to backup the transaction logs, and the databases themselves in such a way that they can be restored to a consistent state.

Navision FDB has no such facilities. I'm sure it has some sort of internal transaction log, but there is no exposed interface for making sure the backup you take of that FDB is consistent - meaning you didn't grab a copy during the middle of a write transaction. To Veeam, the FDB database is nothing but a file, so it just copies it the best it can, same was it would grab a Microsoft Word file.

Hotcopy is the only tool that can "quiet" the FDB database, so that the resulting FBK is consistent. It can guarantee that you did not copy the file in the middle of writing data.

Nazzy

So basically you are saying "application-aware" backups do not apply to Navision FDB (native db) because there is no ability to quiet the database (e.g. flush I/O data in memory to disk).

Now that we've established that, my next question... suppose we did not use hotcopy, and only used Veeam to backup the FDB file. Let's also suppose the backup was "inconsistent" because Veeam copied the file in the middle of writing data.

Now suppose we restore that inconsistent database. What would we find wrong with the database? I assume we'd only be missing the IO data that was in memory? And other than that, the database would be ok? Or not?

Nazzy

EDIT: I would think Veeam uses VSS (e.g. in 2003 R2 server) to ensure a consistent database during/after backup, even if it was copied in middle of writing data. VSS would write back all the data that was in memory at time of backup.

vaprog

Nazzy wrote: »

You said anything other than hotcopy is not guaranteed that a restore of FDB would work. I wonder why do you believe that?

That is how this database is designed.
There's one other way to get a guaranteed consistent backup: All connections to the database closed and the server service stopped. This makes sure data on disk is consistent.

A backup takes time to read all the files belonging to a database. If the database management system writes to the database (pseudo-)concurrently, the image is not an snapshot at one moment. Therefore one part of the file might be inconsistent with another part, which has been backed up at a slightly different moment. You need to freeze the image on disk at one moment in tome during the entire backup of all the files belonging to the database.

Hotcopy works similarly to what the volume shadow copy service would do, but internally in the database.
Newer databases usually support VSS in a way that they get a chance to make the image on disk consistent, then tell VSS to carry on, and then they can carry on themselves. The VSS service then redirects all write operations to the shadow copy. After the backup has finished, the changed data from the shadow copy is stored to it's original destination.
The native database is much older than VSS and does not support it.

Veeam's Application-Aware backup relies on VSS. See Application-Aware Processing

vaprog

Nazzy wrote: »

Now suppose we restore that inconsistent database. What would we find wrong with the database? I assume we'd only be missing the IO data that was in memory?

Well, maybe, maybe not. When you connect to such a database, a lengthy procedure of checking the data and making sure everything is consistent would start. During that process you might loose transactions, maybe net even necessarily in backward chronological order. But it even might be, that the database could not be mounted again. Anyway, You will not want to take chances with this.

Nazzy

Vaprog, thank you for your very helpful comments. I now have a better understanding of it. So hotcopy really is the key to a successful backup/restore of native db, regardless what other backup solution is used to backup the server. Seems best practice would be to backup entire server with backup solution of our choice (e.g. Veeam, Shadowprotect etc), and then also hotcopy the database file to a separate location. If need to restore the entire server, do that first, then restore the database file that was previously hotcopy'd. Would you agree?