It is not file is getting deleted after the retention period, but a catalog record about that file. When that record is deleted, you are still able to recover the file. But, you won't be able to find it or select files to extract from jobs whose files were expired. All you might be able to do is to recover the whole job, optionally you can filter which files to extract with regexp. When the job catalog records expire too, you may still extract data from the (raw) volume.
Also an option is this case is to extract old catalog backup, recover it to some VM and use that to recover files from old jobs.
Only the "volume purge" operation irreversibly destroys old backup data. You have set retention period for a year, which means, if you really be able to keep all those volumes that long, you'll be able to recover any files up to a year ago. This also means, while it is possible to set volume retention period shorter than others, this configuration is useless — your files and jobs retention period will be effectively cut to volume retention. When Bacula/BareOS is going to purge a volume, it first removes all jobs which used that volume and consequently all files which belong to that jobs.
File records take by far the most space in the Bacula/BareOS catalog database. This is the motivation to expire file records early — to keep the database from inflating.
All of this doesn't correlate much with how often the file is updated. You should you have regular full backups (by default, once per month). It serves as the "base" for subsequent differential and incremental backups; unchanged files don't get into those relative backups. But full backup always contains all files, even those which are unchanged since some previous backup. For instance, if you backup some fileset which doesn't change at all, you will have all full backups of the same size and zero-sized differential and incremental backups.
Also notice, by default change of fileset triggers a full backup.
