File Naming Issues - Proposed Solution

1) Create a directory where image(s) are to be saved.
2) Decide on a filename for the image. Use that filename as the "root" for the image backup filename. Lets use "W8_x64progs" as the example.
3). Construct two .bat files. One should have the function to delete the previous backup in the directory. For example: "DEL E:\images\W8_x64Progs.tib". Name this batch file delete.bat, or something similar. The second batch file should contain a command to rename the Acronis-created filename with your filename (root). For example: "RENAME E:\images\W8_x64Progs*.tib. W8_x64Progs.tib". Save this batch file as rename.bat, or similar.
4) Save the two batchfiles anywhere that does not require elevated privileges to access.
5) Now create your backup job in TI2013. Under "backup options", select "pre- post- commands"
6) Your pre- command should point to your "delete" batchfile. This will delete the previous backup prior to making the new one. If you don't want to delete the old backup, modify this step as desired. Check the option to finish the command prior to execution of the job.
7) Your post- command should point to your "rename" batchfile. This will rename the backup containing the Acronis attached suffixes (i.e. b1,s1,v1, etc.) with the simple filename root you chose. Check the option to finish the command prior to execution of the job.
8) Obviously you can modify any or all of these steps to fit your particular needs.
9) what will happen is this: when the job is run, first the previous backup will be deleted. Then a new backup is created with the TI2013 created filename additions to the name root you create. Finally, after the image is created, the filename is changed to the root you selected, stripping off all the additional naming verbiage.
10)Perhaps best of all, no registry "hacks" or software modifications are necessary. This procedure only utilizes functions and commands that are already available. :)

Hopefully, this will give all of you having these issues some ideas of a "fix".

Regards, T

.

Many of us recommend that a backup never be deleted until you have a proven replacement. Hopefully you have other backups stored in other locations , which can be utilized once your most current backup has been deleted, should the yet to be created be corrupted during the creation process.

TrueImage will create a new full backup each time it is run as the original will have been deleted.

Yes I have redundant copies elsewhere on another media. I only make full backups, and only when I'm sure everything is working properly. I.e., no differentials, incrementals, etc. also, I only image the OS Drive in case of disaster. For data, I mirror file by file to a second drive.

You could also use the rename command (instead of delete) in the pre.bat file and then have the post.bat file do the deletion of the original file AFTER the backup. You would have to change the original backup file extension with the rename command in the pre.bat file so that your post.bat file could still do the rename correctly, then issue the delete command on the renamed original backup file. (for example: ren (or rename) *.tib *.oldtib in the pre.bat file, and del (or delete) *.oldtib in the post.bat file)

James F wrote:

You could also use the rename command (instead of delete) in the pre.bat file and then have the post.bat file do the deletion of the original file AFTER the backup. You would have to change the original backup file extension with the rename command in the pre.bat file so that your post.bat file could still do the rename correctly, then issue the delete command on the renamed original backup file. (for example: ren (or rename) *.tib *.oldtib in the pre.bat file, and del (or delete) *.oldtib in the post.bat file)

I like this idea! Especially for those who do not have redundant backups.
Regards,
T

You may already have this covered but you wrote
" only image the OS Drive in case of disaster. For data, I mirror file by file to a second drive."

IF this OS DRIVE has hidden partitions or partitions without letters, you should include those within your backup--especially if they are boot or recovery partitions. See note below. A backup of C only may not be sufficient to create a new bootable replacement disk. In fact, if your "system disk" has a data partition, you should consider including the data partition within the backup but use the exclude feature to exclude all the data. Using this method, the backup of the system disk would include all partitions but excluding the contents of the data partition. If a new disk created, then the base backup would restore its contents and an additional restore of the data partition only would be needed to fully have an identical replacement disk.

Note: The Windows Disk Management tool would show your disk partition structure and any non-lettered partitions.

Yes. Thank you. I actually have three physical drives in my machine. I believe that creating partitions on one physical drive is only asking for trouble, since if that drive goes out there is certainly the risk of losing all of the partitions. Therefore I have an SSD drive (C:) containing only the Windows OS and "programs". My D: drive also contains a single partition and contains only my "data" and personal files. And finally, an E: drive which contains only the backup images and mirrored files. C backs up to E, and D backs up to E. My personal files mirror to E in real time. In the event of failure of drives C or D, I simply replace them with a new drive and either restore the image on C or reverse the mirror copy to D. In the event of failure of Drive E, I would replace that one and remirror or reimage to the new E drive. This gives me at least double redundancy, but I have another procedure in place which extends that to triple. Drive E copies its contents out once a week to an external drive. That drive turns on only long enough to receive the copy then powers off again, making for very little use. I use a BlacX drive for that and every month I swap the drive in the. BlacX box with one I keep at my office. This gives me an "off site" copy of everything that is no more than one month old. Everything except my swapping out the drive to my office is scheduled and automated so I don't really have to do anything.

Sounds like you have given this a lot of thought and well covered. The only thing I would add further would be if you have not actually tested your restore procedure, I would prove your recovery procedure by actually performing a restore--perhaps to a test disk. Good job!

Oh yes, tested that too! :)