For a single machine, the most straight forward method is to create an account under the Builtin Backup Operators group.
There are two large drawbacks that initially come to mind when running programs under SYSTEM.
Almost always the biggest reason admins create discreet accounts for scheduled processes is to monitor them and grant them access one would normally not grant to a typical running application. In this case, it needs read access to all files and needs write access to your backup storage location, the later tending to have more strict access.
To give any program that runs as SYSTEM amounts to running them as an admin more or less, thus granting it more privileges than it needs. There is a built in Backup Operators group for this reason.
The SYSTEM account is sometimes mistaken by users as a SuperUser or a root account. It is neither. It is used internally by Windows. It was never intended to be used by programs unless the program specifies it. That said, there are unknown bugs that creep up if running a program not designed for the SYSTEM account. For one, notice there is no user password for it. Nor is it actually a user account if you try to authenticate to it remotely.
Anecdotally,, UAC also plays havoc with programs that run under the SYSTEM context. I've seen badly written programs straight up throw up a dialog asking the user to "run as Admin." Go figure.
Also there is an MSDN blog post that comes to mind that I cannot find that the author spent a whole day debuggging SQL Server on a client's machine. Fresh install . . . or so they thought. Turns out, a certain component of the OS itself was switched from NT AUTHORITY\NETWORK SERVICE to SYSTEM, under the guise that it had a more permissions and privileges than any other account. Rather, it just has different ones.