Installation Method

Installation

Configuration

• Manage Delivery Controllers

• Configure Unified Experience

• Manage Authentication Methods

• Manage Receiver for Web Sites

• Configure Remote Access Settings

• Configure XenApp Services Support

• Configure Store Settings

• Export Provisioning File

• Manage NetScaler Gateways / Manage Beacons

Fault Tolerant Citrix StoreFront configuration

Summary

The Best All-Around Option: Pushbullet

• SMS from a real keyboard: Send SMS directly from your computer without touching your phone.
• Mirror notifications on your computer: Never miss another notification—Pushbullet will send all notificationss from your phone to your PC.
• Send links directly to your phone: Skip emailing links to yourself, just push it directly to the phone.

The Most Robust Option: AirDroid

• Manage calls and SMS: No need to grab your phone to respond to a message, just do it from the computer.
• Mirror notifications: See all your phone’s notifications right on the desktop.
• Send and receive files: Not only can you send files to your phone with AirDroid, but you can also pull files from it. It’s brilliant.
• Edit contacts: Manage contacts from the comfort of a keyboard and mouse.
• Manage music and videos: No need to plug up to manage music.
• Set ringtones: Change your tones without ever touching the phone.
• Clipboard share: Copy on the computer, paste on the phone.
• Remote access the Camera: You can see both cameras on your computer screen. That’s neat.

The Simplest Option: Portal

 

Vulnerable Servers and Applications

• Use the HTTP_PROXY environmental variable to configure proxy connections: Either in the application code itself or any libraries that are used leverages. This is a fairly standard method of configuring proxy servers using the environment.
• Make requests to backend services using HTTP: Because the name collision is specific to the HTTP_ prefix, only requests made by the application using HTTP will be affected. Requests using HTTPS or any other protocols are not vulnerable.
• Operate in a CGI or CGI-like environment: Deployments where client headers are translated into HTTP_ prefixed environmental variables are vulnerable. Any compliant implementation of CGI or related protocols like FastCGI will do this.

Language Specific Information

How to Defeat the Vulnerability

• Applications or libraries can ignore the HTTP_PROXY variable when they are in a CGI environment.
• Applications or libraries can use a different environmental variable to configure proxy connections
• Web servers or proxies can unset the Proxy header received in client requests

Removing the HTTP Proxy Header with Apache

Ubuntu and Debian Servers

sudo a2enmod headers 

sudo nano /etc/apache2/apache2.conf 

. . .
RequestHeader unset Proxy early

sudo apache2ctl configtest 

sudo service apache2 restart 

CentOS and Fedora Servers

sudo nano /etc/httpd/conf/httpd.conf 

. . .
RequestHeader unset Proxy early

sudo apachectl configtest 

sudo service httpd restart 

Removing the HTTP Proxy Header with Nginx

Ubuntu and Debian Servers

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf 

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params 

. . .
    location ~ \.php$ {
        . . .
fastcgi_param HTTP_PROXY "";
        . . .
    }
}

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params 

. . .
    location /application/ {
        . . .
        proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
        . . .
    }
}

sudo nginx -t 

sudo service nginx restart 

CentOS and Fedora Servers

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf 

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params 

. . .
    location ~ \.php$ {
        . . .
fastcgi_param HTTP_PROXY "";
        . . .
    }
}

grep -r "proxy_pass" /etc/nginx 

Output

/etc/nginx/nginx.conf.default:        #    proxy_pass   http://127.0.0.1;

. . .
    location /application/ {
        . . .
        proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
        . . .
    }
}

sudo nginx -t 

sudo service nginx restart 

Removing the HTTP Proxy Header with HAProxy

sudo nano /etc/haproxy/haproxy.cfg 

frontend www
http-request del-header Proxy
    . . .

backend web-backend
http-request del-header Proxy
    . . .

listen appname 0.0.0.0:80
http-request del-header Proxy
    . . .

sudo haproxy -c -f /etc/haproxy/haproxy.cfg 

sudo service haproxy restart 

Conclusion

Prerequisites

• You have a Node running Ubuntu 14.04
• You are logged in to your server as a non-root user with administrative privileges. See the tutorial Initial server setup guide for Ubuntu 14.04 to set this up.
• You have installed the official Java 8 JRE from Oracle.

Installing and Running BaasBox

wget http://www.baasbox.com/download/baasbox-stable.zip 

sudo apt-get install unzip 

unzip baasbox-stable.zip 

cd baasbox-X.Y.Z

chmod +x ./start 

./start 

Output

2016-06-28 14:32:14,554 - [info] - BaasBox is Ready.
2016-06-28 14:32:14,558 - [info] - Application started (Prod)
2016-06-28 14:32:14,733 - [info] - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
2016-06-28 14:32:15,261 - [info] - Session Cleaner: started
2016-06-28 14:32:15,263 - [info] - Session cleaner: tokens: 0 - removed: 0
2016-06-28 14:32:15,263 - [info] - Session cleaner: finished

• http://localhost:9000 and http://127.0.0.1:9000 from the server that it is installed on (or via an SSH tunnel)
• http://your_internal_server_ip:9000 from the internal network that your server is on (if it is on an internal network)
• http://your_ip_address:9000 from the internet if your_ip_address is a publicly accessible IP address.

./start -Dhttp.port=target_port -Dhttp.address=target_interface

Creating an Application with BaasBox

• Allow users to sign up
• Allow users to log in
• Allow users to create multiple todo lists
• Allow users to retrieve their own todo lists
• Allow users to modify their todo lists
• Allow users to delete their todo lists
• Allow users to share their todo list with another user

• We will create two users with usernames user1 and user2
• The passwords of these users will be referred to as user1_password and user2_password
• The session IDs of these users will be referred to as user1_session_id and user2_session_id.

• Default Username: admin
• Default Password: admin
• Default App Code: 1234567890

Creating Users

• administrator - this role has complete, unrestricted access
• backoffice - this role grants access to the content created by registered users
• registered - this is the default role foe newly registered users

Creating a Collection

Using the REST API

Creating a User Using the REST API

curl http://your_ip_address:9000/user \ 

    -d '{"username" : "username", "password" : "password"}' \ 

    -H Content-type:application/json \ 

    -H X-BAASBOX-APPCODE:baasbox_appcode

curl http://your_ip_address:9000/user \ 

    -d '{"username" : "user2", "password" : "user2_password"}' \ 

    -H Content-type:application/json \ 

    -H X-BAASBOX-APPCODE:1234567890 

Output

{
"result": "ok",
"data": {
"user": {
"name": "user2",
"status": "ACTIVE",
"roles": [
        {
"name": "registered",
"isrole": true
        }
      ]
    },
"id": "a4353548-501a-4c55-8acd-989590b2393c",
"visibleByAnonymousUsers": {},
"visibleByTheUser": {},
"visibleByFriends": {},
"visibleByRegisteredUsers": {
"_social": {}
    },
"signUpDate": "2016-04-05T13:12:17.452-0400",
"generated_username": false,
"X-BB-SESSION": "992330a3-4e2c-450c-8d83-8eaf2903188b"
  },
"http_code": 201
}

Logging the User In Using the REST API

curl http://your_ip_address:9000/login \ 

    -d "username=username" \ 

    -d "password=password" \ 

    -d "appcode=baasbox_appcode"

curl http://your_ip_address:9000/login \ 

    -d "username=user1" \ 

    -d "password=user1_password" \ 

    -d "appcode=1234567890"

Output

{
"result": "ok",
"data": {
"user": {
"name": "user1",
"status": "ACTIVE",
"roles": [
        {
"name": "registered",
"isrole": true
        }
      ]
    },
"id": "84191e4c-2471-48a7-98bb-ecdaf118285c",
"visibleByAnonymousUsers": {},
"visibleByTheUser": {},
"visibleByFriends": {},
"visibleByRegisteredUsers": {}
    },
"signUpDate": "2016-04-05T13:06:35.750-0400",
"generated_username": false,
"X-BB-SESSION": "74400b4b-d16c-45a2-ada3-1cd51cc202bb"
  },
"http_code": 200
}

Creating a Document Using the REST API

Sample Document Contents

{
"list_name": "Task List Name",
"tasks": [
    {
"task": "Task Details",
"done": false
    },
    {
"task": "Task Details",
"done": false
    }
  ]
}

curl -X POST http://your_ip_address:9000/document/collection_name \ 

     -d 'json_formatted_document' \ 

     -H Content-type:application/json \ 

     -H X-BB-SESSION:session_id

Document Contents

{
"list_name": "User 1 - List 1",
"tasks": [
    {
"task": "User1 List1 task 1",
"done": false
    },
    {
"task": "User1 List1 task 2",
"done": false
    }
  ]
}

curl -X POST http://your_ip_address:9000/document/todos \ 

     -d '{"list_name":"User 1 - List 1","tasks":[{"task":"User1 List1 task 1","done":false},{"task":"User1 List1 task 2","done":false}]}' \ 

     -H Content-type:application/json \ 

     -H X-BB-SESSION:user1_session_id

Output

{
"result": "ok",
"data": {
"@rid": "#24:1",
"@version": 2,
"@class": "todos",
"list_name": "User 1 - List 1",
"tasks": [
      {
"task": "User1 List1 task 1",
"done": false
      },
      {
"task": "User1 List1 task 2",
"done": false
      }
    ],
"id": "c83309e7-cbbd-49c8-a76b-9e8fadc72d6f",
"_creation_date": "2016-04-05T20:34:30.132-0400",
"_author": "user1"
  },
"http_code": 200
}

• Create another list for user1
• Create two lists for user2

• user1list1id
• user1list2id
• user2list1id
• user2list2id

Retrieving a Single Document Using the REST API

curl http://your_ip_address:9000/document/collection_name/document_id \ 

     -H X-BB-SESSION:session_id

curl http://your_ip_address:9000/document/todos/user1_list1_id \ 

     -H X-BB-SESSION:user1_session_id

Output

{
"result": "ok",
"data": {
"@rid": "#24:1",
"@version": 2,
"@class": "todos",
"list_name": "User 1 - List 1",
"tasks": [
      {
"task": "User1 List1 task 1",
"done": false
      },
      {
"task": "User1 List1 task 2",
"done": false
      }
    ],
"id": "c83309e7-cbbd-49c8-a76b-9e8fadc72d6f",
"_creation_date": "2016-04-05T20:34:30.132-0400",
"_author": "user1"
  },
"http_code": 200
}

