Reducing TIB file size after deleting some recovery points

Hi Ondrej,

I assume you are using Always Incremental archive type (default one: Single file for all backups), so it is not possible to reduce the physical size of the archive file. This archive can be considered as a container which grows only until there is a space requirement. Now since the retention rules took place (7 backusp were deleted) there is additional space freed up inside your archive which means that the next backup attempt into this archive won't expand it (until this free space is used), so the physical archive file size won't grow any more and will remain at 400GB rate. You can check additional details about this type of archive here:

http://www.acronis.com/support/documentation/AVMP8/index.html#15030.html

There is one tip which may be useful for you: you can set up 2nd destination option (dual-destination) in your backup task which will copy the recovery points from your existing 400GB archive into new one (can be on the same location but with different name). This new archive will be around 138Gb since it will be compacted after copying (copying does not migrate the "free" space from old archive to new one). After that you can get rid of your original archive and continue backing up into the new one.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

I have a question on this actually.

I want to save some space so I've been going in and changing the simple cleanup scheme to from hold 7 days to hold 3 days.

Then in recovery points I've been looking to see what I have. There's a machine with over 100 recovery points. Some with 10, some with 14. Though they used to be set at 7.

Now that I reset it to 3, will the tib file with 100+ recovery points be reduced to 3? Will the ones with 10 or more be reduced to 3?

Also after making these changes the virtual machine memory usage for AcronisAppliance8 went into alert. Then my backup location said it was an unavailable location. I had to tell the vm to power off and on to get it to be able to see the backup location again.

Hi KJSTech,

The retention rules are applied to backup archive only when the backup task finishes, i.e. in the end of it. The retention rules will be applied to recovery points of the VMs which are backed up within this particular task where you set up the retention rules (you should be able to see in the log file the event of recovery points deletion).

Also the retention rules behavior depends on the archive format ("single file" or "multiple files"). If you have "multiple files" archive format then everything depends on the setting where you define how often to create full backup, since only entire Full+incremental chains can be deleted (you cannot delete just incremental recovery point from such archive). For example you set "multiple files" format, keep backups for 7 days, create full backup each 30th day then the backups (first chain of 1 full + 29 incrementals) will be deleted only after 37 days, i.e. only when the whole 1st Full+incrementals chain becomes subject to deletion. The "single file" archive format is not affected by such behavior and any recovery point can be deleted from it, so it should always keep only 7 days of backups.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Vasily. I use single file because it just seems simpler to manage. Thank you for your explanation.

I was confused because a machine had over 100 restore points in a single TIB file. I changed the job to specify 3 restore points. Sure enough today now the tib file contains 3 restore points, so it is based on the job.

We backup 1 machine per job. This way if a job fails we know at a glance which machine did not back up.

Hi there,

i have a question to this topic too.

our first Backup Location is 1TB, and available Size is now only 5%. so we created a second storage with 2 TB, created a new task, and shifted 10 machines from the first backup job and store to the second. i also deleted some old recovery points manually (which is by the way awfully slow with just 600 recovery points, now 500). if i understand right, there is no other chance to free up the unneeded space displayed in the gui, except you create a new storage location and shift the job and recovery points, right?

But the problem isnt solved so far, cause i never will know how much space is really left in the mounted storage, so i if it is running out of space again, i have to create a new one and shift again, hence i am not able to calculate how many recovery backups i can store in a storage. there is neither a way to disable the "running out of diskspace error".

Will there be any fix in the newer builds / version ? And is it possible to speed up browsing and deleting in recovery points. it tooks me over 1 minute just for displaying the available recoverpoints, and another minute to approve the delete task and more than a nother minute to reload again and so on. (we are working with a single tib file and always incrementel with a retention period of 14 days)

Thanks a lot in advance.

Regards

Peter

Hi Peter,

If the archive has grown up to the stage where you had to manually delete the recovery points to free up the space inside it - this means that the original planning was not exactly right. 600 points/14 days = 42 machines which means that you should estimate the space required to keep the desired amount of recovery points. Though I assume that your new 2TB storage would be more than enough to keep all the backups inside it during the required retention period (so it will not grow indefinitely).

One of the ways to get rid of the large archive is to edit the backup task and add 2nd destination option. After that continue backup into it. What will happen is that there will be 1 recovery point added into the original archive + all recovery points from it will be cloned into the new archive (on 2nd destination) which size will be equal to real size of the recovery points. After this run is done you can delete the original large archive and redirect the 1st location to the new cloned one (which will be significantly less in size). As the result you will have new archive with all your existing recovery points and it will be less in size (thus you will get rid from the low free space alert).

In order to speed up the recovery points browsing you can increase the amount of RAM assigned to the virtual appliance and reboot it - increasing the RAM typically speeds up the browsing of recovery points drastically especially when there is more than 300 of them in one location.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hello Vasily,

thanks for your very fast response and your detailed explanation. i understand the "workaround" already, but thanks for explaning again ;)
Our appliance already has 4 GB RAM but it is still slow. And more cant be used due to the 32-bit OS Environment.

But maybe i should just split up the backup jobs into smaller ones.

Regards

peter

Hi Peter,

The main bottleneck here is the recovery points amount (not even the size) inside one location, so yes, you can split the job into 2 or 3 tasks for example and the main idea is to make them backing up into different subfolders on your current location (so that there are 2-3 backup locations instead of one). This will improve the performance.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

but then i need more storage space, because DeDup isnt as efficient as it could be :(

Regards

Peter

Hi Peter,

The inline deduplication is most efficient when you back up VMs which have been cloned from one same template, thus if you back up different types of VMs the deduplication won't be that effective. Therefore if you group similar VMs inside one backup task then you will get the most benefit from deduplication (so different types of VMs will be backed up into different archives and still you won't see too much difference in space consumed).

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

When I backup my entire partion, Acronis premium 2014 shows a file size that is different from the actually file size. 455GB vs 76GB. Is there something in the backup setting that causes this?

When I backup my entire partion, Acronis premium 2014 shows a file size that is different from the actually file size. 455GB vs 76GB. Is there something in the backup setting that causes this? This did not happen with version 2013.

Hi Charles,

In Acronis True Image 2014 there are different compression methods used than in Acronis Backup for VMware (former vmProtect) discussed in this particular thread. I've asked my colleagues from Acronis True Image team and they advised that you should take a screen shot of the inconsistency you observe and create a new forum topic here: http://forum.acronis.com/forums/acronis-true-image-home-discussions/acr…

So far there are no such known issues except for case when entire disk is saved to Acronis Cloud storage by Acronis True Image 2014 - the sizes may be shown incorrectly in the UI.

Thank you.
--
Best regards,
Vasily
Acronis Backup for VMware Program Manager