application-aware backup for 3.70 native db?

NazzyNazzy Member Posts: 6
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.

Best Answer

Answers

  • mucamuca Member Posts: 42
    edited 2020-02-26
    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
  • NazzyNazzy Member Posts: 6
    edited 2020-02-27
    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.
  • kylehardinkylehardin Member Posts: 257
    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.
    Kyle Hardin - ArcherPoint
  • NazzyNazzy Member Posts: 6
    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.

  • kylehardinkylehardin Member Posts: 257
    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.
    Kyle Hardin - ArcherPoint
  • NazzyNazzy Member Posts: 6
    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?


  • NazzyNazzy Member Posts: 6
    edited 2020-02-28
    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.
  • vaprogvaprog Member Posts: 1,116
    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.


  • NazzyNazzy Member Posts: 6
    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?
Sign In or Register to comment.