If backup_parameter() takes a long time to execute, and has a priority that is higher than the priority of the task that flashes the LEDs, then it will starve the LED flashing task of any execution time, which is a task priority issue rather than a blocking issue.
Did you define configASSERT and enabled stack checking ? Did you verify that the task stacks are large enough ?
I think something (probably the backup task) is damaging internal data structures making your application not longer working properly. This is almost always caused by stack overflows given the code is not buggy.
Most microcontrollers can’t fetch instructions from flash while a write operation is in progress, so they appear frozen until the flash write operation completes. This includes most STM32 parts (the ones without dual flash banks), but I don’t know how GD32 parts behave. At least some GD32 parts copy instructions from flash to RAM during boot and then execute from RAM.
Double-check the capabilities of the Flash in the processor. As Tagli said, most processors are unable to read from one block of flash while another one is being written to.
Another possibility (as rtel mentioned) is that the FLASH_Program() disables interrupts to give it the correct timing, which will stop the rest of the system.
One technique to get around not being able to read and write to flash simultaneously is to copy the code you want running during the flash write to RAM, then temporarily execute from RAM. You would have to build the function copied to RAM specifically to enable that though.