Will SSD for metadata will accelerate my TSM scanning backup time?

The incremental backups will benefit from having metadata on SSD, as it will improve the performance associated with the treewalks.

Thank's Scott for the reply,

We buy 8 ssd and force all copy of metadata on SSD and did not see improuvement when scanning with TSM (3 Gfiles "already backup"). Should we have to put some parameters in TSM to speed up the scanning process of the Isilon with SSD?

The only time we see improvement (half the scanning time) is when we scan with the TSM  "no backup security" option???

Hi Alain,

SSD disks can be used for three functions:

Metadata read acceleration: creates a copy of metadata on SSD disks for read acceleration.

Metadata Read/write acceleration: Requiring four or six times more space, it can mirror metadata reads and writes to SSDs.

Data on SSDs: you can redirect only particular files to SSDs disk.

In conclusion, SSDs disk can improve the performance of backup. However, if you just intend to accelerate the performance of backup, you could add a backup accelerator which has four 4GB/s FC ports for connections to tape libraries and allow to offload backups from the storage nodes.

Well,  all our metadata are now on SSD. We lauch the backup on a smb share directly on the backup server so "the list file" is localy. If we scan without the "permission" option, it take 1h. For regular scan it take 3h30. both backup server and isilon cluster are cpu and network idle???? Who is slowing the scan time???

Is that the same subset (3 Mio files) you mentioned earlier? -- if so, no improvement. (Check SMB params,

max request size, packet signing etc).

Or is it the original full set now (30 Mio files)? -- substantial improvement, 10x!

In the latter case, further speedup would be possible only by

enhancing the level of parallelism: follow Stefan's pointer.

Cheers

-- Peter

Well sadly 1h is only for the subset of 3 mio files. I wonder if I can change the setting on my TSM server for the filelist your talking stefan " (that's the reason why IBM works with a shadow file on o GPFS to have that info locally which makes thing much faster)."

Is there a TSM specialist at EMC who can help us with that slow tree walk???

interesting solution, one good thing about this is that typically NDMP can be restored to like to like platform. You can't take NDMP backup from NetApp and restore it on VNX.

I am curious how well massive storage product will scale with 200-300 million inodes.

File system with millions of inodes …i can already see that simulator choking. If your RTO is 2 years that’s probably an ok solution ☺

Side note:

OneFS NDMP backups can be restored to non-Isilon NFS shares

via  the virtual nodes/simulator, single node cluster suffices.

Mount the target to something like /ifs/nfsrestore

on a virtual node and redirect the NDMP restore there.

(mount point must be under /ifs; i.e. /tmp/nfsrestore will not work.)

Cheers

-- Peter

That was not the point I wanted to make. For example, it's a simple means to restore some high-priority data way before the physical Isilon gets repaired/replaced, if you are in such a disaster situation with a single Isilon.

With gazillions of files we are always struggling. If one makes that virtual node restore path a part of the regular DR solution, one needs to plan accordingly, of course.

And, it will be the ingest performance of the other NFS server that determines the restore speed, not so much the capability of the virtual node...

Cheers

-- Peter