Same OS Backup Different Results
I did the following three installs of CentOS 6.3 Basic Server, but am receiving different results during backup and for the life of me, I can't understand why.
1st Install (Fresh-yum-waninst-script.tib)
1. Install CentOS
2. Do yum update
3. Install Dependencies for Sangoma Wanpipe drivers
4. Run FreeSWITCH Script (Installs FreeSWITCH, Postgres and FusionPBX)
* Backup and Verification succeeds and I am able to Restore.
2nd Install (Yum-script.tib)
1. Install CentOS
2. Run FreeSWITCH Script (Installs FreeSWITCH, Postgres and FusionPBX)
* Backup and Verification succeeds, but I am not able to Restore.
In the 2nd install the backup was much bigger and split into two archive files even though the 1st install's actual data was more to begin with, than the 2nd backup and the 1st backup was not only not split, but it was considerably smaller as well.
Even though it didn't make any sense, I thought that it may have something to do with the order of the install so I made a 3rd, slightly different install than the 1st, and tried it again, but with no luck.
3rd Install (Yum-nb-script)
1. Install CentOS
2. Do yum update
3. Install Dependencies for Sangoma Netborder Express (same dependencies as for Wanpipe + imake)
4. Run FreeSWITCH Script (Installs FreeSWITCH, Postgres and FusionPBX)
Backup and Verification succeeds, but I am not able to Restore.
Again, the archive was split into two even though the data on the partition being backed up was smaller in size than the data on partition backed up in the 1st install. See Pic Sizes.
Furthermore, when I go to Recovery and click on Refresh Backups, if I were to right click on the 1st backup and go to details, it has "a green bill of health" as seen in pic 1st_install. If I were to do the same for the 2nd or 3rd backup, it displays a tiny red x next to the drive as seen in pics 2nd_install and 3rd_install.
I am truly perplexed as to why it would work with the 1st install and not with the 2nd or 3rd
Thanks in advance for the help.
In the latest test, I worked with yum-script.tib.
When I verify the archive, I get the message "The archive was successfully checked" as seen in pic 754
I tried to recover that same archive as seen in pic 751 which shows it's size is 3.626 GB which means that the archive should never have been split in the first place even if it was copied at a 1:1 ratio.
Pic 752 shows that I am recovering partition D to partition D so not doing anything wrong there and finally pic 753 shows the error I get which just says "Recover operation failed." It also corrupts my install so that I am no longer able to boot into Linux after attempting to recover the partition.
You are right that the the destination drive is Fat32, but as I had mentioned and as can be seen in pic 751, the entire data on the drive at the time of backup was 3.626 GB, so why is it exceeding 4GB? Furthermore, my first install which is backing up and recovering successfully, after all the installs/upgrades have been made and done, is around 4GB, but is being saved in a barely over 2 GB tib file. Moreover, I can recover my first install, back it up as a different archive and recover that just fine as well, so it's not like the recovery worked once and that is it. There seems to be some sort of difference in the way True Image sees the installs.
I was also a little worried about not having my pbx backed up so I went ahead and bought HDClone after reading the reviews and it is making a backup and restore of everything. Including the image of yum-script above which is failing with True Image and it is saving it as an image slightly bigger than 2 GB. However, I'm still interested in knowing what the issue is with True Image and hopefully they can fix it in an upcoming version.
Thanks again for the help.
I meant to check the file systems of installs #2 and #3. You would need to boot into Linux or use a Live Linux CD and run a check on them (probably e2fsck or fsck).
Check the TI logs for those backups and see if anything odd is showing up (like switching to sector-by-sector mode).
I'm not really following.
The Linux OS which I am currently running is a continuation on the yum-script install, which fails to restore under ATIH 2012, but which I have successfully backed up and restored with HDClone. Meaning that if I back up my current install with ATIH, it will backup OK, verify OK and if I try to restore it, it will fail as well as corrupt my install by unmarking the Linux OS partition active.
Now would you like to me
1. Boot normally into Linux and run a file system check on the OS
2. Use a Live CD to boot into Linux then run a file system check on the Linux partition
3. Boot normally into Linux and run a file system check on the .tib file of the archive
#1 or #2. If #1 you would need to be checking a non-mounted partition (a reboot-type check would also work for a mounted partition). Basically, if it were Windows instead of Linux, you'd be running chkdsk /f on the partition(s).
This check is just because it seems that TI is detecting something wrong with the partition or file system, though it may just be TI.
Did you notice anything in the logs?
I'm using the TI rescue disk and didn't know that creates a log. Would I find that on the source disk or target disk and where exactly. I'm going to do a check disk with a Lice CD and report.
Thanks
The log won't be saved then. You could try creating a new backup and looking at the log before you exit TI and see if it shows anything.
The file system check took literally about 2 seconds to complete with CentOS Live CD 6.3 (pic 760).
I then went ahead and created a backup of partition D who's file system I had just checked. The partition is 10GB but only has 4.314 GB of Data (pic 761).
With 1:24 left in the backup (pic 767), everything looked good then the time would freeze, increase, come back down and go back up again (not much of an issue as this is only expected time.) At some point in the process, the archive gets split (pic 769) as the name changes from MudCrab.tib to MudCrab1.tib and the time has again shot up to 2 minutes when it had been 1:24 earlier. Finally I got the operation succeeded message.
The log for this "successful" operation is MudCrabBackup.log The total size of the archive came to over 5.5 GB (pic 777) even though all the data was 4.314.
I created a recovery operation (pics 778 and 779). Immediately after starting the recovery operation, I got the operation failed error. The log is MudCrabRecover
After failing, my system would no longer boot up (pic 781). I loaded the Live CD and it showed that there was no Ext4 partition (pic 782) and that the active partition was now my Fat32 partition.
The pictures are very telling. You may have missed the one showing the problem since you didn't comment on it. #778 shows that TI has the details incorrect for the partition recovery (Free space before: 8,589,934,592 TB, Partition size: 0 bytes, Free space after: 9.767 GB).
This is a known problem that has existed for several versions, but I don't know if anyone has reported it with a Linux partition. It could be caused by a bug in TI (likely), but may also be triggered by a partition or file system error.
If it's not too much trouble, could you save Sector 0 (the MBR) of the drive to a file and attach it to a post so I can take a look at it?
In the meantime, I'll put in a request to Acronis and see if they have any info on this problem.
I actually saw that, but didn't understand it, kind of like a deer in headlights :)
You are the one going through all the trouble, I just really appreciate your help. I have attached the MBR archive .bin within a zip file as it would not allow me to attach a .bin. While I greatly appreciate the help, HDClone is working a treat, I more just curious why it is not working, so no rush. Again, thanks for everything.