curl -X POST http://your_ip_address:9000/document/todos/user1_list1_id \ 

     -H X-BB-SESSION:user2_session_id

Output

{
"result": "error",
"message": "c83309e7-cbbd-49c8-a76b-9e8fadc72d6f not found",
"resource": "\/document\/todos\/c83309e7-cbbd-49c8-a76b-9e8fadc72d6f",
"method": "GET",
"request_header": {
"Accept": [
"*\/*"
    ],
"Host": [
"localhost:9000"
    ],
"User-Agent": [
"curl\/7.35.0"
    ],
"X-BB-SESSION": [
"8f5a2e48-0f42-4478-bd1b-d28699158c4b"
    ]
  },
"API_version": "0.9.5",
"http_code": 404
}

Retrieving All Documents Using the REST API

curl http://your_ip_address:9000/document/collection_name \ 

     -H X-BB-SESSION:session_id

curl http://your_ip_address:9000/document/todos \ 

     -H X-BB-SESSION:user1_session_id

Output

{
"result": "ok",
"data": [
    {
"@rid": "#24:1",
"@version": 2,
"@class": "todos",
"list_name": "User 1 - List 1",
"tasks": [
        {
"task": "User1 List1 task 1",
"done": false
        },
        {
"task": "User1 List1 task 2",
"done": false
        }
      ],
"id": "c83309e7-cbbd-49c8-a76b-9e8fadc72d6f",
"_creation_date": "2016-04-05T20:34:30.132-0400",
"_author": "user1"
    },
    {
"@rid": "#24:2",
"@version": 1,
"@class": "todos",
"list_name": "User 1 - List 2",
"tasks": [
        {
"task": "User1 List2 task 1",
"done": false
        },
        {
"task": "User1 List2 task 2",
"done": false
        }
      ],
"id": "7c99c877-d269-4281-8a22-ef72175085f4",
"_creation_date": "2016-04-05T20:46:14.338-0400",
"_author": "user1"
    }
  ],
"http_code": 200
}

Updating a Document Using the REST API

curl -X PUT http://your_ip_address:9000/document/collection_name/document_id \ 

     -d 'new_json_formatted_document' \ 

     -H Content-type:application/json \ 

     -H X-BB-SESSION:session_id

• Only the document owner can modify a document
• An update does not merge the old and the new documents. It replaces the old document with the new one. This means that if the update command includes a documents with some fields missing from the original version, these fields will be lost.

New Document Contents

{
"list_name": "User 1 - List 1 Updated",
"tasks": [
    {
"task": "New User1 List1 task 1",
"done": false
    }
  ]
}

curl -X PUT http://your_ip_address:9000/document/todos/user1_list1_id \ 

     -d '{"list_name":"User 1 - List 1 Updated","tasks":[{"task":"New User1 List1 task 1","done":false}]}' \ 

     -H Content-type:application/json \ 

     -H X-BB-SESSION:user1_session_id

Output

{
"result": "ok",
"data": {
"@rid": "#24:1",
"@version": 4,
"@class": "todos",
"list_name": "User 1 - List 1 Updated",
"tasks": [
      {
"task": "New User1 List1 task 1",
"done": false
      }
    ],
"id": "c83309e7-cbbd-49c8-a76b-9e8fadc72d6f",
"_creation_date": "2016-04-05T20:34:30.132-0400",
"_author": "user1"
  },
"http_code": 200
}

Deleting a Document Using the REST API

curl -X DELETE http://your_ip_address:9000/document/collection_name/document_id \ 

     -H X-BB-SESSION:session_id

curl -X DELETE http://your_ip_address:9000/document/todos/user1_list1_id \ 

     -H X-BB-SESSION:user1_session_id

Output

{"result":"ok","data":"","http_code":200}

Granting Access to Another User Using the REST API

curl -X PUT http://your_ip_address:9000/document/collection_name/document_id/access_type/user/username \ 

     -H X-BB-SESSION:session_id

• read
• update
• delete
• all

curl -X PUT http://your_ip_address:9000/document/todos/user1_list1_id/read/user/user2 \ 

     -H X-BB-SESSION:user1_session_id

Output

{"result":"ok","data":"","http_code":200}

Using Supervisor to Keep the Application Running

sudo apt-get install supervisor 

sudo nano /etc/supervisor/conf.d/baasbox.conf 

[program:Baasbox]
directory = /home/sammy/baasbox-0.9.5
command = /home/sammy/baasbox-0.9.5/start
autostart = true
autorestart = true
startsecs = 5
user = sammy
stdout_logfile = /var/log/supervisor/baasbox.log

supervisorctl reread 

supervisorctl update 

Conclusion

Prerequisites

• Three Ubuntu 16.04 Nodes with a minimum of 1 GB RAM and private networking enabled
• Non-root user with sudo privileges for each Node (Initial Server Setup with Ubuntu 16.04 explains how to set this up.)

Downloading and Installing MySQL Cluster

• Cluster manager software
• Data node manager software
• MySQL 5.6 server and client binaries

sudo apt-get install libaio1 

sudo dpkg -i mysql-cluster-gpl-7.4.11-debian7-x86_64.deb 

Configuring and Starting the Cluster Manager

sudo mkdir /var/lib/mysql-cluster  

sudo nano /var/lib/mysql-cluster/config.ini 

[ndb_mgmd]
# Management process options:
hostname=manager.mysql.cluster  # Hostname of the manager
datadir=/var/lib/mysql-cluster  # Directory for the log files

[ndbd]
hostname=node1.mysql.cluster    # Hostname of the first data node
datadir=/usr/local/mysql/data   # Remote directory for the data files

[ndbd]
hostname=node2.mysql.cluster    # Hostname of the second data node
datadir=/usr/local/mysql/data   # Remote directory for the data files

[mysqld]
# SQL node options:
hostname=manager.mysql.cluster  # In our case the MySQL server/client 

is on the same Node as the cluster manager

sudo /opt/mysql/server-5.6/bin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini 

Output of ndb_mgmd

MySQL Cluster Management Server mysql-5.6.29 ndb-7.4.11

sudo systemctl enable rc-local.service 

sudo nano /etc/rc.local 

...
/opt/mysql/server-5.6/bin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini
exit 0

Configuring and Starting the Data Nodes

sudo nano /etc/my.cnf 

[mysql_cluster]
ndb-connectstring=manager.mysql.cluster

sudo mkdir -p /usr/local/mysql/data 

sudo /opt/mysql/server-5.6/bin/ndbd 

Output of ndbd

2016-05-11 16:12:23 [ndbd] INFO     -- Angel connected to 'manager.mysql.cluster:1186'
2016-05-11 16:12:23 [ndbd] INFO     -- Angel allocated nodeid: 2

sudo systemctl enable rc-local.service 

sudo nano /etc/rc.local 

...
/opt/mysql/server-5.6/bin/ndbd
exit 0

Configuring and Starting the MySQL Server and Client

sudo nano /etc/my.cnf 

[mysqld]
ndbcluster # run NDB storage engine
...

sudo groupadd mysql 

sudo useradd -r -g mysql -s /bin/false mysql 

sudo /opt/mysql/server-5.6/scripts/mysql_install_db --user=mysql 

sudo cp /opt/mysql/server-5.6/support-files/mysql.server /etc/init.d/mysqld 

sudo systemctl enable mysqld.service 

sudo systemctl start mysqld 

sudo ln -s /opt/mysql/server-5.6/bin/mysql /usr/bin/ 

mysql 

Output of ndb_mgmd

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.6.29-ndb-7.4.11-cluster-gpl MySQL Cluster Community Server (GPL)

Testing the Cluster

sudo /opt/mysql/server-5.6/bin/ndb_mgm 

Inside the ndb_mgm console

-- NDB Cluster -- Management Client --
ndb_mgm>

SHOW 

Output of ndb_mgm

