And why are you not considering git itself?
The strategy you describe, after one full and two incremental backups, has it's complications when you continue. It is easy to make mistakes, and it can get very inefficient, depending on the changes. There would have to be a kind of rotation, ie from time to time you make a new full backup - and then do you want to keep the old one or not?
Given a working dir "testdir" containing some project (files, and subdirs), git makes by default a hidden .git subdir for the data. That would be for the local, additional version control features. For backup, you can archive/copy it away to a medium or clone it via network.
The revision control you get (without asking for) is a side effect of git's differential storage.
You can leave out all the forking/branching and so on. This means you have one branch called "master".
Before you can commit (actually write to the git archive/repo), you have to configure a minimal user for the config file. Then you should first learn and test in a subdir (maybe tmpfs). Git is just as tricky as tar, sometimes.
Anyway, as a comment says: backing up is easy, hard part is the restoring.
Disadvantages of git would be just the small overhead/overkill.
Advantages are: git tracks content and file names. It only saves what is necessary, based on a diff (for text files at least).
Example
I have 3 files in a dir. After git init, git add . and git commit I have a 260K .git dir.
Then I cp -r .git /tmp/abpic.git (a good place to save a backup:). I rm the 154K jpg, and also change one text file.
]# ls
atext btext
]# git --git-dir=/tmp/abpic.git/ ls-files
atext
btext
pic154k.jpg
Before restoring the files I can get the precise differences:
]# git --git-dir=/tmp/abpic.git/ status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: atext
deleted: pic154k.jpg
no changes added to commit (use "git add" and/or "git commit -a")
Here I want to follow the git restore hint.
After git --git-dir=/tmp/abpic.git/ restore \*:
]# ls -st
total 164
4 atext 156 pic154k.jpg 4 btext
The jpeg is back, and text file btext has not been updated (keeps timestamp). The modifications in atext are overwritten.
To reunite the repo and the (working) dir you can just copy it back.
]# cp -r /tmp/abpic.git/ .git
]# git status
On branch master
nothing to commit, working tree clean
The files in the current dir are identical to the .git archive (after the restore). New changes will be displayed and can be added and committed, without any planning. You only have to store it to another medium, for backup purposes.