Yes, your dbdump that corresponds to the incremental must be stored alongside the incremental.
Your incremental should also know about files that have been moved/removed (e.g., moved from contentstore to contentstore.deleted) and restore of the full+intervening incrementals should exactly replicate the state of alf_data at the time of the last incremental in the restore. So if files have been removed completely from contentstore.deleted, or have been moved from contentstore to contentstore.deleted, your restore procedure should reflect that.
If it doesn't (e.g., if FULL+incrementals restore is only additive, not reflecting moves or removes) then alfresco will not start (content integrity). Whatever your backup procedure (and this gets more important as your procedure gets more complex, as with FULL+incrementals, you should test restore). You'll also want to run the incrementals when alfresco is either down (if you can tolerate the downtime) or when there's likely to be no traffic. This is because content updates/add/remove between when you take the incremental and the db backup is likely to cause content integrity issues.
Where I work, the sysadmins have settled on dirvish. You might look into that if you're using Linux. It's a lot simpler than incrementals. Identical files from multiple backups are stored as linux hard links. So only one copy is kept around. If all links to the file are deleted (it was deleted N days ago and we only keep N backup generations) then the disk space is freed up.
There will be occasions when we keep two copies of the same file (moved from contentstore to contentstore.deleted and not yet physically removed from one), but the disk space used isn't anywhere near Nx[content size] where N is the number of generations.
I don't think I would (for myself) use FULL+incrementals for alfresco backup. disk is pretty cheap and the added complexity of FULL+incrementals is not something I'd like to deal with when restoring.
Good luck.