Connected to Management Server at: manager.mysql.cluster:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=2    @10.135.27.42  (mysql-5.6.29 ndb-7.4.11, Nodegroup: 0, *)
id=3    @10.135.27.43  (mysql-5.6.29 ndb-7.4.11, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @10.135.27.51  (mysql-5.6.29 ndb-7.4.11)

[mysqld(API)]   1 node(s)
id=4    @10.135.27.51  (mysql-5.6.29 ndb-7.4.11)

2 STATUS 

Output of ndb_mgm

Node 2: started (mysql-5.6.29 ndb-7.4.11)

mysql -u root 

SHOW ENGINE NDB STATUS \G 

Output of mysql

*************************** 1. row ***************************
  Type: ndbcluster
  Name: connection
Status: cluster_node_id=4, connected_host=manager.mysql.cluster, 

connected_port=1186, number_of_data_nodes=2, number_of_ready_data_nodes=2, 

connect_count=0
...

Working with the NDB Engine

CREATE DATABASE cluster; 

USE cluster; 

CREATE TABLE cluster_test (name VARCHAR(20), value VARCHAR(20)) ENGINE=ndbcluster; 

INSERT INTO cluster_test (name,value) VALUES('some_name','some_value'); 

SELECT * FROM cluster_test; 

Conclusion

Download the Packages from Microsoft

• Ubuntu 16.04: Download the package ending in “16.04.1_amd64.deb”.
• Ubuntu 14.04: Download the package ending in “14.04.1_amd64.deb”.
• CentOS 7 and Red Hat Enterprise Linux 7: Download the package ending in “el7.centos.x86_64.rpm”.
• Mac: Download the package ending in “.pkg”.

How to Install PowerShell on Linux

sudo apt-get install libunwind8 libicu55
sudo dpkg -i /path/to/powershell.deb

sudo apt-get install libunwind8 libicu55
sudo dpkg -i ~/Downloads/powershell_6.0.0-alpha.9-1ubuntu1.16.04.1_amd64.deb

sudo apt-get install libunwind8 libicu52
sudo dpkg -i /path/to/powershell.deb

sudo yum install /path/to/powershell.rpm

How to Install PowerShell on a Mac

How to Launch PowerShell on Linux or Mac

General Overview

Python 2

Python 3

Python 2.7

Key Differences

Print

print"Sammy the Shark is my favorite sea creature"

print("Sammy the Shark is my favorite sea creature")

Division with Integers

5 / 2 = 2.5

a = 5 / 2
print a

Output

2

a = 5 / 2
print(a)

Output

2.5

b = 5 // 2
print(b)

Output

2

Unicode Support

Continued Development

Additional Points to Consider

Conclusion

Prerequisites

• Three Ubuntu 16.04 servers, each with a non-root user with sudo privileges and private networking, if it’s available to you.

Step 1 — Adding the MariaDB 10.1 Repositories to All Servers

• sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

• sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'

sudo apt-get update 

Step 2 — Installing MariaDB on All Servers

sudo apt-get install mariadb-server 

sudo apt-get install rsync 

Step 3 — Configuring the First Node

sudo nano /etc/mysql/conf.d/galera.cnf 

[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://first_ip,second_ip,third_ip"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"

• The first section modifies or re-asserts MariaDB/MySQL settings that will allow the cluster to function correctly. For example, Galera Cluster won’t work with MyISAM or similar non-transactional storage engines, and mysqld must not be bound to the IP address for localhost. You can learn about the settings in more detail on the Galera Cluster system configuration page.
• The "Galera Provider Configuration" section configures the MariaDB components that provide a WriteSet replication API. This means Galera in our case, since Galera is a wsrep (WriteSet Replication) provider. We specify the general parameters to configure the initial replication environment. This doesn't require any customization, but you can learn more about Galera configuration options.
• The "Galera Cluster Configuration" section defines the cluster, identifying the cluster members by IP address or resolvable domain name and creating a name for the cluster to ensure that members join the correct group. You can change the wsrep_cluster_name to something more meaningful than test_cluster or leave it as-is, but you must update wsrep_cluster_address with the addresses of your three servers. If your servers have private IP addresses, use them here.
• The "Galera Synchronization Configuration" section defines how the cluster will communicate and synchronize data between members. This is used only for the state transfer that happens when a node comes online. For our initial setup, we are using rsync, because it's commonly available and does what we need for now.
• The "Galera Node Configuration" section clarifies the IP address and the name of the current server. This is helpful when trying to diagnose problems in logs and for referencing each server in multiple ways. The wsrep_node_address must match the address of the machine you're on, but you can choose any name you want in order to help you identify the node in log files.

Step 4 — Configuring the Remaining Nodes

sudo nano /etc/mysql/conf.d/galera.cnf 

. . .
# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
. . .

Step 5 — Opening the Firewall on Every Server

sudo ufw status 

Output

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

• 3306 For MySQL client connections and State Snapshot Transfer that use the mysqldump method.
• 4567 For Galera Cluster replication traffic, multicast replication uses both UDP transport and TCP on this port.
• 4568 For Incremental State Transfer.
• 4444 For all other State Snapshot Transfer.

sudo ufw allow 3306,4567,4568,4444/tcp 

sudo ufw allow 4567/udp 

Step 6 — Starting the Cluster

Stop MariaDB on all Three Servers:

sudo systemctl stop mysql 

sudo systemctl status mysql 

Output

. . . 
Aug 19 02:55:15 galera-01 systemd[1]: Stopped MariaDB database server.

Bring up the First Node:

sudo galera_new_cluster 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

Output

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Bring up the Second Node:

sudo systemctl start mysql 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

Output

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

Bring up the Third Node:

sudo systemctl start mysql  

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

Output

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Step 7 — Configuring the Debian Maintenance User

Copy from the First Node:

sudo nano /etc/mysql/debian.cnf 

[client]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Update the Second Node:

sudo nano /etc/mysql/debian.cnf 

Update the Third Node:

sudo nano /etc/mysql/debian.cnf 

sudo cat /etc/mysql/debian.cnf 

mysql -u debian-sys-maint -p 

• Update mysql.user set password=PASSWORD('password_from_debian.cnf') where User='debian-sys-maint';

Step 8 — Testing Replication

Write to the First Node:

• mysql -u root -p -e 'CREATE DATABASE playground;
• CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id)); 
• INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

Read and Write on the Second Node:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Output

+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

• mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

Read and Write on the Third Node:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Output

+----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

• mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

Read on the First Node:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Output

+----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

Conclusion

How to add new storage locations for indexing on Windows 10

• Use the Windows key + X to open the Power User menu and select Control Panel.
• Change the view to Large Icons.

• Click on Indexing Options.

• Click Modify.

• Click Show all locations .
• On Indexed Locations, select the folders and drives you want to give Cortana permission to search.

• Quick Tip: If you have sensitive files (or videos), in this step, you can also exclude the locations you don't want Cortana to use to show search results.
• Getting Granular: If you want to index a folder, but you don't want a subfolder to be indexed, expand the folder and remove the checkmark for those files and folders inside it you don't want Cortana to consider during a search.

• Click the OK button to complete the task.

• Click Advanced.
• Click Rebuild.

• Click OK to confirm.

Wrapping things up

How to Associate Your Windows 10 License with a Microsoft Account

How to Activate Your Windows 10 License After a Hardware Change

Why You Can’t Just Use a Simple Product Key

You Can’t Move a Free Windows 10 License to Another PC

Split-Screen Mode

More Powerful Notifications

A Better Doze for Longer Battery Life

An Easier, More Customizable Quick Settings Menu

New Secret Features in the System UI Tuner

Data Saver, Call Blocking, and More

How to prevent Insider builds from installing on your Windows 10 PC

1. Change your Active Hours settings

1. Open Settings.
2. Click on Update & security.
3. Click on Windows Update.
4. Click the Change active hours link.
   
   
   
5. Set the Start time and End time to postpone the restart the maximum period of time (12 hours).
6. Click Save.
   
   

2. Change your Windows Insider Preference

1. Open Settings.
2. Click on Update & security.
3. Click on Windows Insider Program.
4. Lower your ring level to Slow or Release Preview (if available).
   
   

3. Remove the installation files from your computer

1. Use the Windows key + R keyboard shortcut to open the Run command.
2. Type cleanmgr and click OK to launch the Disk Cleanup tool.
3. Make sure you're selecting the drive C: and click OK.
4. Click the Clean up system files button.
   
   
5. Make sure you're selecting the drive C: and click OK.
6. Select the Temporary Windows installation files option.
7. Make sure to remove the checkmark for anything you don't want to delete.
8. Click OK.
   
   
9. Click Delete files.

How to get Nougat through the Android Beta program

1. Head to Android Beta programme portal on your Nexus phone or Pixel C tablet.
2. Sign into the Google account associated with that phone.
3. Scroll down to Your eligible devices.
4. Find the device you want to enrol in the Beta programme and tap Enrol device.
5. Follow the prompts to accept the over-the-air download.

How to get Nougat by flashing a factory image

Get the right tools to flash a factory image

1. Go to Android Studio webpage
2. Scroll to the bottom of the page.
3. Find command line tools for your platform — Windows, Mac, or Linux.
4. Extract the accompanying file (.exe, .zip, .tgz)

Enable developer settings and USB debugging

1. Go to your Nexus'Settings.
2. Scroll down to About Phone/Tablet.
3. Tap on the Build number seven times until the dialog box says you are now a developer.
4. Open Settings and you should find a new option called Developer options.
5. Click into the Developer options.
6. Make sure that the developer options are turned on and that USB debugging is checked on.
7. Check Enable OEM unlock.
8. Plug your Nexus device into your computer.
9. Tap OK on the dialog box asking you to Allow USB debugging while connected to the computer.

Unlocking your bootloader

1. Turn off your phone or tablet.
2. Hold down the power button and the volume down button.
3. On your computer, open Command Prompt (Windows) or Terminal (Mac). Navigate to folder with Platform tools.
4. On your computer, type: ./fastboot flashing unlock in a terminal or command prompt.
5. Press volume up button and the power button on your device to confirm bootloader unlock.
6. On your computer, type: ./fastboot reboot

Flashing the Android 7.0 factory image

1. Visit Nexus Factory Images page.
2. Scroll down to your phone and find the Android 7.0 image for your phone.
3. Once downloaded, extract the file in your Platform tools folder.
4. Put your phone into bootloader mode (see above) and plug it into your computer.
5. Open Command Prompt (Windows) or Terminal (Mac). Navigate to folder with Platform tools.
6. On the command line, type:./adb devices to ensure your phone is seen by your computer.
7. Type the flash-all command.
   On Windows, that will be flash-all.bat
   On Mac, that will be flash-all.sh

Learning about Nougat

Have you tried turning it off and on again?

Reset your router

Forget and re-learn

1. Launch Settings from your home screen, the Notification Shade, or the app drawer.
2. Tap Wi-Fi.
3. Tap the network you're connected to.
4. Tap Forget.
   
5. Tap the network again to reconnect to it.
6. Enter the password if there is one.
7. Tap Connect.
   

Is your software up to date?

1. Launch Settings from your home screen, the Notification Shade, or the app drawer.
2. Tap About device.
3. Tap Download updates manually. Your phone will then check for and download any updates.
4. Tap Later, Install overnight, or Install now to choose when you want the update installed.
   

Try another network

Get closer

Check your router settings

Make sure Wi-Fi is always on

1. Launch Settings from your home screen, the Notification Shade, or the app drawer.
2. Tap Wi-Fi.
3. Tap More in the top right corner of your screen.
   
4. Tap Advanced.
5. Tap Keep Wi-Fi on during sleep.
6. Tap Always.
   

Turn off Power Saving Mode

Change the encryption settings on your router

Get a new router!

If all else fails

Solution Architecture

Components

Backup Server

• Coordinates backup, replication, recovery verification and restore tasks
• Controls job scheduling and resource allocation
• Is used to set up and manage backup infrastructure components as well as specify global settings for the backup infrastructure
  In addition to its primary functions, a newly deployed backup server also performs the role of the default backup repository, storing backups locally.
  
  The backup server uses the following services and components:
  
  • Veeam Backup Service is a Windows service that coordinates all operations performed by Veeam Backup & Replication such as backup, replication, recovery verification and restore tasks. The Veeam Backup Service runs under the Local System account or account that has the Local Administrator permissions on the backup server.
  • Veeam Backup & Replication Console provides the application user interface and allows user access to the application's functionality.
  • Veeam Guest Catalog Service is a Windows service that manages guest OS file system indexing for VMs and replicates system index data files to enable search through guest OS files. Index data is stored in the Veeam Backup Catalog — a folder on the backup server. The Veeam Guest Catalog Service running on the backup server works in conjunction with search components installed on Veeam Backup Enterprise Manager and (optionally) a dedicated Microsoft Search Server.
  • Veeam Backup & Replication Configuration Database is used to store data about the backup infrastructure, jobs, sessions and so on. The database instance can be located on a SQL Server installed either locally (on the same machine where the backup server is running) or remotely.
  • Veeam Backup PowerShell Snap-In is an extension for Microsoft Windows PowerShell 2.0. Veeam Backup PowerShell adds a set of cmdlets to allow users to perform backup, replication and recovery tasks through the command-line interface of PowerShell or run custom scripts to fully automate operation of Veeam Backup & Replication.
  • Mount server is a component required for browsing the VM guest file system and restoring VM guest OS files and application items to the original location.

