Avamar 7 FLR and LVM Full disk support ?

none of my Linux servers can use FLR -

seems it does have support for it, but only if it is configured in a specific way.

it seems none of my Linux have ext2 or ext3 formatting -

so I do a once a week vm backup (so I could rebuild)

and a daily backup like a physical server.

this is the list  of items that would prevent you from doing FLR.

File-level restore limitations

The following limitations apply to file-level restore as described in “Restoring specific

folders or files” on page 86:

◆ • Unformatted disks

• GUID Partition Table (GPT) disks

• FAT16 filesystems

• Extended partitions (that is, any virtual disk with more than one partition or when

• Encrypted partitions

◆ ◆ ◆ Manager (LVM):

• Only ext2 and ext3 formatting is supported

you must be looking at really old release notes, ext4 is fully supported.  I am using FLR with RHEL5 and RHEL6..works like a champ.

RHEL or other flavors ? what errors are you getting ?

my apologies that list was from version 6

and I have upgraded to version 7

but I still cannot FLR my unix VM backups. never have been able to.

rhel5

or

ubuntu

can't help you with Ubuntu but we got the same on RHEL, need to set partition type to Linux LVM (8e)

fdisk /dev/sde
p ( print partition)
t ( type)
1 ( partition number)
8e ( for type)
p ( print to make sure it changed from 83 to 8e)
w ( write change)

dynamox wrote: can't help you with Ubuntu but we got the same on RHEL, need to set partition type to Linux LVM (8e) fdisk /dev/sde p ( print partition) t ( type) 1 ( partition number) 8e ( for type) p ( print to make sure it changed from 83 to 8e) w ( write change)

Hi Dynamox, your reply is OK but I was originally talking about a full disk LVM (the PV is created on the whole disk) like this example :

# fdisk -l /dev/sdc Disk /dev/sdc: 2147 MB, 2147483648 bytes 67 heads, 62 sectors/track, 1009 cylinders Units = cylinders of 4154 * 512 = 2126848 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x810c8f4f    Device Boot      Start         End      Blocks   Id  System

Here is what we do to resize disks in our virtual environment :

blockdev --rereadpt /dev/sdx pvresize /dev/sdx lvresize etc....

It's both much easier and not disruptive than using partition-based LVM .

I think it's all about the lack of partition but I'd like a confirmation : Using partition-based LVM is really a loss in virtual environment as you're limited to 3 extents of a disk (adding a partition to the extended disk and add it to the LVM each time) before you cannot use FLR anymore (over 3 partitions you have to use extended partition which is not supported by FLR).

i am not a system admin, so i have no control how my Linux guys are setting things up. I do have to make sure they can recover the data

I have to make sure I can recover the data too.

that is why I have to do linux vm backups 2 ways

once a week as a vm

daily as a physical.

once we made the change i provided above (which was online, non-disruptive), we are no longer getting the UUID error message and can successfully restore using FLR.