The requested operation could not be completed due to a file system limitation (Asigra)

On trying to backup an Exchange database using Asigra we were seeing the message “The requested operation could not be completed due to a file system limitation” after about 4 hours of backing up. This was an Exchange database backup (non VSS), and it was copying the database to the DS-Client buffer.  The Exchange database was 1TB+.  The DS-Client was running on Windows 8.1.

The message:

The requested operation could not be completed due to a file system limitation  (d:\buffer\buf\366\1\Microsoft Information Store\database1\database1.edb)

Solution:

There is a default limitation with the Windows file system for supporting large files. We had to reformat the buffer drive on the DS-Client using the command:

format d: /fs:ntfs /L /Q

After making this change we no longer experienced the error message and backups completed successfully.

Interested in learning how Managecast can help your business with its cloud backup and disaster recovery solutions? Fill out this form for more information!

Asigra reporting “cannot allocate memory” during seed import

We have DS-Systems running on Linux and we connect the Windows Seed backups to a Windows 7/8.1 machine and then use CIFS to mount the Windows share to Linux. The command we use on Linux to mount the Windows share is:

mount -t cifs //<ipaddress of windows machine>/<sharename> -o username=administrator,password=xxxxxx /mnt/seed

We were importing some large backup sets with millions of files and started noticing “cannot allocate memory” errors during the seed import process. When the import would complete it would indicate that not all files were imported.

At first we thought this was an Asigra issue, but after much troubleshooting we found this was an issue with the Windows machine we were using and was related to using the CIFS protocol with Linux.

A sample link to the issue we were seeing is: http://linuxtecsun.blogspot.ca/2014/12/cifs-failed-to-allocate-memory.html

That link indicates to make the following changes on the Windows machine:

regedit:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement\LargeSystemCache (set to 1)

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size (set to 3)

Alternatively, start Command Prompt in Admin Mode and execute the following:

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v “LargeSystemCache” /t REG_DWORD /d 1 /f

reg add “HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” /v “Size” /t REG_DWORD /d 3 /f

Do one of the following for the settings to take effect:

Restart Windows

Restart the Server service via services.msc or from the Command Prompt run: ‘net stop lanmanserver’ and ‘net start lanmanserver’ – The server may automatically restart after stopping it.

After we made these changes the memory errors were resolved!

Asigra slow seed import

We recently discovered that Asigra DS-System v13.0.0.5 seems to have a serious problem with importing seed backups. This problem exposed itself as we attempted to import 5.5TB of seed data. We then performed additional testing by backing up a small Windows 2008 server. The seed backup was a little under 3GB. On v13.0.0.5 the seed import took 55 minutes. On the same infrastructure, the same server seed backup imported into a v12.2.1 DS-System in less than 3 minutes.

In addition we are also seeing the error “cannot allocate memory” during the seed import process even though we have tons of free RAM and disk space.

We have notified Asigra and they are attempting to reproduce the problem.

Update 12/4/2015

In testing, and working with Asigra, we have found that if you create the seed backup without using the metadata encryption option then the seed import speed is acceptable and imports quickly.

Update 12/8/2015

Asigra released DS-System v13.0.0.10 to address this issue. Testing shows it does indeed solve the speed issue. Thanks Asigra!

Asigra BLM Archiving – Align the value of your data with the cost to protect it

Years ago, we treated all data as being equal. All data originated on one type of storage and stayed there until it was deleted. We now understand that not all data is created equal. Some types of data are more important than others, or accessed more frequently than others. Backup Lifecycle Management (BLM), defines the BLM concept where data is created on one storage system, then migrated to less expensive storage systems as it ages.

Asigra Backup Tiers

BLM-graphic

For example:

Data that is 2 minutes old is highly valued.
Data that is 2 months old may be of interest but is not as highly valued.
Data that is 2 years old may be needed for records but it is not critical to the daily functioning of the company.
DS-System – Primary Storage-Business-Critical Operational Data

Business Critical Operation Data contains the files, databases, email systems, etc., that are needed for operations on a day-to-day basis. All data that is critical to business operations data should be stored in the DS-System Tier.

BLM Archiver – Policy based retention of older data

Large file servers or other large repositories of potentially older data can be moved to BLM, Cost savings are the primary benefit by allowing storage of older data and automatic retention policies that move aged data into the lower cost tier. BLM Archiver can also be leveraged to provide storage of past generations of data while keeping the most recent version in business critical DS-System.

Managecast will help with analyzing your data to determine a protection method to best suit your recovery requirements and budget. There are many options to protect business data by strategically identifying the value and aligning the cost to protect it.

BLM Cloud Storage – For Low-Cost, Rarely Retrieved Files

Typically for files older than 1 year, BLM Cloud Storage is a method to cost effectively protect large data sets that are still needed for reference, compliance, and infrequent restores.

Files older than a specified age can be selected to move to long-term cloud storage and are generally grouped in large chucks from 250GB on up to multiple terabytes and then copied to long-term archive on disk.

Customers can utilize Amazon S3 cloud storage or use Managecast Enterprise Cloud Storage