The design shown in the OP has several problems. I know that you're still learning, so don't see the following as critique but as tips. I also don't know what language constructs are already in your toolbox, so feel free to skip the one or other tip until being prepared to consider it.
First of, class Item is a factory for items, a container for items, and an item itself. That is a bad idea because it burdens the class with 3 different responsibilities. A principle in OOP is the "one responsibility principle" which means that a class should be written so that it does one thing. This is not a hard requirement, but it is usually a good idea to follow it. So it would be a Good Thing (™) to have classes Item, ItemFactory, and ItemContainer. Notice please that Inventory is also a candidate to be an ItemContainer.
Looking at the factory first, it is notable that there is not exactly one factory as would be expected. Even if you had separated the factory functionality into an ItemFactory, you could still instantiate more than one. This is okay in principle, but you want the factory to create unique identifiers. This can be done only if either there is one and only one factory instance, or else all existing factories are synchronized when generating an item identifier. There is a so-called design pattern with the name "Singleton" (you may ask the Internet for it). Singletons are a bit controversial because of their global nature. Nevertheless, an application wide sole factory is IMHO a valid use case. It works so that you cannot instantiate the class ItemFactory directly, but invoke a static function that returns you ever the same object. This object is generated the very first time of invocation, stored internally, and returned as is for every sub-sequent invocation. This is in fact an OOP approach to a class with all static members, what itself is another possibility to make the factory unique.
The class Item itself should hold the attributes that are common to items. Your Item.itemDB array isn't such a thing. Why should, for example, a knife has contained items? The member itemDB and its companion routines are good for the ItemContainer class but not for the Item class. This doesn't mean that a concrete item is not able to hold other items. You can derive the class ItemContainer from the class Item, so it is itself an item and can contain other items. You can search the Internet for a design pattern named "Composite" if you are interested in the nitty-gritty details.
Your Inventory class suffers from some of the above issues as well. More to this later ...
… I cant seem to figure out how to insert items from "Item array" into "Backpack array" just by using reference ID which is also happens to be array index.
The problem with this kind of index addressing is that all containers (counting the array to it) need to have the same number of slots. I'm using this e.g. for resource handling where a resource (of a specific type) is referred to by the resource library as well as the concrete graphic rendering device. It works because on both sides the number of slots needed by the containers is the same. But in your case it isn't. An inventory is usually much smaller (or else you'll wasting memory) than your main table.
Now, in your current implementation the class Inventory has a member that can refer to a single Item instance, but it has an array for references to Inventory instances. This is spurious. I would expect it to have no reference to other inventories but a container (an array in your case) for items! This is because an inventory should be enabled to hold several items! If done so, and the array is chosen big enough to have a slot for each Item.id that can be occur, you can store items within the inventory using Item.id as index as well as done currently in the Item class.
It seems to be a project problem. An "Item" class should be used to implement a general item, not more than one. If you wanted a different class for swords, you could create another class called "Weapon", which inherits "Item", and another one called "Sword". Then, you could create a class to store ANY type of Item, no matter if they are a sword or a jewel or a coin. I'll give you a little example without being too complex about this.
Although this isn't wrong in principle and actually correct to a degree, it should be mentioned that OOP has a second mechanism besides inheritance, and that is composition. I urge the OP to notice this because inheritance, since being kind of innovation in OOP, is somewhat forced by textbooks and internet sources, so it seems to be the magic weapon. This is not true. Relying only on inheritance does not solve problems but leads to unmaintainable code. This becomes clear only after a while, namely if the codebase begins to grow noticeable. Either you end up in spaghetti inheritance or the so-called "God class".
To explain it a bit further, I exaggerate a bit:
Item <= RightHandUseable <= Weapon <= Cutter <= Sword <= MagicSword <= SwordOfKalmahar <= EnhancedSwordOfKalmahar
Or should it better be
Item <= Weapon <= Cutter <= RightHandUseable <= ...
This can be defused a bit when using mix-in inheritance, i.e. inheriting orthogonal functionality, but that is possible only by inheriting interfaces (in Java) so have to implement them each and every time. Now, what is with a Stick? It is inherited from Tool or, specialized, Lever because it is a tool to activate a mechanism when inserted into a slot, or is it a Weapon because it can be used as a Cudgel?
Doing all this is right is probably too much when still learning the language; but don't get trapped by the ideas coming from a single source. Be open.