Why are slices increasing?

You're doing all of the right things. There are many knowledgeable folks here that are willing to do their best to help. Feel free to post any questions that you may have.

Regards,
Bruce

 

Actually with XP Home, when going to Control Panel>Performance and Maintenance>System>System Restore tab

...and click "Turn Off System Restore" I get a window advising me that restore points will be deleted. Checking my HDD free space before and after, I can confirm that it did just that.

 

Yes indeed, but my instructions for cleaning System Restore would leave you with the last restore point (in case you needed to roll back your system in the event something went wrong ) rather than deleting them all.

Regards

 

Just completed a Full archive of my internal disk with 13.3 GB used and 97.5 GB free.

Called this archive "MBU23Dec". Well it came out with 24 slices and consumed 92.9 GB of my external HD !?

The only other archive on the Backup drive is called "MBUDec22". It has 13 slices and consumed 50.23 GB.

Must be something else than this Windows restore business.

I have yet to validate today's backup. I'm tempted to erase the 2 backups on my backup drive and start fresh. But then I just wonder what is happening with all that space. Could it be the Partitioning function of ATI? That portion in the archiving process is the longest operation to take place.

 

What is the file size of each slice? Its sounds like you are backing up to an external drive that is formatted as FAT32. If that is true then TI is breaking them up to be about 4GB each which is the file size limit for FAT32. You may wan to format your external drive to NTFS and then you will only egt one large file when you backup. If you divide the number of slices into the used space you get about 4GB/slice in both the scenarios you mentioned.

 

Yes I knew slices have a maximum of 4 GB under FAT32 format. But why does FAT32 require 92.9 GB of space to archive a HDD of 13.3 GB?

Formating external drive with NTFS now...

 

I'm not expert here but he size of the allocation units may be making a difference. Look at these Microsoft articles
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/convertfat.mspx for FAT32 to NTFS info.
http://support.microsoft.com/default.aspx/kb/310525
http://support.microsoft.com/kb/314878

 

The external HDD has 50% NTFS formatting done, as I write this. I intended to delete the two ATI archives anyway and start fresh after formatting is done.

In the meantime I created a restore point for the internal drive and will shutoff Windows Restore prior to doing the TI archive.

 

Completed my first archive under NTFS file system in my External HDD.

Before doing so, while my external HDD was powered ON, went to Start>Control Panel>Performance and Maintenance>Restore tab and saw that both internal and external drives were programmed for Windows Restore. Turned that off (and will remain off) and it confirmed OFF for each drive.

The new archive took 12 minutes (the one before was 2:24 hours) and the size in one slice is 9.686 GB (the one before was 92.9 GB in 24 slices)

The above 1st archive stats are about the same as for the 1st archive with the external drive formatted in FAT32. It is the next archiving events which will confirm if things are as they should be. Nevertheless, my sense is, at the present time, that shutting down Windows Restore is important and that TI 10 probably prefers archiving to the NTFS file system. We know that TI 10 is not designed for Windows 98 but for XP.

And then why was it that the partitioning portion of the archiving was so long to take place, was the operation overriding something? Will watch this the next time...

 

Today I just made a second Full Image archive of my 13.3 GB data on my internal disk.

Following are the process duration:

Creating Partition Image = 15 minutes
OEM recovery disk = 1 minute
C:\ = 10 minutes for a total of 26 minutes vs 12 minutes for the first archive under the NTFS file system. Still only one slice, however. The file size for # 2 is 19.35 GB vs 9.686 GB for # 1.

Validation took 14 minutes vs 7 minutes for the first one.

Just noted something in properties of my external HDD drive:

The "Allow Indexing Service to index this disk for fast file searching" is checked.

I would think that checked mark should be OFF. I have a choice of:
E:\ only
E:\, subfolders and files.

My sense is that it should be the second choice.

Once I put this indexing OFF, I believe I should delete archive # 2 and do a # 3 and see what happens. If one of you can comment before I do the above...

 

Archive # 3 without Indexing Service took the same time as the previous one. And the same size file = 19.35 GB (while the first archive yesterday was 9.686 GB)