Backup & Replication Console

• Veeam Backup PowerShell Snap-In
• Veeam Explorer for Microsoft Active Directory
• Veeam Explorer for Microsoft Exchange
• Veeam Explorer for Oracle
• Veeam Explorer for Microsoft SQL
• Veeam Explorer for Microsoft SharePoint
• Mount server

• The remote console can be installed on a Microsoft Windows machine (physical or virtual).
• If you install the console remotely, you can deploy it outside NAT. However, the backup server must be behind NAT. The opposite type of deployment is not supported: if the backup server is deployed outside NAT and the remote console is deployed behind NAT, you will not be able to connect to the backup server.

• You cannot perform restore from the configuration backup via the remote console.
• The machines on which the remote console is installed are not added to the list of managed servers automatically. For this reason, you cannot perform some operations, for example, import backup files that reside on the remote console machine or assign roles of backup infrastructure components to this machine. To perform these operations, you must add the remote console machine as a managed server to Veeam Backup & Replication.

Off-Host Backup Proxy

• The role of an off-host backup proxy can be assigned only to a physical Microsoft Windows 2008 Server R2 machine with the Hyper-V role enabled, Windows Server 2012 machine with the Hyper-V role enabled or Windows Server 2012 R2 machine with the Hyper-V role enabled.

• The off-host backup proxy must have access to the shared storage where VMs to be backed up, replicated or copied are hosted.
• To create and manage volume shadow copies on the shared storage, you must install a VSS hardware provider that supports transportable shadow copies on the off-host proxy and the Hyper-V host. The VSS hardware provider is usually distributed as a part of client components supplied by the storage vendor.

• Veeam Installer Service is an auxiliary service that is installed and started on any Windows (or Hyper-V) server once it is added to the list of managed servers in the Veeam Backup & Replication console. This service analyzes the system, installs and upgrades necessary components and services.
• Veeam Transportis responsible for deploying and coordinating executable modules that act as "data movers" and perform main job activities on behalf of Veeam Backup & Replication, such as performing data deduplication, compression and so on.
• Veeam Hyper-V Integration Service is responsible for communicating with the VSS framework during backup, replication and other jobs, and performing recovery tasks. The service also deploys a driver that handles changed block tracking for Hyper-V.

Guest Interaction Proxy

• Application-aware processing
• Guest file system indexing
• Transaction logs processing

• The load on the backup server was high.
• If a connection between two sites was slow, the job performance decreased.
• If the backup server had no network connection to VMs, application-aware processing tasks were not accomplished for these VMs.

Important!

The guest interaction proxy deploys the runtime process only in Microsoft Windows VMs. In VMs with another guest OS, the runtime process is deployed by the backup server.

• It must be a Microsoft Windows machine (physical or virtual).
• You must add it to the Veeam Backup & Replication console as a managed server.
• It must have a LAN connection to the VM that will be backed up or replicated.

Note:

The guest interaction proxy functionality is available in the Enterprise and Enterprise Plus Editions of Veeam Backup & Replication.

1. A machine in the same network as the protected VM that does not perform the backup server role.
2. A machine in the same network as the protected VM that performs the backup server role.
3. A machine in another network that does not perform the backup server role.
4. A machine in another network that performs the backup server role.

 

Backup Repository

Simple Backup Repository

• Microsoft Windows server with local or directly attached storage. The storage can be a local disk, directly attached disk-based storage (such as a USB hard drive), or iSCSI/FC SAN LUN in case the server is connected into the SAN fabric.
  On a Windows repository, Veeam Backup & Replication deploys a local Veeam Data Mover Service (when you add a Windows-based server to the product console, Veeam Backup & Replication installs a set of components including the Veeam Data Mover Service on that server). When any job addresses the backup repository, the Veeam Data Mover Service on the backup repository establishes a connection with the source-side Veeam Data Mover Service on the backup proxy, enabling efficient data transfer over LAN or WAN.
• Linux server with local, directly attached storage or mounted NFS. The storage can be a local disk, directly attached disk-based storage (such as a USB hard drive), NFS share, or iSCSI/FC SAN LUN in case the server is connected into the SAN fabric.

• CIFS (SMB) share. SMB share cannot host Veeam Data Mover Services. For this reason, data to the SMB share is written from the gateway server. By default, this role performs an on-host or off-host backup proxy that is used by the job for data transport.

• Deduplicating storage appliance. Veeam Backup & Replication supports the following deduplicating storage appliances:

• EMC Data Domain

• ExaGrid
• HPE StoreOnce

Scale-Out Backup Repository

• Microsoft Windows backup repositories
• Linux backup repositories
• Shared folders
• Deduplicating storage appliances

• Backup jobs.
• Backup copy jobs. You can copy backups that reside on scale-out backup repositories and store backup copies on scale-out backup repositories.
• VeeamZIP tasks.

• The scale-out backup repository functionality is available only in Enterprise and Enterprise Plus editions of Veeam Backup & Replication.

• You cannot use the scale-out backup repository as a target for the following types of jobs:

• Configuration backup job
• Replication jobs
• Endpoint backup jobs

• You cannot add a backup repository as an extent to the scale-out backup repository if any job of unsupported type is targeted at this backup repository or if the backup repository contains data produced by jobs of unsupported types (for example, replica metadata). To add such backup repository as an extent, you must first target unsupported jobs to another backup repository and remove the job data from the backup repository.

• You cannot use a scale-out backup repository as a cloud repository. You cannot add a cloud repository as an extent to the scale-out backup repository.
• You cannot use a backup repository with rotated drives as an extent to a scale-out backup repository. Even you enable the This repository is backed up by rotated hard drives setting for an extent, Veeam Backup & Replication will ignore this setting and use an extent as a simple backup repository.

• If a backup repository is added as an extent to the scale-out backup repository, you cannot use it as a regular backup repository.

• You cannot add a scale-out backup repository as an extent to another scale-out backup repository.
• You cannot add a backup repository as an extent if this backup repository is already added as an extent to another scale-out backup repository.
• You cannot add a backup repository on which some activity is being performed (for example, a backup job or restore task) as an extent to the scale-out backup repository.
• If you use Enterprise Edition of Veeam Backup & Replication, you can create 1 scale-out backup repository with 3 extents for this scale-out backup repository. Enterprise Plus Edition has no limitations on the number of scale-out backup repositories or extents.

Extents

• Number of tasks that can be performed simultaneously
• Read and write data rate limit
• Data decompression settings
• Block alignment settings

• Rotated drive settings. Rotated drive settings are ignored and cannot be configured at the level of the scale-out backup repository.
• Per-VM backup file settings. Per-VM settings can be configured at the level of the scale-out backup repository.

Backup File Placement

• Data locality— all backup files that belong to the same backup chain are stored on the same extent of the scale-out backup repository.

• Performance— full backup files and incremental backup files that belong to the same backup chain are stored on different extents of the scale-out backup repository. If necessary, you can explicitly specify on which extents full backup files and incremental backup files must be stored.

1. Availability of extents on which backup files reside. If some extent with backup files from the current backup chain is not accessible, Veeam Backup & Replication will trigger a full backup instead of incremental (if this option is enabled).
2. Backup placement policy set for the scale-out backup repository.
3. Load control settings — maximum number of tasks that the extent can process simultaneously.
4. Amount of free space available on the extent — the backup file is placed to the extent with the most amount of free space.
5. Availability of files from the current backup chain — extents that host incremental backup files from the current backup chain (or current VM) have a higher priority than extents that do not host such files.

• For per-VM backup chains: the size of the full backup file is equal to 50% of source VM data. The size of an incremental backup file is equal to 10% of source VM data.

• For single file backup chains: the size of the full backup file is equal to 50% of source data for all VMs in the job. For the first incremental job session, the size of an incremental backup file is equal to 10% the full backup file. For subsequent incremental job sessions, the size of an incremental backup file is equal to 100% of the previous incremental backup file.

1. During the first job session, Veeam Backup & Replication checks to which extent a full backup file can be stored. As both extents can host the full backup file, Veeam Backup & Replication checks which extent has more free space, and picks the extent that has 200 GB of free space.
2. During incremental job session, Veeam Backup & Replication checks to which extent an incremental backup file can be stored. As both extents can host the incremental backup file, Veeam Backup & Replication picks the extent that does not store the full backup file — the extent that has 100 GB of free space.

Service Actions with Scale-Out Backup Repositories

• Put extents to the Maintenance mode
• Evacuate backups from extents

Maintenance Mode

• Veeam Backup & Replication does not start new tasks targeted at this extent.
• You cannot restore VM data from backup files residing on the extent. You also cannot restore VM data from backup files residing on other extents if a part of the backup chain resides on the extent in the Maintenance mode.

• If no tasks using the extent are currently running, the job puts the extent to the Maintenance mode immediately.
• If the extent is busy with any task, for example, a backup job, the job puts the extent to the Maintenance pending state and waits for the task to complete. When the task is complete, the extent is put to the Maintenance mode.

Backup Files Evacuation

• On Extent 1, full backup files are stored.
• On Extent 2 and Extent 3, incremental backup files are stored.

Backup Repositories with Rotated Drives

1. Veeam Backup & Replication creates a regular backup chain on the currently attached drive.
2. When a new job session starts, Veeam Backup & Replication checks if the backup chain on the currently attached drive is consistent. The consistent backup chain must contain a full backup and all incremental backups that have been produced by the job. This requirement applies to all types of backup chains: forever forward incremental, forward incremental and reverse incremental.

