Backup/Restore of a large Linux server

[rreich]

Hello,

I am having issues backing up and restoring a large (115TB single Data Set) Linux server using the Linux agent managed by Veeam B&R. With my previous backup product I had broken down the backup jobs into smaller 10-15 TB jobs and run them simultaniously to get the throughput I needed. The first issue is that with the Veeam Linux agent I cannot run more than one job at a time and cannot get the throughput needed in that one job. My second issue is that when testing a file level recovery, Veeam is unable to mount any size backup files as even a 20 GB test file is returning a "The destination file system does not support large files" error.

Am I doing something wrong here or is this not even possible with Veeam? How do others handle file level backups of servers of this size with Veeam? Reducing the server size or changing the storage into smaller drives is not an option.

FYI: I am not a Linux admin and my kowledge of that OS is limited . The Linux team here has helped with testing but are out of ideas as well.


Thank you,

[HannesK]

Hello,
I moved the topic to the "Veeam Agent for Linux" forum.

For the speed: which speed do you get right now with "entire computer" or "volume level" backup?

For the file level recovery error message: I suggest to open a support case and post the case number here.

Thanks,
Hannes

[nielsengelen]

Could you give more information on the OS, the partitions and which VAL version you are using? In terms of speed, which throughput are you seeing and how is the backup job set up (volume based, entire computer, file based) and what is the target? Which is the bottleneck according to the backup job?

[rreich]

The OS is RHEL 6.4, they are using LVMs of 115TB and 35TB, and the agent version is 3.0.0.865-2.6.32_131.0.15. The throughput I saw in my tests (file level backup) was similar to what I get from a single job in Data Protector. Depending on what is being backed up (file size) I'd get anywhere from 150-300 GBs per hour. The bottleneck is always the source but more so the reading of the files. With system resources to spare, running simultaneous backups to get multiple steams was the best solution I could find. That is not an option with the Veeam agent and running full backups for 30 days isn't ideal.

[HannesK]

Hello,
yes, file level backup is slower than block level backup... could you test with volume level backup or entire computer?

Thanks,
Hannes

[rreich]

Thank you for the quick replies.

Two weeks without backups is long enough so we have reverted back to Data Protector. If we do volume level or entire computer backups how will that affect indexing and file level restores? Do volume and entire computer backups process multiple streams simultaneously? I can run partial tests next week but can't really run a 30 day entire computer backup test (which is about how long a file level backup would take based on previous tests).

[HannesK]

Hi,
there is no impact on indexing and file level restores. Actually we work completely different than Data Protector and most customers don't even use indexing (only on file-servers where helpdesk gets questions like "I don't know what I deleted but it could be something like ..."

Depending on hardware I have heard about speed between 300-800MByte/s from customers which would mean that a full backup would probably take around two days for you. Incrementals should be a fraction of that time with changed block tracking.

Best regards,
Hannes

[rreich]

Thank you for the reply, Hannes. I should be able to run some tests based on your suggestions the week after next and will post my findings.

Regards,

[rreich]

It's been quite some time but I now have a week long window to revisit this. Unfortunately the storage associated with this system is not only extremely slow, it's also getting hit pretty hard. Based on partial tests it would take close to 3 weeks for a full backup. Due to the time needed to run a volume level or entire computer backup, I have just run a few file level backups in order to test restores. The file level backups appear to run fine but when I try to test restores the FLR appliance fails with the message "Destination file system does not support large files”. The backup is only a few GBs, could this issue be related to the size (115TB) of the source logical volume and a VMWare volume size limitation when it tries to mount for a restore? I have other questions too:

1.Is mounting the backup through VMWare the only option for restores?
2.If so, is the max file size for VMWare 64TB? (VMWare version 6.7)
3.Again "if so", what are my options for a restorable backup of a 115TB Logical Volume?

Thank you for the help and education!

[PTide]

Hi,

1. If you want to perform FLR from VBR console then yes, currently it's the only option.

We plan to make it possible to not utilize VMware infrastructure for FLRs at all in future releases.

2. It might be, however you need to contact support for investigation.

3. You can also go in CLI on the linux host, and perform FLR from there (run 'veeam' and select "[R]ecover files").

Thanks!

[rreich]

Thank you very much!