Is the backup of collections in the database properly organized?

Question

Database

There is a desktop application. Simplified, it has several collections ( ProductList ) where the user can scan products ( ProductRecord ) or add manually, then send to the server.
There is a requirement to save all collections to disk after each change to them and their elements in order to avoid loss of information in case of external failures.
For UI binding, ProductList implements INotifyCollectionChanged and ProductRecord implements INotifyPropertyChanged .
Now a permanent backup of changes is implemented through the Backuper class, which is subscribed to the ProductList.CollectionChanged event and to the PropertyChanged of eachProductRecord . Next, when one of the two events occurs, the entire ProductList with all of its ProductRecords is serialized into a file.
On small collections, this algorithm works fine, but in the future I would like to switch to the database and update only the changed elements, and not the entire collection.
Decided to try SQLite + Entity Framework 6.2 and had questions:
1. Most EF articles describe how to work with data: [selection] - [modification] - [record], and DbContext is recommended to be released as early as possible. In my case, the lifetime of the list coincides with the lifetime of the application, sampling is required only at startup, to load the saved data, then only modification with subsequent recording. It turns out that I need to constantly keep the DbContext. Is this acceptable, or do you need a different approach to working with data?
2. Question regarding the mechanism of backups in general: I tried to google, but did not meet such options. Perhaps so few people do it because there is another approach that I don't know about?

Answer 1

The decision is determined by the size of the list. If the size is such that there is a strong swap in RAM, then you need to work with samples from sql. For any, everything does not fit into the screen and hangs.

Answer 2

Quite normal, especially for working with a database.
And the entities in memory (and on the screen) can then be respectively changed/deleted (marked)/added, which will later "branch" their behavior (ultimately update / delete / insert)