• [For backup jobs] Veeam Backup & Replication starts the backup chain anew. It creates a new full backup file on the drive, and this full backup is used as a starting point for subsequent incremental backups.
• [For backup copy jobs] If the attached drive is empty, Veeam Backup & Replication creates a full backup on it. If there is a backup chain on the drive,Veeam Backup & Replication creates a new incremental backup and adds it to the backup chain. The latest incremental backup existing in the backup chain is used as a starting point for the new incremental backup.

3. [For external drives attached to Microsoft Windows servers] Veeam Backup & Replication checks the retention policy set for the job. If some backup files in the backup chain are outdated, Veeam Backup & Replication removes them from the backup chain.
4. When you swap drives again, Veeam Backup & Replication behaves in the following way:

• [For backup jobs] Veeam Backup & Replication checks the backup chain for consistency and creates a new full backup.

• [For backup copy jobs] If the attached drive is empty, Veeam Backup & Replication creates a full backup on it. If there is a backup chain on the drive, Veeam Backup & Replication creates a new incremental backup and adds it to the backup chain. The latest incremental backup existing in the backup chain is used as a starting point for the new incremental backup.

• When you insert a drive for the first time, the drive is not registered in the configuration database. Such drive must have the same letter as the one specified in the Path to folder field in the backup repository settings.

• When you insert a drive that has already been used and has some restore points on it, the drive is already registered in the configuration database. Veeam Backup & Replication will be able to detect and use it, even if the drive letter changes.

1. During the first run of the job, Veeam Backup & Replication creates a regular backup full backup on the drive that is attached to the backup repository server.
2. During the next job session, Veeam Backup & Replication checks if the current backup chain on the attached drive is consistent. The consistent backup chain must contain a full backup and all incremental backups subsequent to it. This requirement applies to all types of backup chains: forever forward incremental, forward incremental and reverse incremental.

• If the current backup chain is consistent, Veeam Backup & Replication adds a new restore point to the backup chain.
• If external drives have been swapped, and the current backup chain is not consistent,  
• Veeam Backup & Replication always starts a new backup chain (even if restore points from previous backup chains are available on the attached drive). Veeam Backup & Replication creates a new full backup file on the drive, and this full backup is used as a starting point for subsequent incremental backups.
  
  As soon as Veeam Backup & Replication starts a new backup chain on the drive, it removes information about restore points from previous backup chains from the configuration database. Backup files corresponding to these previous restore points are not deleted, they remain on disk. This happens because Veeam Backup & Replication applies the retention policy only to the current backup chain, not to previous backup chains.

1. You cannot store archive full backups (GFS backups) created with backup copy jobs in backup repositories with rotated drives.
2. You cannot store per-VM backup files in backup repositories with rotated drives.

Support for Deduplicating Storage Systems

• EMC Data Domain
• ExaGrid
• HPE StoreOnce

EMC Data Domain

• Distributed Segment Processing
• Advanced Load Balancing and Link Failover
• Virtual Synthetics
• Managed File Replication

How EMC Data Domain Works

• DD Boost library. The DD Boost library is a component of the EMC Data Domain system. The DD Boost library is embedded into the Veeam Data Mover Service setup. When you add a Microsoft Windows server to the backup infrastructure, the DD Boost Library is automatically installed on the added server together with the Data Mover Service.
• DD Boost server. The DD Boost server is a target-side component running on the OS of the EMC Data Domain storage system.

• The server must run Microsoft Windows OS.
• The server must be added to the backup infrastructure.
• The server must have access to the backup server and EMC Data Domain appliance.

Supported Protocols

• TCP/IP protocol: Veeam Backup & Replication communicates with the EMC Data Domain server by sending commands over the network.
• Fibre Channel protocol: Veeam Backup & Replication communicates with the EMC Data Domain Fibre Channel server by sending SCSI commands over Fibre Channel.

Limitations for EMC Data Domain

• Use of EMC Data Domain with DD Boost does not guarantee improvement of job performance; it reduces the load on the network and improves the network throughput.
• EMC Data Domain requires at least 1 Gbps network and 0% of packets data loss between the gateway server and EMC Data Domain storage appliance. In the opposite case, stable work of EMC Data Domain cannot be guaranteed.
• EMC Data Domain does not support the reverse incremental backup method. Do not enable this option for backup jobs targeted at this type of backup repository.
• When you create a backup job targeted at EMC Data Domain, Veeam Backup & Replication will offer you to switch to optimized job settings and use the 4 MB size of data block for VM data processing. It is recommended that you use optimized job settings. Large data blocks produce a smaller metadata table that requires less memory and CPU resources to process.
• The length of forward incremental and forever forward incremental backup chains (chains that contain one full backup and a set of subsequent incremental backups) cannot be greater than 60 restore points. To overcome this limitation, schedule full backups (active or synthetic) to split the backup chain into shorter series. For example, to perform backups at 30-minute intervals 24 hours a day, you must schedule synthetic fulls every day. In this scenario, intervals immediately after midnight may be skipped due to duration of synthetic processing.
• If you connect to EMC Data Domain over Fibre Channel, you must explicitly define a gateway server to communicate with EMC Data Domain. As a gateway server, you must use a Microsoft Windows server that is added to the backup infrastructure and has access to the EMC Data Domain storage appliance over Fibre Channel.

ExaGrid

• Data Mover Service on the backup proxy
• Data Mover Service on the ExaGrid appliance

HPE StoreOnce

• Perform source-side deduplication
• Perform target-side deduplication
• Work in the shared folder mode

1. You have a Catalyst license installed on HPE StoreOnce.
2. You use a Catalyst store as a backup repository.
3. The Catalyst store is configured to work in the Low Bandwidth mode (Primary and Secondary Transfer Policy).
4. You add the HPE StoreOnce Catalyst as a deduplicating storage appliance, not as a shared folder to the backup infrastructure.

1. During the backup job session, HPE StoreOnce analyzes data incoming to the HPE StoreOnce appliance in chunks and computes a hash value for every data chunk. Hash values are stored in an index on disk.
2. The HPE StoreOnce Catalyst agent calculates hash values for data chunks in a new data flow and sends these hash values to target.
3. HPE StoreOnce identifies which data blocks are already saved on disk and communicates this information to the HPE StoreOnce Catalyst agent. The HPE StoreOnce Catalyst agent sends only unique data blocks to target.

• For a Catalyst store:

• The Catalyst store works in the High Bandwidth mode (Primary or Secondary Transfer Policy is set to High Bandwidth).
• The Catalyst license is installed on the HPE StoreOnce (required).
• The Catalyst store is added as a backup repository to the backup infrastructure.

• For a CIFS store:

• The Catalyst license is not required.
• The CIFS store is added as a backup repository to the backup infrastructure.

1. HPE StoreOnce analyzes data incoming to the HPE StoreOnce appliance in chunks and creates a hash value for every data chunk. Hash values are stored in an index on the target side.
2. HPE StoreOnce analyzes VM data transported to target and replaces identical data chunks with references to data chunks that are already saved on disk.

How HPE StoreOnce Works

• HPE StoreOnce Catalyst agent. The HPE StoreOnce Catalyst agent is a component of the HPE StoreOnce Catalyst software. The HPE StoreOnce Catalyst agent is embedded into the Veeam Data Mover Service setup. When you add a Microsoft Windows server to the backup infrastructure, the HPE StoreOnce Catalyst agent is automatically installed on the added server together with the Data Mover Service.
• HPE StoreOnce appliance. The HPE StoreOnce appliance is an HPE StoreOnce storage system on which Catalyst stores are created.

• Data Mover Service on the backup proxy
• Data Mover Service on the gateway server

• The server must run Microsoft Windows OS.
• The server must be added to the backup infrastructure.
• The server must have access to the backup server and HPE StoreOnce appliance.

Tip:

For work with HP StoreOnce, Veeam Backup & Replication uses the Catalyst agent installed on the gateway proxy. If you want to reduce the load on the network between the source and target side, assign the gateway server role to a machine on the source side, closer to the backup proxy.

Limitations for HPE StoreOnce

• Backup files on HPE StoreOnce are locked exclusively by a job or task. If you start several tasks at a time, Veeam Backup & Replication will perform a task with a higher priority and will skip or terminate a task with a lower priority.

• When you create a backup job targeted at HPE StoreOnce, Veeam Backup & Replication will offer you to switch to optimized job settings and use the 4 MB size of data block for VM data processing. It is recommended that you use optimized job settings. Large data blocks produce a smaller metadata table that requires less memory and CPU resources to process.
• The HPE StoreOnce backup repository always works in the Use per-VM backup files mode.
• The length of backup chains (chains that contain one full backup and a set of subsequent incremental backups) on HPE StoreOnce cannot be greater than 7 restore points. The recommended backup job schedule is the following: not more than 1 incremental backup once a day, not fewer than one full backup (active or synthetic) once a week.
• HPE StoreOnce does not support the reverse incremental backup method.
• The HPE StoreOnce backup repository does not support the Defragment and compact full backup file option (for backup and backup copy jobs).
• You cannot perfom quick migration for Microsoft Hyper-V VMs started with Instant VM Recovery from the backup that resides on the HP StoreOnce backup repository.
• You cannot use the HP StoreOnce backup repository as a target for Veeam Endpoint backup jobs. Backup copy jobs, however, can be targeted at the HP StoreOnce backup repository.
• You cannot use the HPE StoreOnce backup repository as a source or target for file copy jobs.
• You cannot use the HPE StoreOnce backup repository as a cloud repository.

• If you configure several backup repositories on HPE StoreOnce and add them as extents to a scale-out backup repository, make sure that all backup files from one backup chain are stored on one extent. If backup files from one backup chain are stored to different extents, the transform operations performance will be lower.
• HPE StoreOnce has a limit on the number of opened files that applies to the whole appliance. Tasks targeted at different backup repositories on HPE StoreOnce and run in parallel will equally share this limit.
• For HPE StoreOnce working over Fibre Channel, there is a limitation on the number of connections from one host. If you connect several backup repositories to one gateway, backup repositories will compete for connections.
• Deduplication on HPE StoreOnce works within the limits of one object store.

Gateway Server

• Shared folder backup repositories
• EMC DataDomain and HPE StoreOnce deduplicating storage appliances

• A gateway server can run on a physical or virtual machine.
• The gateway server can run on a Microsoft Windows machine or Microsoft Hyper-V host.
• The machine must be added to the backup infrastructure.
• The machine must have access to the backup repository — shared folder, EMC DataDomain or HPE StoreOnce.