Therefore the following questions should be addressed:

1. Should Indexing Service be allowed for the Backup external drive?
2. Since indexing is not impacting file size, why is the next archive doubling the first one in size?
3. Should Compression for the Backup external drive be ON?
4. If it is not critical to keep an archive file on the Backup external drive (no recent events to justify this), should I delete all archives first then do an Full Image Archive?

Reason: feels strange to restore a 9.686 GB data drive with an archive of 19.35 GB!

Correction the Internal drive has 13.3 GB of data (9.686 GB is the size of Archive # 1)

 

I think indexing is a red herring. For a start, once built adding/removing files will have an insignificant effect on the size of the partition. Can anyone suggest why/how indexing affects backup or restore ?

F.

 

Can't see that indexing would impact on the size of an image BUT for most Indexing is perhaps best turned off. In any list of ways to speed up/improve your system "turning off indexing" is always near the top of the list

 

...but then, ON or OFF, there was no change in speed or file size.

 

No But if indexing is off then you should experience a general speed up of your machine.

 

Yes I realise that, but have obviously lost the gist of the thread. I thought the problem was an disproportionate increase in image size - nothing to do with speed.

Indexing will not significantly affect the size of an image - especially after it has been built.

F.

 

I agree with Foghorne. The original issue has been resolved by the mfabien reformatting his external drive from FAT32 to NTFS. Indexing has absolutely nothing to with the original problem

 

The original issue of the increase in the number of slices has been resolved by reformatting with the NTFS system. But the increase in slices, under FAT32, was pointing out to a more complex problem.

Under NTFS I'm still getting an unexplained increase in file size from one archive to the next without alteration of the size of the source drive, which is 13.3 GB. The increase of the slices with a FAT32 format simply added to puzzle an element which some, at the time, thought was caused by FAT32. But the increase in file size is still taking place under NTFS (#1 = 9.686 GB, # 2 = 19.35 GB). So, what is going on?

Window Restore is off
Indexing Service is off



Partitioning of the second archive seems to take a much greater time than the first archive. And, based on past experience, the third archiving will be worst. Consequently, am I to conclude that one full image archive of my internal hard disk is all that should be stored on my 250 GB external HDD?

Am I the only one with this kind of file increase when adding additional Full image archives to a dedicated HDD?

 

To my simple mind it sounds as though you are including the first .tib file in the backup. Make sure that only disk 1 is ticked on the Partition Selection screen as below and that it is not being created on your C: drive.

If this is not the case download and install TreeSize Professional from http://www.jam-software.com/treesize/ mount your image and check for files or folders amounting to some 9.6 GB in the mounted image, compare the tree with that of the original drive.

 

I think you have put your finger on the problem. I have been ticking Drive 2 as well.

Will delete archive 2 and do a new archive with Drive 1 only. Be back later...

 

Como,

Yes that was my problem.

My latest archive was 9.692 GB in size and took 10 minutes plus 8 minutes to validate.

The 1st archive on the newly formatted external drive was not impacted by my ticking drive 2 because it was empty at the time. But the subsequent archives were compounding the size of their file because I was backing up the backups each time. I thought ticking drive 2 was telling the program to go to that drive when in fact it is the command line starting with E: that sends the archive to the specific drive.

Thanks to all of you and to Como.

My only small outstanding question now is:

Do I leave the Indexing Service OFF my backup drive or not? The archive is an image, is indexing of any use?

 

Good to see it is all sorted now. At the risk of being told that I have lost the gist
again I still think that indexing is of no use to anyone and should always be turned off. The only exception might be a librarian who spends all day searching.

 

Indexing will not do you much good for its intended purpose since you will typically have a small number of files on your backup drive and will not likely be searching them in the XP search sense.

I would turn it off but I doubt if it would make any noticeable difference if it was left on.

 

Thank you all and Merry Xmas.

 

I agree that indexing should be turned off it is only of use if you are searching a large number of files and you would probably need a stopwatch to tell any difference anyway.

When backing up your system drive, make sure that you tick drive 1 as in my screen shot otherwise you will not include the mbr in the archive.