CBT / SnapAPI clarification
How can give me clarification for the following question:
With a VMWare VA agent, Acronis can definitely make use of CBT (Changed Block Tracking) information, and perform incremental backups very swiftly.
To direct file level recoveries directly to the clients I learned that currently an agent is needed in the VM (see also KB 65204: Acronis Cyber Protect Cloud, Acronis Cyber Backup: Impossible to recover files to the original VM in case of agentless backup).
Such a client implements the SnapAPI (Acronis Snapshot Technology, also available on Linux) to get consistent backups.
Is such an agent based backup also able to perform block based backups that adress only changed blocks? If so, how is it performed: CBT should not be available to the agent as far as my understanding goes.
Regards, Tom
Vasily, thanks for clarifying this.
Are there any technical papers available that outline this "CBT for physical machines". I looked around and could find none.
Thanks, Tom
Hi Tom,
There is no such public paper, as it's quite low-level technology related to how the Acronis SnapAPI driver operates. Please clarity what exactly you want to find out?
Thank you.
I read KB 1512 about SnapAPI (awkward that including URLs here is not allowed ...), but this is only about ensuring consistency, and it does not mention that the agent has a mechanism to base its backup on changed blocks. That's quite an important fact indeed.
Another drawback of the mentioned KB is that it only mentions Windows, although the SnapAPI obviously is also present in Linux agent installs.
Technically, I also would like to know where the block changing information is stored on the client in absense of real CBT.
more information about the SnapAPI (as suggested in my last post) would probably help understand the current XFS File System Limitations:
- Files cannot be excluded from a disk backup
- Fast incremental/ differential backup cannot be enabled
- Volumes cannot be resized during a recovery
Vasily, do you believe that the KB might be updated?
Hi Tom,
The technology of blocks tracking during incremental backup is 8y old and is very low level. We typically do not share these deep specifics in public as this knowledge is not really helpful. What matters is that our incremental backup performance is optimized and it's faster than most of the competitors on the market.
Please clarify why you want to find out such deep details?
The limitations around XFS file system are only partially related here - the problem there is in lack of implementation for full support of XFS file system (we plan to implement it in future: internal RM-757 ID for reference).
Thank you.
Vasily, I understand that the implementation details are not for the public, but I want to understand the architecture of the solution, and the possible implications. To get to know all block level changes, I guess that the agent would need to hook in at kernel level, and write a list of changed blocks of its own? I imagine that incurs some overhead, and also need some free space for registering. Also, will each type of I/O be noticed?
Just want to be sure that this is a rock solid solution to backup incrementally.
Hi Tom,
Here's some info which I've found and which can be shared: there is volume_tracker.sys Acronis kernel driver which tracks the regions of the sectors starting from 1st volume snapshot triggered after the driver is installed. The ranges of the changed sectors are stored in system memory (the actual changed data is not stored there of course) because each system reboot will make the CBT information invalid (due to volume changes which cannot be tracked) -> therefore these ranges can be discarded upon reboot -> the changes are not stored on the disk. The overhead here is minimum since only ranges of the sectors are stored (for example "sector 0-1000"). The reboot cases are handled during incremental backup by reading the map of allocated sectors from the file system returned from SnapAPI -> that's where CBT for physical volumes cannot be applied, except for case when Microsoft VSS snapshot is used (default choice) - described below.
In case Microsoft VSS snapshot is used, we rely on tracking information provided by the Microsoft volsnap.sys driver which is stored on the disk: Microsoft stores the actual data changes between 2 VSS snapshots in "System Volume Information" folder -> so it persists through reboots.
This approach allows proper handling of cases when there is a huge DB file on the volume, which is changed only slightly between the backups and therefore it should not be backed up entirely (for example a 100GB file will be marked as changed, but we'll backup only the actual changed sectors in it, thus significantly reducing the incremental backup time).
Thank you.
Vasily, thanks. That was exacly the information i wished to have.
Hi Vasily. Has there been any update on supporting file exclusions for the XFS file system or that RM-757 issue? This is somewhat of a deal-breaker for us as we don't need to backup the whole system (only want to backup the data/directories we care about).
Vasily Semyonov wrote:Hi Tom,
The technology of blocks tracking during incremental backup is 8y old and is very low level. We typically do not share these deep specifics in public as this knowledge is not really helpful. What matters is that our incremental backup performance is optimized and it's faster than most of the competitors on the market.
Please clarify why you want to find out such deep details?
The limitations around XFS file system are only partially related here - the problem there is in lack of implementation for full support of XFS file system (we plan to implement it in future: internal RM-757 ID for reference).
Thank you.
Paul C wrote:Hi Vasily Semyonov. Has there been any update on supporting file exclusions for the XFS file system or that RM-757 issue? This is somewhat of a deal-breaker for us as we need to backup the whole system rather than just the data/directories we care about.
Vasily Semyonov wrote:Hi Tom,
The technology of blocks tracking during incremental backup is 8y old and is very low level. We typically do not share these deep specifics in public as this knowledge is not really helpful. What matters is that our incremental backup performance is optimized and it's faster than most of the competitors on the market.
Please clarify why you want to find out such deep details?
The limitations around XFS file system are only partially related here - the problem there is in lack of implementation for full support of XFS file system (we plan to implement it in future: internal RM-757 ID for reference).
Thank you.
Hello again. No reply was received, so I suppose there hasn't been any progress made on supporting file exclusions for the XFS file system. Is that right?
Paul C wrote:Hello again. No reply was received, so I suppose there hasn't been any progress made on supporting file exclusions for the XFS file system. Is that right?
Hi Paul,
I'm afraid the request is still in backlog.