• If you select a gateway server explicitly, Veeam Backup & Replication uses the selected machine as a gateway server.
• If you instruct Veeam Backup & Replication to select the gateway server automatically, Veeam Backup & Replication selects a gateway server using the following rules:

• For backup jobs: the role of a gateway server is assigned to a machine performing the role of a backup proxy (onsite or offsite).
• For backup copy jobs: if a backup copy job uses a direct data path, the role of a gateway server is assigned to the mount server associated with the backup repository (Veeam Backup & Replication fails over to the backup server if the mount server is not accessible for some reason). If a backup copy job uses WAN accelerators, the role of a gateway server is assigned to WAN accelerators. For example, if you copy backup from a source Microsoft Windows backup repository to a shared folder backup repository, the gateway server role is assigned to the target WAN accelerator. If you copy backups between 2 shared folder backup repositories, the gateway server role is assigned to the source and target WAN accelerators.
• For backup to tape jobs: the role of a gateway server is assigned to the backup server.

Mount Server

1. From the remote site to the local site — to mount the content of the backup file to the staging server.
2. From the local site to the remote site — to restore files or application items.

• Backup repository. For Microsoft Windows backup repositories, the mount server role is assigned to the backup repository server itself.
• Backup server. For Linux, shared folder backup repositories and deduplicating storage appliances, the mount server role is assigned to the backup server.
• Veeam Backup & Replication console. The mount server role is also assigned to a machine on which the Veeam Backup & Replication console is installed. Note that this type of mount server is not registered in the Veeam Backup & Replication configuration database.

• You can assign the role of a mount server to Microsoft Windows machines (physical or virtual).
• You can assign the role of a mount server to 64-bit machines only.
• The mount server must have access to the backup repository with which it is associated and to the original VM (VM to which you restore files or application items). For restore from storage snapshots, the mount server must also have access to the ESX(i) host on which the temporary VM is registered.

Veeam Backup Enterprise Manager

• Veeam Backup Enterprise ManagerService coordinates all operations of Veeam Backup Enterprise Manager, aggregates data from multiple backup servers and provides control over these servers.
• Veeam Backup Enterprise Manager Configuration Database is used by Veeam Backup Enterprise Manager for storing data. The database instance can be located on a SQL Server installed either locally (on the same machine as Veeam Backup Enterprise Manager Server) or remotely.
• Veeam Guest Catalog Service replicates and consolidates VM guest OS file system indexing data from backup servers added to Veeam Backup Enterprise Manager. Index data is stored in Veeam Backup Enterprise Manager Catalog (a folder on the Veeam Backup Enterprise Manager Server) and is used to search for VM guest OS files in backups created by Veeam Backup & Replication.

Veeam Backup Search

Deployment Scenarios

• Simple Deployment
• Advanced Deployment
• Distributed Deployment

Simple Deployment

• It functions as a management point, coordinates all jobs, controls their scheduling and performs other administrative activities.

• It is used as the default backup repository. During installation, Veeam Backup & Replication checks volumes of the machine on which you install the product and identifies a volume with the greatest amount of free disk space. On this volume, Veeam Backup & Replication creates the Backup folder that is used as the default backup repository.
• It is used as a mount server and guest interaction proxy.

Tip:

If you decide to use a simple deployment scenario, you can install Veeam Backup & Replication right on the Hyper-V host where VMs you want to work with reside. However, to use this Hyper-V host as the source for backup and replication, you will still need to add it to the Veeam Backup & Replication console.

• The backup server might not have enough disk capacity to store the required amount of backup data.
• A significant load is placed on production servers that combine the roles of backup proxies and source hosts.

Advanced Deployment

• Virtual infrastructure servers — Hyper-V hosts used as source and target for backup and replication.
• Backups server — a configuration and control center of the backup infrastructure.
• Off-host backup proxy — a “data mover” component used to retrieve VM data from the source datastore, process it and deliver to the target.
• Backup repository — a location used to store backup files and auxiliary replica files.
• Dedicated mount servers — component required for VM guest OS files and application items restore to the original location.
• Dedicated guest interaction proxies — components used to deploy the runtime process in Microsoft Windows VMs.

Distributed Deployment

Resource Scheduling

• Network Traffic Throttling and Multithreaded Data Transfer
• Limiting the Number of Concurrent Tasks
• Limiting Read and Write Data Rates for Backup Repositories
• Detecting Performance Bottlenecks
• Data Processing Modes

Network Traffic Throttling and Multithreaded Data Transfer

• Backup to a Microsoft Windows or Linux backup repository: a backup proxy (onhost or offhost) and backup repository
• Backup to an SMB share, EMC Data Domain and HPE StoreOnce: backup proxy (onhost or offhost) and gateway server
• Backup copy: source and target backup repositories or gateway sever(s), or WAN accelerators (if WAN accelerators are engaged in the backup copy process)
• Replication: source and target backup proxies (onhost or offhost) or WAN accelerators (if WAN accelerators are engaged in the replication process)
• Backup to tape: backup repository and tape server

Note:

Throttling rules are reversible — they function in two directions. If the IP address of the component on the source side falls into the target IP range, and the IP address of the component on the target side falls into the source IP range, the rule will be applied in any case.

Note:

Veeam Backup & Replication performs a CRC check for the TCP traffic going between the source and the target. When you perform backup and replication operations, Veeam Backup & Replication calculates checksums for data blocks going from the source. On the target, it re-calculates checksums for received data blocks and compares them to the checksums created on the source. If the CRC check fails, Veeam Backup & Replication automatically re-sends data blocks without any impact on the job.

Limiting the Number of Concurrent Tasks

Note:

To use this capability, proxy server(s) should meet system requirements – each task requires a single CPU core, so for two tasks to be processed in parallel, 2 cores is the recommended minimum. Parallel VM processing must also be enabled in Veeam Backup & Replication options.

Limiting Read and Write Data Rates for Backup Repositories

Detecting Performance Bottlenecks

1. Reading VM data blocks from the source
2. Processing VM data on the backup proxy
3. Transporting data over the network
4. Writing data to the target

1. Source— source disk reader component responsible for retrieving data from the source storage.
2. Proxy— backup proxy component responsible for processing VM data.
3. Source WAN accelerator— WAN accelerator deployed on the source side. Used for backup copy and replication jobs working via WAN accelerators.
4. Network— network queue writer component responsible for getting processed VM data from the backup proxy and sending it over the network to the backup repository or another backup proxy.
5. Target WAN Accelerator— WAN accelerator deployed on the target side. Used for backup copy and replication jobs working via WAN accelerators.
6. Target— target disk writer component (backup storage or replica datastore).

 

• If you limit the read and write data rates for a backup repository, a backup repository may become a bottleneck. Veeam Backup & Replication will report Throttling in the bottleneck statistics.
• If you set up network throttling rules, network may become a bottleneck. Veeam Backup & Replication will report Throttling in the bottleneck statistics.

Data Processing Modes

Note:

When you limit the number of tasks for the backup repository, you should also consider the storage throughput. If the storage system is not able to keep up with the number of tasks that you have assigned, it will be the limiting factor. It is recommended that you test components and resources of your backup infrastructure to define the workload that they can handle.

1. You set up the backup proxy to process 2 tasks simultaneously.
2. You configure 2 backup jobs, each processing 1 VM with 1 disk.

 

Backup

Unlike traditional backup tools designed to work with physical machines, Veeam Backup & Replication is built specifically for virtual environments. It operates at the virtualization layer and uses an image-based approach for VM backup. To retrieve VM data, no agent software needs to be installed inside the guest OS. Instead, Veeam Backup & Replication leverages VSS snapshot capabilities. When a new backup session starts, a VSS snapshot is taken to create a cohesive point-in-time copy of a VM including its configuration, OS, applications, associated data, system state and so on. Veeam Backup & Replication uses this point-in-time copy to retrieve VM data. Image-based backups can be used for different types of recovery, including Instant VM Recovery, full VM recovery, VM file recovery and file-level recovery.

Use of the image-based approach allows Veeam Backup & Replication to overcome shortfalls and limitations of traditional backup (such as, the necessity to provide guest OS credentials for every VM, significant resource overhead on the VM and hypervisor during the backup process, management overhead and so on). It also helps streamline the restore process — to recover a single VM, there is no need to perform multiple restore operations. Veeam Backup & Replication uses a cohesive VM image from the backup to restore a VM to the required state without the necessity for manual reconfiguration and adjustment.

In Veeam Backup & Replication, backup is a job-driven process where one backup job can be used to process one or more VMs. A job is a configuration unit of the backup activity. Essentially, the job defines when, what, how and where to back up. It indicates what VMs should be processed, what components should be used for retrieving and processing VM data, what backup options should be enabled and where to save the resulting backup file. Jobs can be started manually by the user or scheduled to run automatically.

The resulting backup file stores compressed and deduplicated VM data. All backup files created by the job are located in a dedicated job folder on a backup repository. Veeam Backup & Replication creates and maintains the following types of backup files:

• Full backup (.vbk) to store copies of full VM images
• Backup increment (.vib or .vrb) to store incremental changes to VM images
• Backup metadata (.vbm) to provide information on the backup job, VMs in the backup, number and structure of backup files, restore points, and so on. The metadata file facilitates import of backups or mapping of backup jobs to existing backups.

To back up VMs, you can use one of three available methods:

• Foverver forward incremental backup
• Forward incremental backup
• Reverse incremental backup

Regardless of the method you use, the first run of a job creates a full backup of VM image. Subsequent job runs are incremental — Veeam Backup & Replication copies only those data blocks that have changed since the last backup job run. To keep track of changed data blocks, Veeam Backup & Replication uses its proprietary changed block tracking mechanism.

In This Section

• Backup of VMs on Local Storage and CSV
• Backup of VMs on SMB3
• Backup Architecture
• Backup Methods
• Retention Policy
• Per-VM Backup Files
• Changed Block Tracking
• Data Compression and Deduplication
• Data Exclusion
• Transaction Consistency
• Guest Processing
• Job Scheduling
• VeeamZIP
• Quick Backup
• Health Check for Backup Files
• Compact of Full Backup File

 

Backup of VMs on Local Storage and CSV

