Long term storage of encrypted data Say that I have 16-32 GB of data, and I want to devise a system for storing this data in an encrypted form. This system needs to meet two core objectives:


The data needs to remain as pristine as possible for a very long time, which in this case means 10-50 years.
No one but me should be capable of decrypting the data.


Here's the system that I've come up with so far:


Two copies of the data are stored, each on its own flash drive.
These flash drives are encrypted using VeraCrypt.
Every year, on a specific date, I mount both devices, and copy the contents of one onto the other.


Are there any obvious holes in this system? Will copying the data as described above keep the data "fresh"?
Answering question 1:
I see the following flaws in your model:

flaw 1: Any currently known data storage device is prone to accrue errors and data degradation no matter what you do. They also have an expected lifetime, with a different failure rate. USB devices have less durability (on average) than hard-drives, for instance. This means that you may lose both drives at the same time, and probability for this to happen increases dramatically over time, no matter how good you conserve the drives.

Solution:
replace unreliable USB technology with hard drives or tape, which are more appropriate for long term storage (although they also are not invulnerable).

flaw 2: Having only two devices means that you will have a RAID-1 equivalent. With that approach, if you lose a drive, you need to replace it and resilver from the surviving one. That puts a lot of stress on the surviving drive, and in case of failure during the process, you lose data.

Solution: You need to add more drives to reduce the probability to have a single source of data.

flaw 3: Copying the data on a yearly basis means that any silently corrupted data in drive A will be copied into drive B, so you are unwitingly damaging your data.

Solution: Use a hashing tool like ‘hashdeep’ to bulk create checksums of your files in both drives, and use a comparisson script to check and compare both drives individually on a regular basis. Your full-checksum-test will evaluate any damaged data in a drive and you can copy and replace from the other drive.

flaw 4: If you use a single large file as container with VeraCrypt, the above flaw 3 is harder to resolve. A failure in a portion of your large container file means you will need to fully resilver the entire dataset.

Solution: You may prefer to use LUKS encryption, or file based encryption like gpg for your full dataset, so that the 'hashdeep' process is executed over individual data files and isolate errors won't affect the full encrypted container. This way you can individually isolate damages and replace files from any of the surviving disks after your regular (monthly or yearly) full-checksum.
As a side note, for that long storage time, a separate set of replicas in RAID1 in a remote location is convenient. Also mixing drive technologies so that you don't hit a controller bug that will affect all your drives.
Answering question 2:
Nobody can for sure ensure you 100% that any current encryption algorithm or its implementations is free of bugs, flaws or vulnerabilities. Considering that long time, your best option is always to mitigate the physical access to the drives, on top of the encryption applied, keeping them stored safely in locations where you and only you will be able to access them during this time.
Obviously your threat model must be studied further depending on whether you are storing only personal love letters to be protected from ex-girlfriends or whether you are storing valuable trade secrets that a Court may seize.
Good luck.