So, basically, after doing something like the FULL-SIMPLE-Back-to-FULL manoeuvre you have to wait, potentially, as long as a week until the next NetBackup full backup runs.
Which IMNO neatly illustrates why this type of backup is rarely a good solution.
Every-other-day DIFF would worry me, as that's potentially 48 hours data loss, but it very much depends on how much data change you have going on, and how easily that could be repeated. If its all key-to-disk from paper forms then easy to repeat (albeit annoying ...) but if its real-time from phone calls etc. then its probably impossible to contemplate repeating the data entry and you need up-to-the-minute backup.
With where you are right now you need to take a Full Backup, so that your Log Backups start working. Yes, that will probably break the DIFF backups via NetBackup (well ... it might not, it might just mean that you would have to restore YOUR Full Backup and the next DIFF off NetBackup ... if you needed to). Definitely the Netbackup DIFF backups are going to be reliant on the NetBackup Full backups, so important that you only make COPY Full backups (I can't see that a Non-Copy DIFF backup would matter though), but in this case you have no choice - short of waiting up to a week for the next Full NetBackup.
So... if you did restore off NetBackup how would you, then, include a Log Restore? By the sound of it the Restore would come direct off NetBackup and not be able to incorporate a Log Restore as well ... in which case the Log backups are not much use, unless you also have a COPY Full and optional Differential backup.
I have a strongly held personal view here, so ignore it if you don't agree
We only make backups to disk, using SQL's own backup command. We then use "some other means" to safeguard those backup files (in our case: as soon as the backup is made it is immediately copied to another server, physically elsewhere in the building, and within a short period of time it is offsite to our Cloud Backup).
I am in total control of being able to easily restore, and any other changes that I want - such as taking additional Log Backups when rebuilding Indexes and so on. I have access to all the Backup Files that I make, without being reliant on some 3rd party solution.
I have 2 days worth of log backups locally on the server, a weeks worth of daily DIFF backups, and 4 weeks work of Sunday full backups. I can restore from any of those without needing to involve anyone else, or having to figure out how to get something back from the Cloud ... so we really only expect to have to restore from the off-site backups in a total disaster scenario.
The reason for using the MS SQL Backup command is that I don't have to worry that "some 3rd party driver" (in your case the version of NetBackup or a NetBackup "Agent") is no longer compatible with the version of SQL that I have patched / upgraded to. I can also take advantage of compressed backups which significantly reduces Backup Time, Disk Storage and also Restore Time.
I'm in total control of being able to do a Restore. Having to restore a production database is an almost-never situation here - probably for you too - but restoring an old backup to a New, Temporary database, having a look at some historical data, figuring out WHY something happened, or (on a couple of occasions) investigating a possible Fraud ... and then dropping the TEMP database ... is quite common - for me at least.
Personally I'd get rid of NetNackup and replace it with something that backs up the physical backup files. If you are not confident about setting up a robust backup system then have a look at Minion Backup - it reliable ""out of the box" with its default settings, and you can fiddle with it to suit you better only if you feel the need.