Registered users
Linkedin Twitter Google+
Close

In order to improve user's experience and to enable some functionalities by tracking the user accross the website, this website uses its own cookies and from third parties, like Google Analytics and other similar activity tracking software. Read the Privacy Policy
33HOPS, IT Consultants Download XSIBackup
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 930 98 66Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info

©XSIBackup Rotating Replicas

Different ways to rotate replicas

(*) Do not forget to start at Rotation documentation in the ©XSIBackup-DC manual.


Even though we have created a deduplication engine that allows to compress VM data up to 99% with a proprietary FS XSIFS that allows to recover any file in any of the unlimited restore points of a repo, we have detected that some users tend to accumulate sets of replicas instead of using the advantages of deduplication plus compression.

It all makes sense, as the replicas are ready to use and are somewhat simpler to understand from a conceptual point of view, thus they are the favourite of some power users or sys admins who just want to have a quick recovery method that avoids restoring from a repository.

We conceived ©XSIBackup-DC pointing high, still, in the end many of our users are not big enterprises willing to archive thousands of different restore points of their servers in dedicated backup servers, but smaller consultants or SMEs that just want to keep a limited set of ready to use copies.


You should learn to use backup sets, still we acknowledge the usefulness of replica sets.

When it comes to replicate data, the size of the VM is the key. Should the VM be 'big' (we'll leave the relativity of the term to your understanding and scenario) replicating the whole data every time may not be desirable or even possible.

With the introduction of our CBT implementation, keeping a set of replicas has now become a more sense making approach, as once you have some replica in place, transferring the differential blocks is a matter of seconds.

In this post we will cover two ways to keep sets of replicas, although one of them is obviously the most advanced and should grab your attention over the other.



Rotate replica sets

Rotating a timestamped set of replicas

This is a very basic approach, it consists in storing your replicas in a timestamped folder and then rotating them based on number of replica sets, date, or size of the target folder.

This technique is easy to implement and simple to understand. It only has one drawback: as the timestamped folder will always be different, the whole VM will be copied every time.

This can be convenient in case of small VMs (up to 100GB) stored in fast servers, but you will soon hit reality if you want to apply it to multiterabyte VM sets.

Example:

./xsibackup --replica "VMs(WINSRV2019)" "root@192.168.33.200:22:/volume1/backup/replicas/$(date +%Y%m%d%H%M%S)" --rotate=7


Still, the results are quite convenient, as every VM in any target dir is a replica ready to be used.

Rotating a circular set of replicas with our without CBT (recommended)

This is a much more advanced technique that consists in making the target folder traverse a fixed set of folders. We can easily achieve that by using the MOD operator per instance.

./xsibackup --replica=cbt "VMs(WINSRV2019)" "root@192.168.33.200:22:/volume1/backup/replicas/$(( $(date +%j) % 5 ))"


The date command $(date +%j) returns the Julian day (ordinal number for the day in the current year), then we obtain the modulus for the number of sets we want to keep (5 in the example). This way the target folder will subsequently be:

/volume1/backup/replicas/1
/volume1/backup/replicas/2
/volume1/backup/replicas/3
/volume1/backup/replicas/4
/volume1/backup/replicas/5


Every newly created folder will take a full VM transfer, you can also just clone them in the target server if that is more convenient. If you don't activate the CBT feature, like in the case of a Pro version, the whole -flat.vmdk files will be traversed and only the changed blocks will be sent to the target folder.

If you can afford to buy a full ©XSIBackup-DC version, you can activate CBT as in the example. This will cause the replication process to just send the changed blocks. Our CBT implementation allows to keep track of multiple targets at the same time, thus you will just be sending the changed blocks to each of the target folders and saving a vast amount of time in case you are replicating big VMs.

Note how we have omitted the --rotate argument in the last example, as the rotation is implicit to the programmatic definition of the target folder.

This page was last modified on 2021-07-08



Website Map
Resources & help
33HOPS Forum
Index of Docs

©33HOPS site relies on the following technologies and partners:
SSL Protocol PayPal Payment Gateway Stripe Payment Gateway

©33HOPS Sistemas de Información y Redes, S.L. | VAT No: ESB83583716 | Avda. Castilla la Mancha, 95, local posterior, 28701 San Sebastián e los Reyes (Madrid) Spain



Fill in to download
The download link will be sent to your e-mail.
Name
Lastname
E-mail


            Read our Privacy Policy

(*) DC & Pro users, please login to your user area to download