Veeam Backup & Replication performs backup of Hyper-V VMs whose disks are located on the local storage and Cluster Shared Volume (CSV). In contrast to traditional backup tools that deploy an agent inside the VM guest OS and back up from within a VM, Veeam Backup & Replication uses a Veeam Data Mover Service running on the Hyper-V host or a Veeam Data Mover Service running on the off-host backup proxy. A VM is treated as an object from the perspective of the Hyper-V host — Veeam Backup & Replication captures the VM configuration and state along with VM VHD/VHDX's and creates an image-based backup of a VM.

To perform backup of Hyper-V VMs, Veeam Backup & Replication leverages the VSS framework and Hyper-V VSS components. It acts as a VSS requestor and communicates with the VSS framework. Veeam Backup & Replication obtains from VSS information about available VSS components, prescribes what components should be used, identifies volumes where files of the necessary VMs are located and triggers the VSS coordinator to create volume snapshots.

Before a snapshot of a volume is created, VMs on the volume must be prepared for the snapshot — that is, data in the VM must be in a state suitable for backup. Veeam Backup & Replication uses three methods to quiesce Hyper-V VMs on the volume: online backup, offline backup and crash-consistent backup.
Whenever possible, Hyper-V VSS uses online backup to quiesce VMs. If online backup cannot be performed, one of the other two methods is used to prepare a VM for a volume snapshot.

• If online backup is not possible, Veeam Backup & Replication will fail over to the crash-consistent backup.
• If you do not want to produce a crash-consistent backup, you can configure your backup jobs to use the offline backup method instead.

Note:

Veeam Backup & Replication does not fail over to the crash-consistent backup mode if you enable application-aware processing for a job and select the Require successful processing option. In such situation, if application-aware processing fails, Veeam Backup & Replication will simply terminate the job with the Error status.

 

Online Backup

Online backup is the recommended backup method for Hyper-V VMs. This type of backup requires no downtime — VMs remain running for the whole period of backup and users can access them without any interruption. Online backup can only be performed if a VM meets a number of conditions: the VM runs under a VSS-aware guest OS, Hyper-V Integration Services are installed inside the guest OS, the backup integration is enabled, and some other requirements. For a complete list of conditions required for online backup, refer to Microsoft Hyper-V documentation.

For online backup, Veeam Backup & Replication uses a native Hyper-V approach. To quiesce VM data, Hyper-V uses two VSS frameworks that work at two different levels and communicate with each other:

• The VSS framework at the level of the Hyper-V host. This VSS framework is responsible for taking a snapshot of the volume on which VMs are located (this snapshot is also called external snapshot).
• The VSS framework inside the VM guest OS. This VSS framework is responsible for quiescing data of VSS-aware applications running inside the VM and creating a snapshot inside the guest OS (this snapshot is also called internal snapshot).

Online backup includes the following steps:

1. Veeam Backup & Replication interacts with the Hyper-V host VSS Service and requests backup of specific VMs.
2. The VSS Writer on the Hyper-V host passes the request to the Hyper-V Integration Components (HV-IC) installed inside the VM guest OS.
3. The HV-IC, in its turn, acts as a VSS Requestor for the VSS framework inside the VM — it communicates with the VSS framework installed in the VM guest OS and requests backup of VSS-aware applications running inside this VM.
4. The VSS Writers within the VSS-aware applications inside the guest OS are instructed to get the application data to a state suitable for backup.
5. After the applications are quiesced, the VSS inside the VM takes an internal snapshot within the VM using a VSS software provider in the VM guest OS.
6. After the internal snapshot is taken, the VM returns from the read-only state to the read-write state and operations inside the VM are resumed. The created snapshot is passed to the HV-IC.
7. The HV-IC notifies the hypervisor that the VM is ready for backup.
8. The Hyper-V host VSS provider takes a snapshot of a volume on which the VM is located (external snapshot).
9. The volume snapshot is presented to Veeam Backup & Replication. Veeam Backup & Replication reads VM files from the volume snapshot using one of two backup modes — on-host backup or off-host backup. After the backup is completed, the snapshot is deleted.

Internal and external snapshots are taken one after another, with a little time difference. During this time interval, the VM on the volume is not frozen – its applications and OS are working as usual. For this reason, when the external snapshot is created, there may remain unfinished application transactions inside the VM, and this data can be lost during backup.

To make sure the VM data is consistent at the moment of backup, Hyper-V VSS Writer performs additional processing inside the created external snapshot — this process is also known as auto-recovery.
Auto-recovery is performed when a volume snapshot is taken. This process includes the following steps:

1. Right after the snapshot of a volume is taken, Hyper-V host VSS allows the Hyper-V host VSS Writer time to update data inside the external snapshot before it is permanently changed to the read-only state.
2. The Hyper-V host VSS Writer rolls back a VM on the external snapshot to the state of the internal snapshot. All changes that took place after the internal snapshot was taken are discarded – this way, VM data inside the external snapshot is brought to a completely consistent state suitable for backup. At the same time, the internal snapshot inside the VM guest OS is deleted.
3. As a result, you have a VM on the production volume, and a consistent volume snapshot that Veeam Backup & Replication uses for backup.

Note:

Auto-recovery may take up to several minutes.

Offline Backup

Offline backup (or backup via saved state) is another native Hyper-V approach to quiescing VMs before taking a volume snapshot. This type of backup requires some downtime of a VM. When a VM is backed up, the Hyper-V VSS Writer forces the VM into the saved state to create a stable system image.
Offline backup is performed in the following way:

1. Veeam Backup & Replication interacts with the Hyper-V host VSS Services and requests backup of specific VMs.
2. The Hyper-V host VSS Writer forces a VM into the saved state for several seconds. The VM OS hibernates and the content of the system memory and CPU is written to a dump file.
3. The Hyper-V host VSS provider takes a snapshot of a volume on which the VM is located. After the snapshot is created, the VM returns to the normal state.
4. The volume snapshot is presented to Veeam Backup & Replication. Veeam Backup & Replication reads VM files from the volume snapshot using one of two backup modes — on-host backup or off-host backup. After the backup is completed, the snapshot is deleted.

Offline backup may be inappropriate — it incurs downtime to a VM and does not produce transactionally consistent backups and replicas as Veeam Backup & Replication does not interact with the VSS framework on the VM guest OS during backup or replication. As an alternative to offline backup, Veeam Backup & Replication offers the crash-consistent backup method for those cases when online backup is not possible and offline backup is unsuitable.

 

Crash-Consistent Backup

Crash-consistent backup is Veeam’s method of creating crash-consistent VM images. A crash-consistent image can be compared to the state of a VM that has been manually reset. Unlike offline backup, crash-consistent backup does not involve any downtime.

Important!

Crash-consistent backup does not preserve data integrity of open files of transactional applications on the VM guest OS and may result in data loss.

Crash-consistent backup is performed in the following way:

1. Veeam Backup & Replication interacts with the Hyper-V host VSS Services and requests backup of specific VMs.
2. The Hyper-V host VSS Writer notifies the VSS provider that volume snapshots can be taken.
3. The Hyper-V host VSS provider creates a snapshot of the requested volume.
4. The volume snapshot is presented to Veeam Backup & Replication. Veeam Backup & Replication reads VM files from the volume snapshot using one of two backup modes — on-host backup or off-host backup. After the backup is completed, the snapshot is deleted.

Backup Modes

• On-Host Backup
• Off-Host Backup

On-Host Backup

1. Veeam Backup & Replication triggers a snapshot of the necessary volume.
2. The Veeam Data Mover Service uses the created volume snapshot to retrieve VM data; it processes the VM data and copies it to the destination.
3. Once the backup process is complete, the volume snapshot is deleted.

• In case you perform backup or replication of VMs whose disks are located on the CSV in Microsoft Windows Server 2012 or Microsoft Windows Server 2012 R2 and Microsoft CSV Software Shadow Copy Provider is used for snapshot creating, Veeam Backup & Replication assigns the role of the on-host backup proxy to the Hyper-V host owning the CSV. If VM disks are located on different CSV's, Veeam Backup & Replication may use several on-host backup proxies, which are the corresponding Hyper-V hosts owning the CSV's.
• In case you perform backup or replication of VMs whose disks are located on the CSV in Microsoft Windows 2008R2 and a VSS software or hardware provider is used for snapshot creation, Veeam Backup & Replication assigns the role of the on-host backup proxy to the Hyper-V host on which the processed VM is registered.

Off-Host Backup

1. You must configure an off-host backup proxy. The role of an off-host backup proxy can be assigned only to a physical Microsoft Windows 2008 Server R2 machine with the Hyper-V role enabled, Microsoft Windows Server 2012 machine with the Hyper-V role enabled or Microsoft Windows Server 2012 R2 machine with the Hyper-V role enabled.

2. In the properties of a backup or replication job, the off-host backup method must be selected. If necessary, you can point the job to a specific proxy.
3. The source Hyper-V host and the off-host backup proxy must be connected (through a SAN configuration) to the shared storage.
4. To create and manage volume shadow copies on the shared storage, you must install and properly configure a VSS hardware provider that supports transportable shadow copies on the off-host proxy and Hyper-V host. Typically, when configuring a VSS hardware provider, you need to specify a server controlling the LUN and disk array credentials to provide access to the array.

5. If you back up VMs whose disks reside on a CSV with Data Deduplication enabled, make sure that you use a Microsoft Windows 2012 R2 machine as an off-host backup proxy and enable the Data Deduplication option on this off-host backup proxy. Otherwise, off-host backup will fail.

1. Veeam Backup & Replication triggers a snapshot of the necessary volume on the production Hyper-V host.
2. The created snapshot is split from the production Hyper-V server and mounted to the off-host backup proxy.
3. The Veeam Data Mover Service running on a backup proxy uses the mounted volume snapshot to retrieve VM data; the VM data is processed on the proxy server and copied to the destination.
4. Once the backup process is complete, the snapshot is dismounted from the off-host backup proxy and deleted on the SAN.

Important!

If you plan to perform off-host backup for a Hyper-V cluster with CSV, make sure you deploy an off-host backup proxy on a host that is NOT a part of a Hyper-V cluster. When a volume snapshot is created, this snapshot has the same LUN signature as the original volume. Microsoft Cluster Services do not support LUNs with duplicate signatures and partition layout. For this reason, volume snapshots must be transported to an off-host backup proxy outside the cluster. If the off-host backup proxy is deployed on a node of a Hyper-V cluster, a duplicate LUN signature will be generated, and the cluster will fail during backup or replication.

Choosing a VSS Provider

