Tag: GFS

Posted on

NAS Backup – GFS to TAPE – Part II

In the previous article, we saw how to operate on backup jobs to obtain Fulls that can be used to create a GFS retention policy when the destination of the jobs is a tape.

In this second article, we find out how a similar result can be achieved by copying tapes.

Note1: A second tape library must be present in the DataCenter to pursue this protection process.

Note2: The most common use case for Copy-Tape is to migrate data contained on tapes from an old technology (LT06) to a new one (LTO9), since the new technology would not be able to natively read the data contained on the old tapes.

There are two steps that will enable us to achieve our goal:

  • Step 1: Creation of a tape pool afferent to the second library.
  • Step 2: Tape copy job.

Stage 1

The creation of the Media Pool (image 1), will need to be customized by setting:

    • The use of a new tape for each copy session (image 2).
    • Setting a retention that for that tape group coincides with that required by the GFS policy (image 3).

Picture 1

picture 2

Picture 3

Note3: A 4-week retention was set in Image 3, which addresses the need to keep the full weekly for 1 month.

Note4: Image 4 highlights the possibility of implementing a Vault policy for tape storage.

Picture 4

PHASE 2

From the VBR GUI by selecting the tape to be copied with the right mouse button (image 5), the copy command can be initiated.

Picture 5

The simple next steps shown by images 6,7,8 and 9 show how to complete the copying operation.

Picture 6

Picture 7

Image 8

Image 9

Latest notes:

  • Documentation to refer to in order to know how many resources it is essential to allocate to the various components is available at the following link.
  • Automation of copying can be done through scripts in powershell.
  • Copy to Tape does not consume capacitive licensing but refer to the following link, Capacity Licensing item to know all the details.
Posted on

NAS backup – GFS to Tape – Part I

Many customers and partners ask whether it is possible to implement a GFS (Grandfather – Father – Son) type of protection policy when the data to be protected pertains to a NAS (Network network-attached storage) and the destination is a tape library.

Such automation with the current version of Veeam Backup & Replication(VBR) 12.1 is not yet available, something that is already possible when the data source is a backup of VMs and Physical Servers.

In this first article, I will help you achieve that goal by taking advantage of VBR ‘s great flexibility in creating backup jobs.

Note1: In the next one I will illustrate how to make GFS copies by exploiting a little-known feature of
VBR
, the Tape Copy.

Flexibility of Backup Jobs:

a. VBR manages tapes using an architecture that is based on:

  • Media Pool(MP) are the logical containers of the tapes and can pertain to one or more Backup jobs (in our scenario we will create one MP per Job).
  • Media Set(MS) identifies the restore points present on the tape (in our scenario we will create one MS per Backup job per single tape).

b. The proposed solution is to create weekly, monthly, and annual backup jobs in full mode. These backups should be created on a specific date and the backups should reside on tape pools created for the purpose.

Let’s see step by step how to proceed:

c. Creation of weekly and monthly Media Pools(MP).

Picture 1

From image 2 it is important to note that a new tape will be used for each backup session.

picture 2

Image 3 shows how to set the retention, which in this scenario is 4 weeks.

Picture 3

For the Monthly MP, the same procedure is used, changing the retention to 12 months (see images 4,5,6).

Picture 4

Picture 5

Image 6 shows that the retention for Full Months is 12 months.

Picture 6

d. Creating Backup Jobs

Picture 7

image 8

Image 9 highlights the scheduling of the Backup job.

The assumption is to make n full backup jobs for each GFS policy.

Our example scenario shows the first week’s job (blue arrow) with weekly retention (green arrow). For the second, third, and subsequent week, we will proceed in a completely similar way, replacing the value first with second, third, etc. under “Run the full backup automatically.”

Image 9

Image 10 highlights (orange arrow) that no incremental backups will be initiated.

image 10

The same steps must be implemented to create monthly type GFS backups, in the example I set the backup job start on the 4th Saturday of the month (image 12 – blue arrow).

Image 11

Image 12

Image 13

Note 2:

  • Licensing counts licenses per individual Backup job (verision 12.1).
  • Conduct tests to make sure the scenario matches your needs. Get help from Veeam support.

In the next article, we will see how to use the Tape Copy feature.

Posted on

XFS – Resize the immutable file system

In the Veeam Backup & Replication environment, it may be necessary to expand the allocated space of a Linux repository.

In my environment, there is an Ubuntu 22.04 server to which a second disk(dev/sdb) was added, formatted as xfs, and made available as mount point /mnt/backup/ .

The server is used in hardened repository mode (immutability)
(https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html?ver=120).

Let’s look at the simple procedure:

  • The packages to install are cloud-guest-utils and gdisk:
    “sudo apt -y install cloud-guest-utils gdisk”
  • To find out the structure of the file system use the command:
    “sudo lsblk”

      • The result shows the sizing, and mount point of Ubuntu server file system:
        NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
        sda 8:0 0 16G 0 disk
        ├─sda1 8:1 0 1M 0 part
        ├─sda2 8:2 0 1.8G 0 part /boot
        └─sda3 8:3 0 14.2G 0 part
         └─ubuntu–vg-ubuntu–lv 253:0 0 10G 0 lvm /
        sdb 8:16 0 100G 0 disk. └─sdb1 8:17 0 80G 0 part /mnt/backup
        sr0 11:0 1 1024M 0 rom
  • To find out if the file system has additional space to allocate:
    “sudo growpart /dev/sdb 1”

    • The result shows the item changed
      CHANGED: partition=1 start=2048 old: size=167770079 end=167772126 new: size=209713119 end=209715166
  • The final command that widens the file system is: sudo “xfs_growfs /mnt/backup/”
  • Check the result through the command already seen: “sudo lsblk”