How many tib files?

there are as many opinions as people and much of what will drive the decision is your tolerance of risk, your amount of storage and your tolerance of time to create the backup and possiblky to restore from it.

I have personally restored a file from an INCR chain which was 56 links long (full with 55 daily incremental). This is not normal for me, I did a chain of this long mostly to prove it would work as desired. - it did - so to that end a chain of 12 is do-able. For what its worth, when I performed this 56 link restore the process was not any different than restoring from a single full backup. I do not have timing for you, I started the restore and walked away came back about 2 hours expecting it to be done ( and it was). I suspect a 56 link chain takes longer to restore than a single full backupbut it certainly did NOT take 56 times longer, my guess is a few extra minutes mover over the 2 hour event.

In general long incr chains are not ideal the most quoted reason why is if any file in the chain is corrupt all the links which come after it are worth less and you will only be able to restore up through the last good .tib file in the chain. It sure would suck to have 14 days of daily incr backups only to find that the file from day 3 is corrupt. (which means you only can restore through day 2). Now to be fair, there is no more reason that any given .tib file would be corrupt than any other file on your HD. So the chance of tib 56 being corrupt is no greater than the chance of .tib 2 being corrupt its just the downside risk that if tib 2 is corrupt than it really doesnt' matter if all the others that came after it are viable or not, they are worthless.

My personal experience with how I use a PC, is a daily incr file will average about 4% (or less) the size of one's full backup.
so the sum of two weeks of INCR files will end up about 50% the size of my original full and a month of incr will be about the size of a full.

Most of the time I do backups in two "lines" ("a" and "b") each is comprised of a full and daily incrementals.
Typically one line is to a local USB drive the other to another drive somewhere else on the network.
Typically I have each line's full backup occurring midway though the other's cycle.
For example one line might do a full only on the 1st of the month with daily incrs.
the other doing a full on the 16th with daily incrs.
In the example above with the exception of the 1st and 16th, every night at 2am each line performs its own INCR backup each of which take mere minutes. Its only on the 1st or 16th will there be a situation where one line will be perform a full and the other an incr.
Typically I configure things such that when a full is performed the entire prior chain is moved into a historical folder.
This means, even though I just performed a full, I still have the option of restoring files as they looked XX days ago.

If murphy was to strike my PC dead, I always have several different independent backups from which to choose from to perform my restore.
Any of my backup lines are perfectly capable of getting me back to 2am the prior morning. It really doesn't matter which line I use, whichever is easier at the moment is acceptable. Though we talked about the dis-advantage of incr chains, a big advantage of long incr chains is you can restore any file as it looked in any date from recent history and you can do this without having spent thousands on disk drives. With multiple lines (and generations) you also have many different options from which to restore any file as it was in the last xx days. With a 1TB drive costing about $100 one there really isn't much cost to automating your way into several backups on several independent devices and always having multiple restore options regardless of which day of the year diaster strikes.

Really, the most important thing you can do is to automate your backups so you always have one without you doing a dang thing, the sun comes up the sun goes down and oh yeah, your backup system created for you another backup.
2nd and 3rd on the list are
a) backup your backups (multiple lines) so if one line is corrupt you still have options from which to restore - over the years we all have heard stories where people complain they lost their drive/file and their (only) backup was un-usable.
b) physically protect/secure/insulate your backups so if something occurs akin to fire/flood/theft you have restore options outside of that threat.

So to answer your question, your probably due to start a new chain, and while your at it, consider automation, generations and isolation.

Sometimes when a disk goes wonky, you can notice the problem right away. Other times, the wonk might be days old before it rears its ugly head. I suggest you store as many complete backups (either full backups of sets of incs/diffs) as you have room for. Remember that you can only restore for as far back in time as you have a backup and if you need to restore because something has gone wonky on your disk, then the more recent backups might have imaged the disk with the wonk. In that case, rstoring form one of those images will only regive you a disk with the wonk still there. So, in that situation, you will want to be able to reach farther back in time, so to speak, for a restore.

Some folks will keep, say ten full backups (or full sets) in a row, deleting the oldest when the next one is made and keep a backup separately for a long time just in case. And ATI can be set u to do this for you automatically, as oracledba pointed out.

I have, on rare ocassion, had reason to go back to my "old" backup, after which I restored some particular, more recent data files from a later bakup to bring the restored image more up-to-date.

I would urge folks to decided how much they can afford to lose, how far back they might need to go, and buy storage space to fit that need. Storage space is very cheap these days and losing a disk can be very costly in lots of ways.

Thanks. I apologize for the long delayed response. I finally have everything straightened out and working on a new machine. Your advice is in place.

Ken