Today I tried to restore a friend's XP system from an image created by Acronis True Image 8.0 (in order to recover from a pernicious Trojan infection).
When I examined the .tib files on my friend's USB HDD, I found to my surprise that instead of each backup consisting of one large .tib file, it seemed to consist of four smaller ones.
There were two full system images on the drive, and each one consisted of four files, called My backup1.tib, My backup2.tib... etc. The first three were all exactly (and I do mean *exactly*) the same size (about 4.5GB) and the final one was about 2.6GB. In both cases the four files carried the same date, and were created about an hour apart. My friend confirmed that his backup takes about 4 hours (he only has USB 1, so the data flow is slow).
I asked him whether he had created any subsequent incremental backups, and he said no - just the two full backups. And he said that he had successfully verified both the backups.
So, it appears that Acronis has broken up his backups into four consecutive .tib files. Does this sound possible or likely? Do you think it will be safe to go ahead with restoring from one of these four-file sets?
I am guessing that the disc is formatted in FAT32 and the files have to be split due to the files size limit in this type of format
Maj - yes,my friend is using a hard drive, but I take your point.
100andthirty - I never even thought of that! But isn't the maximum file in FAT32 4GB? Three of the four .tib files in each backup are slightly larger than that.
the file size is about 4GB but this is a rounding based on 1024 rounded to 1000!
the maximum file size for FAT 32 is about 4GB; 2 to the power 32 or 4294967296 bytes
if you open My Computer, right click on the drive, and select properties, it'll tell you what the file format is.
I do think this is in FAT 32 and it's three files amounting to one back up; if you run Trueimage, it'll sort it out for you.
I have a full disk backup of my C: drive on a Iomega Ego 250GB USB external drive, it's formatted to FAT 32 and it consists of 27 TIB files adding up to 107GB (no partitions and some games installed, I guess this is the reason for the big file size), each file is 4GB on disk. I've verified the backup from both inside Windows and the boot CD and the integrity was reported as fine so I'm guessing what you report is correct.
Before restoring your friends computer I would recommend verifying from the boot CD, I've read that sometimes the verify process can work from Windows and the recovery itself can still fail, if it verifies from the Linux boot CD environment then it should be safe to recover.
100andthirty - I'm sure you're right about this, and it's a big relief to know that the backup isn't faulty. Thank you!
gazzaho - thanks to you, too, for confirming the FAT32 structure of an image.
I've never yet restored from an Acronis image, but I've looked through the Restore Wizard. When I restore from this four-part image, will Acronis 'chain' the files automatically? In other words, do I simply have to point to the first 4GB file and allow Acronis to find the others, or do I have to tell Acronis about files 2, 3 and 4 as if they were incrementals?
Does anyone know, please?
As above its done that as its Fat32, You should select the last image created to Restore it all. NOT THE FIRST
Aha! That's valuable advice, woodchip. Thank you.
So (just to be sure I understand) given that the files are called 'My backup1', 'My backup 2' and so on up to 4, when restoring I must select 'My backup4' and Acronis will do the rest - is that right?
......Acronis divided my back up into 17 .tibs. When I restored it there was no guidance as to which to pick so I chose the first. I think the message that came up said " can't find the last file" or somesuch, so I started again and picked the last one. It then restored ok and picked up all the other parts without any further intervention from me.
Thanks Inside Edge. That confirms what woodchip said. So I'm happy that I fully understand, now.
Many thanks to everyone who responded. Your advice is really valuable.
This thread is now locked and can not be replied to.