VBR – Mac Backup

Veeam Backup & Replication (VBR) version 11 has a new feature and Mac users will fall in love with it.

It is now available for the backup and restores of your MACOS files.

It supports the last Operating Systems starting from High-Sierra (Big Sur 11.X.X / Catalina 10.15.X / Mojave 10.14.X / High Sierra 10.13.6).

Note 1: The Veeam Agent for Mac (VAM) version 1 supports the M1 processor via Rosetta.

Note 2: The VAM supports consistent data backup with snapshots for the APFS file system.

In the other file systems, the backup is created via a snapshot-less approach.

Note 3: At the moment it’s possible to perform the backup of user data (with a custom scope too). The image of the entire machine and a Bare Metal Restore are not available yet.

The configuration steps are quite easy as shown in the official guide:

To recap, the procedure consists of:

  1. From the VBR console create a resource group using a flexible scope
  2. Copy the files generated from VBR to the MAC to protect
  3. Install the package to your machine and import the created configuration. (It allows the communication between VBR and the Mac)
  4. From the VBR console creating the backup policy and apply it

The following video shows how it works in a managed VBR architecture.

Take care and see you soon.

Modern Applications – Episod 2: Ports & Networking

As written in the last article a container can manage more images.

Picture 1 shows an example of three different workloads running in a single container.

Picture 1

It’s possible to work with different versions of the same image also.

For example, MySQL has several images that can be installed and run to the same container.

Note 1: Nowadays MySQL available images are:

  • 8.0.25, 8.0, 8, latest
  • 5.7.34, 5.7, 5
  • 5.6.51, 5.6

Picture 2 shows a container where three different images run with two kinds of version applications.

Picture 2

Let’s digress slightly talking about how a service is built.

Most of the time it is made by grouping applications that means grouping several types of images.

The question is: How do images talk to each other?

The answer is quite easy. They talk through the networks, where IP addresses and ports are in charge of the communication to and from the applications (picture 3).

Picture 3

There is just a simple rule to remember when a container network architecture is deployed.

As shown in picture 4, if the ports used by a running image can be the same for different applications (in example 161616), the port assigned to the back-end server must be always different (4000,40001,4002).

Note 2: The port numbers are just an example also because the port with the higher number is 216 = 65535.

Picture 4

Wrap-up: The binding network architecture is completely allowed but the host back-end port can’t expose the same port number to more than one service.

Let’s go deeper into networking in the Container environment:

The network’s topology is defined by the used drivers.

They can be:

1. Host

When the container comes up it attaches its ports to the host network directly.

In this way, it shares the TCP/IP stack and the Host NameSpace.

The segregation is guaranteed by Docker technology (Picture 5)

Picture 5

2. Bridge

This is the default network mode.

It creates an isolated bridge network where the containers run inside a range of IP addresses.

In the previous scenario, the containers can talk to each other but no connection is allowed from outside.

To allow communication with external service in Docker, it’s necessary to start docker with the -p option.

docker run -pserverport:containerport nameservice (ie: docker run -p2400:2451 mysql)

port 2400 is now working with 2451

From a security point of view, it is amazing. You can monitor and select which ports are going to be used for a service (Picture 6)

Picture 6

3. Overlay

If the previous technologies are single-host networking topology, the Overlay allows communication among the container hosted in different hosts.

This scenario requires cluster intelligence to manage the traffic and guarantee segregation. It could be Swarm or Kubernetes (picture 7)

The technology core that allows it is vxlan that creates a tunnel on top of the underlay network and it is part of the operating system

The traffic is encrypted (AES) with a rotating password.

When a service is exposed (-p option wrote before), all traffic is automatically routed, nevermind where the service is running

More interesting details: each container has two IP addresses: the first one insists on the overlay network and is used by the containers to talk to each other (internal). The second address is for vxlan and allows the traffic to outside.

Picture 7

4. Null (Black box)

No network connection

5. MacVLan

It’s possible to implement a MacVLan through a driver. The scope is giving to the network container the behaviour of a traditional network. It’s necessary that the network accepts the promiscuous mode.

That’s all for now. Take care and see you soon.

Thanks -Grazie – Merci – Gracias

Thank you (different languages): Amazon.it: Appstore per Android

Dopo 14 mesi di attività a supporto del bridge online e con il ritorno alle normali attività di gioco dei circoli, da lunedì 17 maggio il sito non ospiterà con regolarità i servizi di prenotazione e classifica dei tornei online.

Ringrazio tutti coloro che hanno collaborato e reso possibile continuare a praticare il nostro gioco di carte preferito, durante uno dei momenti più tristi e sfidanti della nostra vita.

Arrivederci al tavolo 🙂



After 14 months of activities in support of online bridge and with the return to face to face activities of the clubs, from Monday 17th May the site will not regularly host the booking and ranking services of online tournaments.

I thank all those who collaborated and made it possible to continue practicing our favorite card game, during one of the saddest and most challenging moments of our life.

See you at the table 🙂