来源:蜘蛛抓取(WebSpider)
时间:2017-06-13 11:22
标签:
esxi 5.0 iso
VMware&Esxi&5.1备份和恢复VM
VMware Esxi 5.1备份和恢复VM的方式很多,下面介绍2种方式:
一.使用vSphere Client对VM进行直接备份和恢复:
备份:1.打开侧边栏物理资源池,选中物理机,然后选择右边标题栏上面的“配置”--“存储器”--“datastore1”--右键--“浏览数据存储”--选中VM所在的文件夹--把数据存储文件下载到本地计算机。
恢复:2.打开侧边栏物理资源池,选中物理机,然后选择右边标题栏上面的“配置”--“存储器”--“datastore1”--右键--“浏览数据存储”--上传--上传文件夹--选中.vmx的VM配置文件--右键--“添加到清单”,选择侧边栏--资源池--VM--右键“电源”--打开电源--打开控制台--查看恢复进程。
二.使用vSphere Client对VM进行OVF模板制作,转换成OVA文件进行导出和导入:
备份:1.打开侧边栏物理资源池,选中资源池下面的VM--编辑设置--CD/DVD驱动器--设备类型:客户端设备。然后点击标题栏“文件”--导出--“导出OVF模板”--选择格式为“OVA”格式并且指定备份的名称和目录。
恢复2:打开侧边栏物理资源池,选中物理机,然后选择标题栏--文件--部署OVF模板--浏览本地计算机,选中.OVA文件--输入VM名称--数据存储选择“Thin
Provision”--勾选“部署后打开电源”。
本文出自 “”
博客,请务必保留此出处
已投稿到:
以上网友发言只代表其个人观点,不代表新浪网的观点或立场。下次自动登录
现在的位置:
& 综合 & 正文
使用ghettoVCB给VMware ESXi 下的虚拟机做热备份
ghettoVCB.sh 介绍
ghettoVCB.sh 此脚本主要是针对VMWare ESXi 备份、还原使用。目前能使用的版本有ESX(i)3.5/4.x/5.x,使用的方法类似VMware的VCB的工具执行备份。ghettoVCB.sh的工作流程大致为,执行虚拟机的快照,然后进行备份,当备份完成后会删除快照。而此脚本最大的特色为可在虚拟机在线时备份,而不用停机备份。
本文准载自:http://blog./?p=6158
ghettoVCB.sh 设定
一、准备工作
开启VMWare
1. 开启SSH
[Configuration] → [Security Profile] → [Properties]
2. [SSH] → [Options] → [Start]
放置ghettoVCB文件
在放置ghettoVCB文件可分为两种方式,选一种来用就行了。
2. 上传lamw-ghettoVCB-518cef7.tar.gz
把刚刚下载好的lamw-ghettoVCB-518cef7.tar.gz上传到ESXi Server。
使用VMware vSphere Client上传
[Configuration] → [Storage] → [datastore1] → [Browse Datastore]
3.选择档案要存放的路径,然后点,选Upload
4. 上传完成后,会看到刚上传好的lamw-ghettoVCB-518cef7.tar.gz,如果没出线的话可按一下
1. 使用SSH 登入ESXi Server
2. 下载档案
# cd /vmfs/volumes/datastore1
# wget http://download./download/System/VMware/ghettoVCB
/ lamw - ghettoVCB - 518cef7.tar.gz
Connecting to
download . faq - book . com
( 61.66.28.156 : 80 )
lamw - ghettoVCB - 518ce
| * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |
0 : 00 : 00
3. 查看档案
查看档案会看到已下载完成的lamw-ghettoVCB-518cef7.tar.gz
lamw-ghettoVCB-518cef7.tar.gz
二、ghettoVCB.sh安装与设定
在开始安装之前有一点要注意一下
由于ESXi重开机之后会把某些资料删除,因此会建议把此文件留在datastore1此硬盘空间内,才不会因重开机后文件就被删除了。
因5.1版为最新版本,而
尚未更新至最新板。如果是使用VMware ESXi 5.1版的,在 ghettoVCB.sh 以下有个地方要修改。要不然在使用上会出现版本序号有问题。
ghettoVCB-master版本的无需修改以下配置
大约在第231行会看到以下程式码,请加入|| [[ "${ESX_VERSION}" == "5.1.0" ]]。多加上5.1版本的判断。
这边有修改好的
# vi ghettoVCB.sh
ESX_VERSION = $ ( vmware
'{print $3}' )
"${ESX_VERSION}"
ESX_VERSION = $ ( vmware
'{print $3}' )
"${ESX_VERSION}"
"${ESX_VERSION}"
基本上datastore1的路径为/vmfs/volumes/datastore1
解tar后会看到ghettoVCB.sh,此脚本正是所需要的
cd /vmfs/volumes/datastore1
tar -zxvf lamw-ghettoVCB-518cef7.tar.gz
cd lamw-ghettoVCB-518cef7
ghettoVCB-restore.sh
ghettoVCB-vm_backup_configuration_template
ghettoVCB.conf
ghettoVCB-restore_vm_restore_configuration_template
ghettoVCB.sh
2. 相关设定档参数说明
2.1 ghettoVCB.sh 设定档
说明ghettoVCB.sh 设定档内常用的设定
这边有修改好的设定档,提供下载参考
# vi ghettoVCB.sh
# Author: William Lam
# Created Date: 11/17/2008
# /docs/DOC-8760
################################################## ################
# directory that all VM backups should go (eg /vmfs/volumes/SAN_LUN1/mybackupdir)
# 设定备份后的储存位置,可自行修改储存位置。
VM_BACKUP_VOLUME = / vmfs / volumes / dlgCore - NFS - bigboi . VM - Backups / WILLIAM_BACKUPS
# Format output of VMDK backup
# zeroedthick
# 2gbsparse
# eagerzeroedthick
# 定义备份的硬碟格式,想了解硬碟格式说明请参考「VMware vSphere(ESXi) 虚拟硬碟格式介绍」
DISK_BACKUP_FORMAT = thin
# Number of backups for a given VM before deleting
# 定义备份保留的数量
VM_BACKUP_ROTATION_COUNT = 3
# Shutdown guestOS prior to running backups and power them back on afterwards
# This feature assumes VMware Tools are installed, else they will not power down and loop forever
# 1=on, 0 =off
# 虚拟机POWER OFF时不会要求snapshotting (enable=1,disable=0)
POWER_VM_DOWN_BEFORE_BACKUP = 0
# enable shutdown code 1=on, 0 = off
# 定义没有安装VMware Tools的虚拟机是否可以在硬碟POWER OFF时启用"POWER_VM_DOWN_BEFORE_BACKUP"
ENABLE_HARD_POWER_OFF = 0
# if the above flag "ENABLE_HARD_POWER_OFF "is set to 1, then will look at this flag which is the # of iterations
# the script will wait before executing a hard power off, this will be a multiple of 60seconds
# (eg) = 3, which means this will wait up to 180seconds (3min) before it just powers off the VM
# 如果启用"ENABLE_HARD_POWER_OFF"此定义执行强制关闭时会倒数运算,单位3为3分钟180秒
ITER_TO_WAIT_SHUTDOWN = 3
# Number of iterations the script will wait before giving up on powering down the VM and ignoring it for backup
# this will be a multiple of 60 (eg) = 5, which means this will wait up to 300secs (5min) before it gives up
# 设定POWER DOWN的时间。等待关闭时VM会放弃或忽略特定的VM备份。单位5为5分钟300秒
POWER_DOWN_TIMEOUT = 5
# enable compression with gzip+tar 1=on, 0=off
# 备份是否启用压缩(enable=1,disable=0)
ENABLE_COMPRESSION = 0
############################
####### NEW PARAMS #########
############################
# Include VMs memory when taking snapshot
# 是否启用VM 虚拟机的快照记忆体(enable=1,disable=0)
VM_SNAPSHOT_MEMORY = 0
# Quiesce VM when taking snapshot (requires VMware Tools to be installed)
# 是否启用对停止的VM 虚拟机使用快照(需有安装VMware Tools)
VM_SNAPSHOT_QUIESCE = 0
################################################## ########
# NON-PERSISTENT NFS-BACKUP ONLY
# ENABLE NON PERSISTENT NFS BACKUP 1=on, 0=off
# 接下来为NFS的相关设定
# 以下是给不想让NFS与系统长期连接的设定。允许只在备份的过程中连接到NFS,
并使用到以下6个变数。
#定义非持久性的NFS备份
ENABLE_NON_PERSISTENT_NFS = 0
# umount NFS datastore after backup is complete 1=yes, 0=no
# 是否要卸载NFS(yes=1,no=0)
UNMOUNT_NFS = 0
# IP Address of NFS Server
# NFS Server 的地址(ip或主机名)
NFS_SERVER = 172.51.0.192
# Path of exported folder residing on NFS Server (eg /some/mount/point )
# NFS 存放档案的路径
NFS_MOUNT = / upload
# Non-persistent NFS datastore display name of choice
# NFS 资料存放地方的名称
NFS_LOCAL_NAME = backup
# Name of backup directory for VMs residing on the NFS volume
# 虚拟机上NFS备份的目录
NFS_VM_BACKUP_DIR = mybackups
############################
######### EMAIL ############
############################
# 以下是MAIL 发送LOG的设定
# Email debug 1=yes, 0=no
# 是否发送debug的LOG,这是做为测试使用
EMAIL_DEBUG = 0
# Email log 1=yes, 0=no
# 是否要透过电子邮件来发送备份LOG (yes=1,no=0)
EMAIL_LOG = 0
# Email Delay Interval from NC (netcat) - default 1
# 设定每封mail之间发送的延迟时间。
EMAIL_DELAY_INTERVAL = 1
# Email SMTP server
# Email 的SMTP server的ip或网址
EMAIL_SERVER = auroa . primp - industries . com
# Email SMTP server port
# 设定mail 所使用的port
EMAIL_SERVER_PORT = 25
# Email FROM
# 寄件人的mail
EMAIL_FROM = root @ ghettoVCB
# Email RCPT
# 收件人的mail
EMAIL_TO = auroa @ primp - industries . com
########################## DO NOT MODIFY PAST THIS LINE ################## ########
# RSYNC LINK 1=yes, 0 = no
RSYNC_LINK = 0
LOG_LEVEL = "info"
VMDK_FILES_TO_BACKUP = "all"
# default 15min timeout
# 设定等待VM快照的时间,在等待关闭时会放弃和忽略特定备份的VM
SNAPSHOT_TIMEOUT = 15
LAST_MODIFIED_DATE =
VERSION = 1
VERSION_STRING = $ { LAST_MODIFIED_DATE } _ $ { VERSION }
# Directory naming convention for backup rotations (please ensure there are no spaces!)
VM_BACKUP_DIR_NAMING_CONVENTION = "$(date +%F_%H-%M-%S)"
2.2 ghettoVCB.sh 参数使用说明
以下是ghettoVCB.sh相关参数的使用说明
./ghettoVCB.sh
Loggingoutputto"/tmp/ghettoVCB-_15-46-10.log"...
2012-10-1615:46:10--info:ERROR:Incorrectnumberofarguments!
##################################################
#############################
ghettoVCB for ESX/ESXi 3.5, 4.x+ and 5.0
Author: William Lam
Documentation: /docs/DOC-8760
Created: 11/17/2008
Last modified:
##################################################
#############################
Usage:./ghettoVCB.sh-f[VM_BACKUP_UP_LIST]-c[VM_CONFIG_DIR]-l[LOG_FILE]-d[DEBUG_LEVEL]-g[GLOBAL_CONF]-e[VM_EXCLUSION_LIST]
BackupallVMsonhost
(备份主机上所有的虚拟机)
ListofVMstobackup
(针对List名单内的虚拟机备份)
VMconfigurationdirectoryforVMbackups
(VM配置目录forVM备份)
PathtoglobalghettoVCBconfigurationfile
Filetooutputlogging
(将LOG记录写到指定档案内)
Debuglevel[info|debug|dryrun](default:info)
(Debug测试,不会产生备份)
BackupVMsstoredinalist
只备份list内的虚拟机
./ghettoVCB.sh-fvms_to_backup
BackupallVMsresidingonthishost
./ghettoVCB.sh-a
BackupallVMsresidingonthishostexceptfortheVMsintheexclusionlist
除了 排除清单(vm_exclusion_list)上的虚拟机外,剩下的都备份
./ghettoVCB.sh-a-evm_exclusion_list
BackupVMsbasedonspecificconfigurationlocatedindirectory
根据vm_backup_configs中特定配置来备份vms_to_backup内指定的虚拟机
./ghettoVCB.sh-fvms_to_backup-cvm_backup_configs
BackupVMsusingglobalghettoVCBconfigurationfile
备份虚拟机时使用ghettoVCB.conf此设定档来备份vms_to_backup内指定的虚拟机
./ghettoVCB.sh-fvms_to_backup-g/global/ghettoVCB.conf
Outputwilllogto/tmp/ghettoVCB.log(considerloggingtolocalorremotedatastoretopersistlogs)
输出的记录到/tmp/ghettoVCB.log(可自行设定LOG所储存的路径和档案)
./ghettoVCB.sh-fvms_to_backup-l/vmfs/volume/local-storage/ghettoVCB.log
Dryrun(nobackupwilltakeplace)
Debug测试,不会产生备份
./ghettoVCB.sh-fvms_to_backup-ddryrun
3. 操作范例
在了解相关参数和设定之后,就用一个比较简单的范例来实作一次。
以下的操作请都在「lamw-ghettoVCB-518cef7」资料夹内操作
3.1建立备份List表
在开始操作之前,先来建立vms_to_backup
List的名称可自己设定
# vi vms_to_backup
#加入要指定的虚拟机名称
3.2 Debug 测试备份
用来排除故障是相当好用的
此模式执行后会提供更详细的讯息,内容包括备份档案和LOG存放的路径,以及备份使用到的空间相关讯息。
./ghettoVCB.sh -f vms_to_backup -d debug
Loggingoutputto"/tmp/ghettoVCB-_13-20-15.log"...
Insufficientarguments.
2012-10-1613:20:15--info:==========ghettoVCBLOGSTART===========
2012-10-1613:20:15--debug:Succesfullyacquiredlockdirectory–/tmp/ghettoVCB.lock
2012-10-1613:20:15--debug:HOSTVERSION:VMwareESXi5.0.0build-469512
2012-10-1613:20:15--debug:HOSTLEVEL:VMwareESXi5.0.0GA
2012-10-1613:20:16--debug:HOSTNAME:localhost
2012-10-1613:20:16--info:CONFIG-VERSION=_1
2012-10-1613:20:16--info:CONFIG-GHETTOVCB_PID=450122
2012-10-1613:20:16--info:CONFIG-VM_BACKUP_VOLUME=/vmfs/volumes/datastore1/backup/backup
2012-10-1613:20:16--info:CONFIG-VM_BACKUP_ROTATION_COUNT=3
2012-10-1613:20:16--info:CONFIG-VM_BACKUP_DIR_NAMING_CONVENTION
=2011-12-27_13-37-15
2012-10-1613:20:16--info:CONFIG-DISK_BACKUP_FORMAT=thin
2012-10-1613:20:16--info:CONFIG-POWER_VM_DOWN_BEFORE_BACKUP=0
2012-10-1613:20:16--info:CONFIG-ENABLE_HARD_POWER_OFF=0
2012-10-1613:20:16--info:CONFIG-ITER_TO_WAIT_SHUTDOWN=3
2012-10-1613:20:16--info:CONFIG-POWER_DOWN_TIMEOUT=5
2012-10-1613:20:16--info:CONFIG-SNAPSHOT_TIMEOUT=15
2012-10-1613:20:16--info:CONFIG-LOG_LEVEL=debug
2012-10-1613:20:16--info:CONFIG-BACKUP_LOG_OUTPUT=/tmp/ghettoVCB-2011-12-27_13-37-15.log
2012-10-1613:20:16--info:CONFIG-VM_SNAPSHOT_MEMORY=0
2012-10-1613:20:16--info:CONFIG-VM_SNAPSHOT_QUIESCE=0
2012-10-1613:20:16--info:CONFIG-VMDK_FILES_TO_BACKUP=all
2012-10-1613:20:16--info:CONFIG-EMAIL_LOG=0
2012-10-1613:20:16--info:
2012-10-1613:20:19--debug:StorageInformationbeforebackup:
2012-10-1613:20:19--debug:SRC_DATASTORE:datastore1
2012-10-1613:20:19--debug:SRC_DATASTORE_CAPACITY:267.2GB
2012-10-1613:20:19--debug:SRC_DATASTORE_FREE:146.2GB
2012-10-1613:20:19--debug:SRC_DATASTORE_BLOCKSIZE:1
2012-10-1613:20:19--debug:SRC_DATASTORE_MAX_FILE_SIZE:256GB
2012-10-1613:20:19--debug:
2012-10-1613:20:19--debug:DST_DATASTORE:datastore1
2012-10-1613:20:19--debug:DST_DATASTORE_CAPACITY:267.2GB
2012-10-1613:20:19--debug:DST_DATASTORE_FREE:146.2GB
2012-10-1613:20:19--debug:DST_DATASTORE_BLOCKSIZE:1
2012-10-1613:20:19--debug:DST_DATASTORE_MAX_FILE_SIZE:256GB
2012-10-1613:20:19--debug:
2012-10-1613:20:19--debug:getVMDKs()-linux.vmdk###100:
2012-10-1613:20:19--info:Initiatebackupforlinux
2012-10-1613:20:19--info:CreatingSnapshot"ghettoVCB-snapshot-"forlinux
2012-10-1613:20:21--debug:Waitingforsnapshot"ghettoVCB-snapshot-"tobecreated
2012-10-1613:20:21--debug:Snapshottimeoutsetto:900seconds
2012-10-1613:20:22--debug:findVMDK()-SearchingforVMDK:"linux.vmdk"tobackup
2012-10-1613:20:22--debug:/sbin/vmkfstools-i"/vmfs/volumes/datastore1/linux/linux.vmdk"-a"lsilogic"-d"thin""/vmfs/volumes/
datastore1/backup/backup/linux/linux-_13-20-15/linux.vmdk"
Destinationdiskformat:VMFSthin-provisioned
Cloningdisk'/vmfs/volumes/datastore1/linux/linux.vmdk'...
Clone:94%done.
2011-12-2713:38:19--info:Removingsnapshotfromlinux...
2011-12-2713:38:19--info:BackupDuration:60Seconds
2011-12-2713:38:19--info:Successfullycompletedbackupforlinux!
2011-12-2713:38:21--debug:StorageInformationafterbackup:
2011-12-2713:38:21--debug:SRC_DATASTORE:datastore1
2011-12-2713:38:21--debug:SRC_DATASTORE_CAPACITY:267.2GB
2011-12-2713:38:21--debug:SRC_DATASTORE_FREE:146.2GB
2011-12-2713:38:21--debug:SRC_DATASTORE_BLOCKSIZE:1
2011-12-2713:38:21--debug:SRC_DATASTORE_MAX_FILE_SIZE:256GB
2011-12-2713:38:21--debug:
2011-12-2713:38:21--debug:DST_DATASTORE:datastore1
2011-12-2713:38:21--debug:DST_DATASTORE_CAPACITY:267.2GB
2011-12-2713:38:21--debug:DST_DATASTORE_FREE:146.2GB
2011-12-2713:38:21--debug:DST_DATASTORE_BLOCKSIZE:1
2011-12-2713:38:21--debug:DST_DATASTORE_MAX_FILE_SIZE:256GB
2011-12-2713:38:21--debug:
2011-12-2713:38:21--info:######
Final status: All VMs backed up OK! ######
2011-12-2713:38:21--debug:Succesfullyremovedlockdirectory-/tmp/ghettoVCB.lock
2011-12-2713:38:21--info:===========ghettoVCBLOGEND=============
3.3 Dryrun 测试
主要是先测试备份看是否有问题,使用Dryrun 模式来测试的话是不会产生备份档的
以下有几个比较需要知道的部份会有注解说明
在预设定情况下log都是存放在/tmp内,若是有需要保留log的话请参考「」来修改log存放处,避免重开机后log会被清除
# ./ghettoVCB.sh -f vms_to_backup -d dryrun
Logging output to
"/tmp/ghettoVCB-_13-23-26.log"
#备份LOG所存放的地方
Insufficient arguments .
2012 - 10 - 16
13 : 23 : 26
=== === === ==
ghettoVCB LOG START
=== === === ===
2012 - 10 - 16
13 : 23 : 26
2012 - 10 - 16
13 : 23 : 26
GHETTOVCB_PID
2012 - 10 - 16
13 : 23 : 26
VM_BACKUP_VOLUME
/ vmfs / volumes / datastore1 / backup / backup
2012 - 10 - 16
13 : 23 : 26
VM_BACKUP_ROTATION_COUNT
2012 - 10 - 16
13 : 23 : 26
VM_BACKUP_DIR_NAMING_CONVENTION
2011 - 12 - 27_13 - 23 - 26
2012 - 10 - 16
13 : 23 : 26
DISK_BACKUP_FORMAT
2012 - 10 - 16
13 : 23 : 26
POWER_VM_DOWN_BEFORE_BACKUP
2012 - 10 - 16
13 : 23 : 26
ENABLE_HARD_POWER_OFF
2012 - 10 - 16
13 : 23 : 26
ITER_TO_WAIT_SHUTDOWN
2012 - 10 - 16
13 : 23 : 26
POWER_DOWN_TIMEOUT
2012 - 10 - 16
13 : 23 : 26
SNAPSHOT_TIMEOUT
2012 - 10 - 16
13 : 23 : 26
2012 - 10 - 16
13 : 23 : 26
BACKUP_LOG_OUTPUT
/ tmp / ghettoVCB - 2012 - 10 - 16_13 - 23 - 26.log
#备份LOG所存放的地方
2012 - 10 - 16
13 : 23 : 26
VM_SNAPSHOT_MEMORY
2012 - 10 - 16
13 : 23 : 26
VM_SNAPSHOT_QUIESCE
2012 - 10 - 16
13 : 23 : 26
VMDK_FILES_TO_BACKUP
2012 - 10 - 16
13 : 23 : 26
2012 - 10 - 16
13 : 23 : 26
2012 - 10 - 16
13 : 23 : 27
#################################### ###########
2012 - 10 - 16
13 : 23 : 27
Virtual Machine :
2012 - 10 - 16
13 : 23 : 27
2012 - 10 - 16
13 : 23 : 27
VMX_PATH :
/ vmfs / volumes / datastore1 / linux / linux . vmx
2012 - 10 - 16
13 : 23 : 27
/ vmfs / volumes / datastore1 / linux
2012 - 10 - 16
13 : 23 : 27
VMX_CONF :
linux / linux . vmx
2012 - 10 - 16
13 : 23 : 27
VMFS_VOLUME :
datastore1
2012 - 10 - 16
13 : 23 : 27
VMDK ( s ) :
2012 - 10 - 16
13 : 23 : 27
linux . vmdk
#备份VM的大小
2012 - 10 - 16
13 : 23 : 27
INDEPENDENT VMDK ( s ) :
2012 - 10 - 16
13 : 23 : 27
TOTAL_VM_SIZE_TO_BACKUP :
#总备份的大小
2012 - 10 - 16
13 : 23 : 27
#################################### ###########
2012 - 10 - 16
13 : 23 : 27
###### Final status: OK, only a dryrun. ######
#告知测试是否OK,并告知此次只有dryrun
2012 - 10 - 16
13 : 23 : 27
=== === === = ghettoVCB LOG END
=== === === === =
以下为三种备份方式,请依需要设定
3.4 针对list (vms_to_backup) 中指定的VM虚拟机进行备份
./ghettoVCB.sh -f vms_to_backup
3.5 备份所有的VM虚拟机
# ./ghettoVCB.sh -a
3.6 排除list中指定的VM虚拟机不进行备份外,其他全部备份
vi vm_exclusion_list
#加入要指定排除的虚拟机名称
./ghettoVCB.sh -a -e vm_exclusion_list
&&&&推荐文章:
【上篇】【下篇】本系列文章会介绍云与备份之间的关系,包括:
(2)KVM 虚机备份和恢复
(3)云与备份
(4)OpenStack 与备份
(5)公有云与备份
1. 与备份有关的VMWare基础知识
1.1 VMware 虚机磁盘在 ESXi 宿主机上的文件
简单来说,虚机的每个虚拟磁盘由ESXi 宿主机上的三个文件组成(这里的虚机名字是 sammy-target-win-small,下面是其第一个磁盘对应的三个文件):
sammy-target-win-small.vmdk (配置文件,大小 633 字节)
sammy-target-win-small-flat.vmdk (二进制文件,大小
sammy-target-win-small-ctk.vmdk (二进制文件,大小 78694 字节)
第一个文件保存的是该磁盘的元数据,其中包括另外两个文件的信息
# Extent description
VMFS "sammy-target-win-small-flat.vmdk"
# Change Tracking File
changeTrackPath="sammy-target-win-small-ctk.vmdk"
第二个文件是 Extent description 文件,二进制数据保存在这个文件中。下面会介绍使用API获取该文件中数据的方法。
第三个文件是 CTK 文件。下面讲到 CTK 的时候再说。
1.2 快照(Snapshot)
虚机的快照是虚机在某个时间点的状态和数据,其中,状态是指虚机的状态,包括运行状态,配置等;数据是指虚机的虚拟磁盘中的数据。快照的基本操作包括:
创建快照(create)
删除快照(delete)
快照合并(consolidate)
恢复到快照(revert)
1.2.1 创建快照
对上面的虚机创建一个快照,除了快照定义文件以外,对该磁盘,新增了三个文件:
-rw-------
786944 Jul 11 10:55 sammy-target-win-small-000001-ctk.vmdk
-rw-------
28672 Jul 11 10:55 sammy-target-win-small-000001-delta.vmdk
-rw-------
428 Jul 11 10:55 sammy-target-win-small-000001.vmdk
第一个依然是 ctk 文件,第二个是 delta 文件,第三个是非二进制文件。然后再创建第二个快照,就成了这样子:
(RW = 读写,RO = 只读)
从数据的角度看:
(绿色部分是从虚机视角看数据;最下面的红框是 base vmdk 中的数据;中间的红框是 delta vmdk 中的数据)
现在可以简单总结一下 VMware 快照的特点:
快照保存虚机在某一个时间点的状态和数据
对一个虚机做快照,相当于将虚机当前的磁盘设为只读模式,然后创建 delta vmdk 文件,它将会接受新的数据写操作。在存在多个快照的情况下,之前的快照磁盘变为只读。
写损失:写的时候,遵循 Copy-on-write 机制,按照数据分块,当需要修改某一块中的数据时,先将它从父vmdk 中拷贝到 delta vmdk,然后再对它修改。
读损失:当读取某一块数据时,ESXi 需要判断从哪里去读:对于没有修改的数据块,从父 vmdk 读;对已经修改了的数据块,从 delta vmdk 读。可见,客户端的一次读操作,可能需要从不同的 vmdk 上读取数据。
delta vmdk 的大小不会超过 base vmdk 的大小,因为极限情况是所有的数据都被拷贝到delta vmdk 并且都没修改了。
因为快照会带来读和写损失,因此一个虚机不能有太多的快照。vSphere 限定一个虚机最多有 32 个快照,但是建议最多只有 2-3 个,而且快照的保留时间不超过一天。
1.2.2 删除快照
显然,快照只是内部数据,保存的是过去某时间点虚机的状态,对外部不可见,因此,删除快照不能影响虚机当前的状态和数据。因此,这里有三种可能:
(1)快照是基于原始虚机的:delta vmdk 中的数据会向 base vmdk 合并,然后 delta vmdk 被删除。(如下图中的s1)
(2)待删除快照在虚机的数据路径上:delta vmdk 中的数据会想父快照的 vmdk 合并,然后delta vmdk 被删除。(如下图中的s2)
(3)待删除快照不再虚机的数据路径上:不需要合并,直接删除。(如下图中的 s3)
现在可以简单总结一下删除快照的特点:
删除快照意味着快照之后的改变会被合并进快照之前的数据,因此,虚机再也无法回到所做快照之时的状态了。
删除快照过程包括两个异步的操作:从 Snapshot manager 中将快照删除,vmdk 数据合并。如果第一步成功而第二步失败,那么将有残留的 delta 文件被保留下来,这是就需要下面将介绍的手工合并操作。
删除快照可能会打来大量的数据写操作,这期间,虚机的性能会受到负面影响
删除快照有时候要花费很长的时间,特别是对于长时间存在的大容量磁盘的快照。 VMware 专门出了一个KB来让用户估计所需要的时间:
当删除所有快照时,自从 vSphere 4 Update 2 开始起过程有了优化,不再是重定向下一层一层地合并,而是各层都直接合并到 base disk。
1.2.3 快照合并(consolidation)
上面谈到了快照删除操作的数据合并可能会失败。这种失败会带来很多问题,包括不必要的磁盘空间占用,以及虚机性能下降。因此,当出现这种情况时,vCenter 会向用户提示需要做 consolidation 了。该操作会检查虚机当前所有的 vmdk 分层,将冗余的 delta 文件先合并再删除。
1.2.4 恢复到快照
恢复到快照操作也比较好理解,就是将虚机的 base vmdk 指向目标快照的 vmdk,其结果是自从目标快照创建后的一切改动都没有了。
1.3 VMware API
VMware 提供非常丰富的 API:
其中,我们可以将与与备份相关的API分为两类,一类是控制平面的API,它们主要用做管理 vSphere 虚拟化环境;另一类是数据平面API,它们用于操作虚机的虚拟磁盘。
1.3.1 VMware API 和 SDK
VMware 通过 Web Service 向客户端提供访问接口,这些接口可用于管理虚机和其他虚拟设施,包括数据中心(datacenter),数据存储(datastore), 网络(network)等。它还提供了包括Java, .NET, Python, Perl, REST, 以及 Ruby 等几种语言在内的 SDK。对于其他语言,则需要通过 SOAP 协议访问其 web service,是一种比较常见的用于C/C++语言编写 web service 客户端程序的套件。
详细情况请阅读&
1.3.2 VDDK 和 VADP
VDDK 全称是 Virtual Disk Development Kit(虚拟磁盘开发包),它能帮助开发人员创建访问虚机存储的应用。VDDK 基于 Virtual disk API。
Virtual disk API,即 &VixDiskLib,是一组操作 VMDK 格式的虚拟磁盘文件的函数。它的主要功能包括:
create, convert, expand, defragment, shrink, and rename 虚拟磁盘文件
创建 redo logs 和删除 vmdk 文件
访问 vmdk 文件中任意数据,以及读取元数据
连接到远端 vSphe 存储,使用高级的传输方式,包括 SAN (备份程序所在的服务器能够直接通过 FC 或者 iSCSI 和虚机磁盘所在的存储连接),hotadd (虚拟磁盘附加到备份程序所在虚机成为其一个磁盘) 和 LAN (备份程序通过 LAN 访问虚拟磁盘)。
VADP 全称是 VMware Storage APIs - Data Protection(VMware 存储API-数据保护),它使用 virtual disk API 和部分 vSphre API 来创建和管理虚机的快照,支持全量和增量备份。&
1.4 CBT (Changed Block Tracking 块修改跟踪)
&CBT 是 VMware 在 vSphere 4.0 版本引入的为了实现增量备份的一个功能。VDAP 使用该功能,使得基于它开发的各种虚机备份应用能够做到增量备份。
相对于全量备份时将vmdk 的全部数据块都保存下来(左图),基于 CBT 的增量备份只保存自从上次备份以来的发生了变化了的数据块(右图)。ESXi 为每个开启了 CBT 的虚机的虚拟磁盘都创建了一个 ctk 文件,它用于保存变化块的元数据。该功能将会对磁盘带来一点性能损失,因为,不使用的时候,可以关闭它,但是它对备份带来的好处是显而易见的。
获取 CBT 变化块的函数的定义为:QueryChangedDiskAreas(snapshot, deviceKey, startOffSet, changeID)。其中,
snapshot 代表当前的快照,也就是&变化&时间段的后端点;
deviceKey 是目标虚拟磁盘的 device ID;
startOffSet 是开始获取变化块的offset;
changeID 是指&变化&时间段的前端点,即老的快照的 changeID。
其结果类似 &(, 65536),(, 65536),(, ),(, 65536),(, 65536)&,每项的格式为 (offset,length),表示一个发生变化的数据块。
1.5 Quiseced Snapshot 和 VMware Tools
&虚机快照按照不同的一致性可以分为三种:
崩溃一致快照(crash-consistent snapshot):当虚机上的应用还在运行,IO 还在进行时进行快照会得到这种快照。它相当于电脑突然断电了磁盘时的状态。
文件系统一致快照(file-system-consistent snapshot): 在做快照之前,虚机的文件系统被暂时冻结,内存中的脏数据都被刷进磁盘;在快照做完之后,文件系统被解冻。此时的快照是文件系统一致的。
应用一致性(application-consistent snapshot):在做快照之前,应用被暂时冻结,内存中应用的所有数据都被刷到磁盘,在快照做完之后,应用被解冻。
默认的快照是第一种,要得到后两种快照,需要增加相应的步骤。其实现方式主要可以分为两种:
在较新的 Windows 客户机上,Windows 提供了 VSS(Volume Shadow Copy Service) 服务,它可以通过 requester-writer 方式来实现有冻结需求的应用和文件系统在快照之前进行冻结和快照之前进行解冻。Microsoft VSS 服务能够通过协调商务应用(比如SQL Server,Exchange server 以及 Oracle 等),文件系统,备份应用,快速恢复应用,以及存储硬件等来提供一致的阴影复制(shadow copies)。
在老的 Windows, VMWare 提供了 SYNC 驱动; 在 Linux 系统上,VMware 提供了 vmsync 内核模块来实现文件系统一致性快照。
在非 Windows 客户机上要实现应用一致性快照的话,需要编写具体应用对应的脚本,在调用后对应用进行冻结或者解冻。
那 VSS 服务,SYNC driver, vmsync 内核模块以及自定义脚本由谁来调用呢?VMware 提供了 VMware Tools,它是一个独立的程序,有不同的操作系统版本,它需要被安装在客户机内。以 VSS 为例,VMware tools 承担 VSS Requester 的角色,在做这种快照之前和之后,它调用 VSS 服务,VSS 服务又调用已经注册的 VSS Writer 来执行相应的操作。下图是个简单示例:
后面两种类型的快照被称为 quiseced snapshot,包括 filesytem-quiseced snapshot 和 applicaiton-quiseced snapshot。其完整的流程大概为:
用户发出 quiesced snapshot 创建请求给 vCenter,vCenter 给虚机所在的 ESXi 的 hostd 服务发出指令
ESXi 上的 Hostd 将请求传给客户机内的 VMware tools
VMware tools 以 VSS Requester 的身份通知 VSS,VSS 再通知已经注册的文件系统以及各应用的 VSS writer 执行各自的数据下刷和冻结操作(应用的暂时冻结不能超过60秒)
一旦完成,VMware tools 将就结果告诉 hostd
Hostd 再执行快照操作
操作结束,按照前面的顺序再对文件系统和应用进行解冻
再说一下 VMware tools。在 Windows 系统上,它的安装包里面包括了很多的驱动,这些驱动能增强虚机的用户体验,比如鼠标更加平滑,分辨率更高,声音效果更好等等;除了这些驱动以外,还有VSS support,它是 VMware tools 和 Windows VSS 之间交互的桥梁。要创建 quiseced snapshots,这项必须被安装。
注意安装 VMware tools 的时候,现在 VWC 里面选择 Guest-&Install/Upgrade VMware Tools,然后登录虚机,找到前面步骤所挂接的磁盘,再双击安装程序开始安装过程。
在 vCenter 客户端中,用户可以选择是否创建 quiesced snapshot:
不同的情况下,有如下几种可能结果:
没选择,或者选择了但是客户机内没有安装 VMware tools:创建 crash-consistent snapshot
选择了,客户机安装了 VMware tools,有 MS VSS 但没有应用 vss writers,或者安装了 vmware vmsync driver:创建 filesystem-consistent snapshot
选择了,客户机安装了 VMware tools,有 MS VSS,也有应用 vss writers,或者编写了应用一致性操作脚本:创建 application-consistent snapshot
1.6 虚拟磁盘传输模式(Tranport modes)
这个传输模式是指虚机或者虚机快照的虚拟磁盘中的数据被传送到备份程序的传输方式。VMware 在不同的环境中支持使用不同的传输模式,好的传输模式能大大增强传输传输效率。
1.6.1 SAN 模式
这种模式要求 VMware 备份程序所在的物理服务器能够通过 FC/iSCSI/SAS SAN 网络访问到虚拟磁盘。对备份来说,这是效率最高的传输模式。这种传输模式下,VADP API 从vCenter 或者 ESXi 上获取 VMFS LUN 的信息,然后再基于这些信息从 VMDK 所在的 FC/iSCSI/SAS LUN 中直接读取数据。下图是一个示例:
要使用这种模式:
备份程序需要运行在物理服务器之内,该服务器必须能够通过SAN网络访问到VMFS LUN。
SAN 模式对备份来说是最佳选择,但是对恢复来说却不是。
1.6.2 LAN(NBD) 模式
这种模式下,ESX/ESXi 主机从其存储中读取数据,再通过 LAN 网络发到备份程序所在的主机。这种模式支持任何类型的存储。备份程序可以运行在一个虚机之内。需要的时候,可以使用 SSL 加密(NBDSSL)。
1.6.3 HotAdd 模式
当备份存储运行在虚机之内时,可以利用 ESXi 的 SCSI HotAdd 特性来将虚拟磁盘直接挂在到该虚机上成为其一个本地磁盘。这种模式只能用于 SCSI 模式的虚拟磁盘,而不适用于 IDE 类型的。
如果虚机的快照有两个虚拟磁盘,当备份程序在其所在的虚机(proxy)上使用 hotadd 模式连接到第一个磁盘后,你可以在 proxy 上看到该磁盘以及它的两个分区:
Disk /dev/sdc: 12.9 GB,
255 heads, 63 sectors/track, 1566 cylinders, total
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x836df02a
Device Boot
HPFS/NTFS/exFAT
HPFS/NTFS/exFAT
然后 proxy 就可以象读取自己的磁盘一样从该磁盘读取文件了。简单来说,hotadd 和你手工把一个快照的某个vmdk 挂接到另一个运行着的虚机的原理和要求是一样的。你也可以通过手工的方式来确定hotadd是否能成功。hotadd 和 nbd(ssl)都走的是以太网,但是区别在于,nbd 走的是管理网络,而这种网络的带宽往往有限;而 hotadd 走的是数据/存储网络,而这种网络往往被单独出来,而且带宽往往比较大。
关于各种传输模式的概念,使用,要求和最佳实践等,请阅读 MVware 的相关文档。
1.6.4 传输模式的选择
& &备份程序都是调用 VDAP 的 Connect/ConnectEx 接口来建立和 vmdk 的连接的。如果不指定传输模式的话,在这个过程中,VADP API 会按照顺序,依次尝试 san,hotadd 和 nbd 三种模式,直到有一种成功或者全部失败。当有成功时,客户端程序可以调用 GetTransportMode() API 返回该连接所使用的传输模式。当然,客户端程序也可以指定特定的传输模式。在操作结束后,客户端程序需要调用 Disconnect API 来断开已经建立的连接。
2. 传统VMware环境的备份软件的基本架构
3. 简要 VMware 虚机镜像备份和恢复流程
3.1 备份流程
简要过程:
备份程序使用 vSphere API 建立和虚机的连接,并备份虚机的配置信息
使用 vSphere API 创建快照,往往会创建 Quiseced 类型的快照,来保证应用或者文件系统一致性
使用 VDDK API 建立和快照的第一个磁盘的连接,连接的传输模式将会是 san/hotadd/nbdssl/nbd 中的一种。
&对该磁盘,调用&QueryChangedDiskAreas 接口,获取它与上次备份时磁盘之间发生了变化的数据块列表
调用 VDDK API,读取发生了变化的数据块的内容并写入存储中的备份
依次处理其它磁盘
所有磁盘处理完毕后,删除快照,并断开与虚机的连接
利用快照功能,保存虚机在某个时间点上的状态和快照,很短时间之后虚机就可以照常运行。备份结束,快照会被删除,这样虚机的性能也就不受到影响了。
利用 VADP API,只读取两次备份之间磁盘上发生了变化的数据块。当然了,第一次是必须做全备份。
只将变化的数据块写入后端存储,也就是说后端存储必须负责维护第一次全备份和以后每次delta备份之间的关系。其实相当于将 VMware 的 Snapshot manger 功能挪到了备份软件的后端存储。
3.2 恢复流程
简要过程:
备份程序使用 vSphere API 建立和待恢复虚机的连接,并恢复虚机的配置信息
使用 vSphere API 创建快照,往往会创建 Quiseced 类型的快照,来保证应用或者文件系统一致性
使用 VDDK API 建立和快照的第一个磁盘的连接
&对该磁盘,调用&QueryChangedDiskAreas 接口,获取它与上次备份时磁盘之间发生了变化的数据块列表
调用 VDDK API,从所存备份中读取变化块的数据,再写入快照磁盘的相应位置。该磁盘的所有变化块写入完成后,关闭与磁盘的连接。
依次处理其它磁盘
将虚机revert到已恢复快照
删除快照,并断开与虚机的连接
在操作前,需要确保虚机处于关机状态
同样也利用快照,然后再利用 API 获取本次快照和上次备份所对应快照之间发生变化了的数据块,再使用已保存的备份中的数据将发生了变化的快照磁盘中相应的数据块覆盖掉
快照的磁盘 vmdk 文件都被恢复后,执行快照恢复
结束后,删除快照
虽然备份时上传的是 delta 数据块,但是在做恢复时,需要读取全部的数据块。
参考资料:
阅读(...) 评论()