• Software providers do not support transportable volume shadow copies and cannot be used for off-host backup.
• By default, in Veeam Backup & Replication jobs working with the same volume can take up to 4 snapshots of a volume simultaneously. The number of snapshots can be increased.
• Hardware providers work at the storage system controller level. Software providers operate at the software level, between the file system and the volume manager, and can cause a significant performance overhead on the source host.
• (For Microsoft Windows 2008 R2) Hardware providers can work with several snapshots simultaneously: that is, if you have several jobs that work with the same volume, you can run them in parallel. If you use a software provider, Veeam Backup & Replication serializes VM processing. You will not be able to start several jobs working with the same volume simultaneously. The volume on which VM disks reside remains locked by one job for the whole period of data processing. Once the job completes, the volume becomes accessible for other jobs.
• (For Microsoft Windows 2008 R2) Software providers are not suitable for backup on Cluster Shared Volumes (CSVs), because a significant backup window is required to back up VMs that reside on the same volume but are registered on different hosts. When a cluster node initiates a snapshot on a CSV, the CSV is switched to the Backup in Progress, Redirected Access mode.

• If a hardware provider is used to take a snapshot in such case, the CSV stays in the redirected mode while the snapshot is taken; after a volume shadow copy is created, the CSV resumes direct I/O.
• If a software provider is used to take a snapshot, the CSV stays in the redirected mode until the backup process completes. In cases when large virtual disks are processed, backup time can be significant.

Backup of VMs on SMB3

1. Make sure that your SMB3 shares are properly configured. For a full list of requirements for SMB3 shares, see the Requirements and supported configurations section at http://technet.microsoft.com/en-us/library/jj612865.aspx.
2. Add the SMB3 server or SMB3 cluster hosting the necessary file shares to the Veeam Backup & Replication console. Otherwise Veeam Backup & Replication will not be able to use the changed block tracking mechanism for VMs residing on SMB3 shares.
3. Make sure that VMs you plan to work with are not located on hidden shares or default shares like C$ or D$. When re-scanning SMB v3 file shares, Veeam Backup & Replication skips these types of shares.

Backup Process

1. VSS framework on the Hyper-V host (Hyper-V Host VSS). When Veeam Backup & Replication starts the backup process, it communicates directly with the VSS framework on the Hyper-V host where the VM is registered. The Hyper-V host VSS Service initiates creation of the file share shadow copy, freezes VM application writes and passes the request for shadow copy to the VSS for SMB File Shares framework. After the shadow copy is created, the Hyper-V host VSS Service returns a path to the shadow copy to Veeam Backup & Replication.
2. VSS for SMB File Shares. This framework is Microsoft’s extension to its VSS framework. VSS for SMB File Shares provides application-consistent shadow copies of VMs on SMB3 network shares. To work with shadow copies of file shares, VSS for SMB File Shares uses two components:

• File Share Shadow Copy Provider is a VSS provider for SMB3. The File Share Shadow Copy Provider is invoked on the Hyper-V host where the VM is registered. The provider uses VSS APIs to interact with the VSS requestor, File Share Shadow Copy Agent, and request creation of file shares shadow copies.
• File Share Shadow Copy Agent is a VSS requestor for SMB3. The File Share Shadow Copy Agent is invoked on the SMB3 file server. The agent interacts with the local VSS framework on the SMB3 file server to create a shadow copy of the requested file share.

3. Local VSS framework on the SMB3 file server. This framework is responsible creating a shadow copy of the volume on which the file share is located and exposing the shadow copy as a file share on the SMB3 server.

 

1. Veeam Backup & Replication interacts with the Hyper-V host VSS Service and requests a shadow copy of the necessary file share.
2. The Hyper-V host VSS Service sends a request to prepare a shadow copy to the Hyper-V host VSS Writer. The Hyper-V host VSS Writer flushes buffers and holds application writes on VMs.
3. The Hyper-V host VSS Service sends a request for shadow copy creation to the File Share Shadow Copy Provider invoked on the Hyper-V host.
4. The File Share Shadow Copy Provider relays the request to the File Share Shadow Copy Agent invoked on the SMB3 file server hosting the necessary file share.
5. The File Share Shadow Copy Agent triggers a request for shadow copy creation to the local VSS on the SMB3 file server.
6. The local VSS on the SMB3 file server uses the necessary shadow copy provider to create a shadow copy of the volume on which the necessary file share is located. The shadow copy is exposed as a file share on the SMB3 server. After that, application writes on VMs located on the original file share are resumed.
7. The File Share Shadow Copy Agent returns a path to the shadow copy to the File Share Shadow Copy Provider.
8. The File Share Shadow Copy Provider communicates this information to the Hyper-V host VSS Service.
9. Veeam Backup & Replication retrieves information about the shadow copy properties from the Hyper-V host VSS Service.
10. Veeam Backup & Replication uses the created shadow copy for backup. The Data Mover on the backup proxy (onhost or offhost) establishes a connection to the Data Mover on the Microsoft SMB3 server and reads CBT information from the Microsoft SMB3 server. The Data Mover on the backup proxy then retrieves VM data blocks from the shadow copy, compresses and deduplicates them, and passes to the Data Mover on the backup repository.

Backup Modes

• On-Host Backup
• Off-Host Backup

On-Host Backup

1. Veeam Backup & Replication triggers a shadow copy of the necessary file share. Microsoft VSS components invoked on the Hyper-V host and SMB3 server create a shadow copy of the volume on which the requested file share is located and expose the shadow copy as a file share on the SMB3 server.
2. The Veeam Data Mover Service deployed on the Hyper-V host accesses the shadow copy file share exposed on the SMB3 server. Veeam Backup & Replication retrieves VM data from the shadow copy, processes the data and copies it to the destination.
3. Once the backup process is complete, the shadow copy is deleted.

Off-Host Backup

1. You must configure an off-host backup proxy. The role of an off-host backup proxy can be assigned only to a physical Microsoft Windows 2008 Server R2 machine with the Hyper-V role enabled, Microsoft Windows 2012 machine with the Hyper-V role enabled or Microsoft Windows 2012 R2 machine with the Hyper-V role enabled.

2. In the properties of a backup or replication job, you must select the off-host backup method. If necessary, you can assign the job to a specific proxy.
3. The Local System account of the off-host backup proxy must have full access permissions on the SMB3 file share.
4. The off-host backup proxy should be located in the same domain where the SMB3 server resides. Alternatively, the domain where the SMB3 server resides should be trusted by the domain in which the off-host backup proxy is located.

1. Veeam Backup & Replication triggers a shadow copy of the necessary file share. Microsoft VSS components invoked on the Hyper-V host and SMB3 server create a shadow copy of the volume on which the requested file share is located and expose the shadow copy as a file share on the SMB3 server.
2. The Veeam Data Mover Service on the off-host backup proxy accesses the shadow copy on the SMB3 server. It retrieves VM data from the shadow copy, processes the VM data and copies it to the destination.
3. Once the backup process is complete, the shadow copy is deleted.

Backup Architecture

• One or more source hosts with associated volumes
• Off-host backup proxy server (optional)
• One or more backup repositories

• One or more guest interaction proxies (optional)

1. Veeam Backup & Replication deploys the runtime process on VM guest OSes via the guest interaction proxy (for Microsoft Windows VMs) or backup server (for VMs with other OSes).
2. The target-side Veeam Data Mover Service obtains the job instructions and communicates with the source-side Veeam Data Mover Service to begin data collection.
3. After a VSS snapshot is created, the source-side Veeam Data Mover Service copies VM data from the volume shadow copy. While copying, the source-side Veeam Data Mover Service performs additional processing — it consolidates the content of virtual disks by filtering out zero-data blocks and blocks of swap files. During incremental job runs, the Veeam Data Mover Service retrieves only those data blocks that have changed since the previous job run (note that with changed block tracking enabled, the speed of incremental backup dramatically increases). Copied blocks of data are compressed and moved from the source-side Veeam Data Mover Service to the target-side Data Mover Service.
4. The target-side Veeam Data Mover Service deduplicates similar blocks of data and writes the result to the backup file in the backup repository.

Onsite Backup

Offsite Backup

Backup Methods

• Forever forward incremental backup
• Forward incremental backup
• Reverse incremental backup

Prerequisites

• Two CentOS 7 servers with a sudo non-root user.
• One the CentOS 7 servers needs Apache, MySQL, and PHP installed.

Step 1 — Installing the Zabbix Server

ssh sammy@your_zabbix_server_ip_address

• sudo rpm -ivh http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm

sudo yum install zabbix-server-mysql zabbix-web-mysql 

sudo yum install zabbix-agent 

Step 2 — Configuring the MySQL Database For Zabbix

mysql -uroot -p 

create database zabbix character set utf8; 

• grant all privileges on zabbix.* to zabbix@localhost identified by 'your_password';

flush privileges; 

quit; 

cd /usr/share/doc/zabbix-server-mysql-3.0.4/ 

zcat create.sql.gz | mysql -uzabbix -p zabbix 

sudo vi /etc/zabbix/zabbix_server.conf 

### Option: DBPassword                           
#       Database password. Ignored for SQLite.   
#       Comment this line if no password is used.
#                                                
# Mandatory: no                                  
# Default:                                       
# DBPassword=

DBPassword=your_zabbix_mysql_password

Step 3 — Configuring PHP For Zabbix

sudo vi /etc/httpd/conf.d/zabbix.conf 

    php_value max_execution_time 300
    php_value memory_limit 128M
    php_value post_max_size 16M
    php_value upload_max_filesize 2M
    php_value max_input_time 300
    php_value always_populate_raw_post_data -1
# php_value date.timezone Europe/Riga

sudo systemctl restart httpd 

sudo systemctl start zabbix-server 

sudo systemctl status zabbix-server 

sudo systemctl enable zabbix-server 

Step 4 — Configuring Settings for the Zabbix Web Interface

Step 5 — Installing and Configuring the Zabbix Agent

ssh sammy@your_monitored_server_ip_address

• sudo rpm -ivh http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm

Preparing...                          ################################# [100%]
Updating / installing...
   1:zabbix-release-3.0-1.el7         ################################# [100%]

sudo yum install zabbix-agent 

sudo sh -c "openssl rand -hex 32 > /etc/zabbix/zabbix_agentd.psk"

cat /etc/zabbix/zabbix_agentd.psk