Some real life figures and examples on ©XSITools

Please note that this post is relative to old deprecated software ©XSIBackup-Classic. Some facts herein contained may still be applicable to more recent versions though.

For new instalations please use new ©XSIBackup which is far more advanced than ©XSIBackup-Classic.

Below you can see one of our ©XSITools backup repositories. Here we keep a set of 5 VMs which sum up 214 GB of real data on 346 GB thin disks.

We are using a 50MB block size combined with LZOP compression, hosting 26675 blocks at an approximate compression rate of 49%, which yields 674 GB of real data on disk.

Desc: XSITools Repo v 1.0.0
Bsiz: 52428800
Bcnt: 26775
Comp: 1

The expanded backup set would use 7.2 TB of real data on 11.7 TB of thin disks. So we are achieving a compression ratio of 91% with 34 individual restore points for every single Virtual Machine.

-rw-r--r-- 1 root root 63 May 5 06:56 .xsitools
drwxr-xr-x 1 root root 1120 Mar 28 06:24 20190328051714
drwxr-xr-x 1 root root 1120 Mar 29 05:33 20190329042041
drwxr-xr-x 1 root root 1120 Mar 30 06:37 20190330053236
drwxr-xr-x 1 root root 1120 Mar 31 05:35 20190331042220
drwxr-xr-x 1 root root 1120 Apr 1 06:38 20190401052643
drwxr-xr-x 1 root root 1120 Apr 2 05:26 20190402041658
drwxr-xr-x 1 root root 1120 Apr 4 05:30 20190404041939
drwxr-xr-x 1 root root 1120 Apr 5 06:31 20190405052443
drwxr-xr-x 1 root root 1120 Apr 6 05:17 20190406041340
drwxr-xr-x 1 root root 1120 Apr 7 06:45 20190407053057
drwxr-xr-x 1 root root 1120 Apr 8 05:28 20190408042323
drwxr-xr-x 1 root root 1120 Apr 9 06:31 20190409052448
drwxr-xr-x 1 root root 1120 Apr 10 05:43 20190410042736
drwxr-xr-x 1 root root 1120 Apr 11 06:39 20190411052836
drwxr-xr-x 1 root root 1120 Apr 12 05:25 20190412041612
drwxr-xr-x 1 root root 1120 Apr 13 06:31 20190413052346
drwxr-xr-x 1 root root 1120 Apr 14 05:30 20190414042055
drwxr-xr-x 1 root root 1120 Apr 15 06:40 20190415052906
drwxr-xr-x 1 root root 1120 Apr 16 05:24 20190416041603
drwxr-xr-x 1 root root 1120 Apr 17 06:38 20190417052438
drwxr-xr-x 1 root root 1120 Apr 18 05:21 20190418041506
drwxr-xr-x 1 root root 1120 Apr 19 06:35 20190419052439
drwxr-xr-x 1 root root 1120 Apr 20 05:23 20190420041640
drwxr-xr-x 1 root root 1120 Apr 21 05:12 20190421041945
drwxr-xr-x 1 root root 1120 Apr 21 11:10 20190421102704
drwxr-xr-x 1 root root 420 Apr 21 11:56 20190421115520
drwxr-xr-x 1 root root 1120 Apr 21 15:19 20190421142255
drwxr-xr-x 1 root root 1120 Apr 29 08:36 20190429071525
drwxr-xr-x 1 root root 1120 Apr 30 05:25 20190430041755
drwxr-xr-x 1 root root 1120 May 1 05:26 20190501041836
drwxr-xr-x 1 root root 1120 May 2 05:23 20190502041755
drwxr-xr-x 1 root root 1120 May 3 05:25 20190503041706
drwxr-xr-x 1 root root 1120 May 4 05:24 20190504041907
drwxr-xr-x 1 root root 1120 May 5 06:58 20190505054651
drwxr-xr-x 1 root root 2520 Jan 15 04:52 data

drwxr-xr-x 1 root root 1120 Mar 28 06:24 .
drwxr-xr-x 1 root root 5320 May 5 06:56 ..
-rwx------ 1 root root 26597 Mar 28 06:24 1553754245-192.168.3.81-config.tgz
drwxr-xr-x 1 root root 1960 Mar 28 05:54 WIN-CRM
drwxr-xr-x 1 root root 2800 Mar 28 06:15 LIN-CENT53
drwxr-xr-x 1 root root 3640 Mar 28 06:01 LIN-LCENT64
drwxr-xr-x 1 root root 2380 Mar 28 06:07 W702-FILE
drwxr-xr-x 1 root root 3640 Mar 28 05:40 WDES01-FILE

The criticism from anybody sitting on the established paradigm would be to say: "50M is a huge block size, you aren't going to achieve any benefit from de-duplicating on that size, and: what about alignment?, what if some chunk of data moves in regards to the start offset?"

The thing is that the proposed scenario has some particular characteristics: we are backing up virtual disks, which correspond day by day to the same set of Virtual Machines, thus the data in the disks remains mostly aligned from one backup cycle to the next. May some block move in the disk, we'll assume it as part of the game.

The results are well above 90% compression ratio as data grows over a 1 month period. What could we achieve if we used some smaller size deduplication software, maybe 96%?. Now the question is:

Are you willing to sacrifice some 5-6% compression efficiency if in return you get a more fluid type of backup that does not clog your server's CPU and RAM as the backup is unfolding?

If your answer to the above question is yes, you came to the right place.

Given that all backup operations are performed from the ESXi shell, partially using a single core with a minimum amount of RAM and at more than extremely decent speeds, you could say that ©XSIBackup-Pro is your best bet if you are ready to make the job in the most efficient way.

Of course, you can always use multi-gigabyte software, depending on a number of third party commercial programs that perform the same task with worse figures.

If you have plenty of spare time and don't care much about your data, there's always somebody offering you a way to cross the river to get water.

Daniel J. García Fidalgo
33HOPS