Need to migrate File Systems to new Luns

that does require a Replicator license though

OT:

that's probably  what I've look for archive old data in slower disks (SATA) or different Celerra....

What about DR restore?

In my company, we'll do cold restart in case of disaster, restoring via ndmp (using a Datadomain appliance in VTL mode) all of our cifs datas in a different Celerra located in a DR site (in housing in HP Italy).

What If I'll use FMA (archiving old files in SATA disks in the same production Celerra)?

Can I backup this old datas once (via ndmp) and restoring them in case of disaster?

What about stub files in a non-archived file systems?

thanks a lot for your help

Rainer_EMC ha scritto: 2) nas_pool -extend of system_defined pool in order to use the new luns there is no need to manually extend a system pool - when the Celerra discovers new LUNs they become automatically eligable for the system pool that matches their profile and they are "pulled in" on demand for the rest of the procedure - I would suggest to look at using multiple checkpoints and differential copies to minimize the downtime. Or - if you have a the license - at using full-blown Replicator, which does this automatically Rainer

Thanks Rainer,

Yes I've got Replicator V2 license and I'll probably use It.

thanks a lot to everybody for your help!

Hi Rainer,

probably Lun migration is the less disruptive solution and:

1) Yes I'll use the same RAID criteria

2) Yes I'll use the same number of disks

3) NO, I'll not create the exact LUN SIZE

about the third point, I'll waste so much space... that's why I cannot use Lun migration

no problem there - just create two LUNs per RG of the same size as the old ones and two with the remainder that you can later use to extend the old fs or for new ones

no wasted space there

Well – backup and DR restore typically depends on your DR planning and what / where your archive target is

You could use NDMP backup with a setting that backups the archive target just like there was not stub (basically then NDMP does a passthrough like a client would).

That’s certainly feasible for a “fast” archive target like another Celerra share on the same or a different Celerra.

In this case the amount and time for a full backup stays roughly the same.

Other customers just use a NDMP backup that backups just the live data and the stubs and then either:

- Don’t backup the archive at all – since its on a different and maybe replicated system

- Backup the archive – but on a less aggressive schedule since archived files never change

Or they archive to platform that has builtin replication and self-healing like Centera or Atmos that typically never get backed up.

That has the advantage that your regular full backup will be smaller and faster.

Since you already have a Data Domain another option would be to archive to that DD in file mode – there the adavantage is that typically any archived files you send to the DD are already stored there from previous backups so the archive costs you very little space (as long as the backup holding the file isn’t expired and purged)

Hope that helps

Rainer

Unluckly my Datadomain (DD565) is running @ very low space in this period (and I don't like its performance for cifs purpose)

Since our business decided that our DR plan involves a COLD RESTART (restoring 48 hr before datas) we probably need to backup production and archived data and the same frequency.... Since Celerra replicator permits only to have a sync as a time of 24 hrs before.

I think archiving to a DD would be done via NFS and not CIFS

Also the workload to the archive store is very different from the workload of a production file system – its mostly sequential write and read of decent-sized files

If you need to restore state of 48 hours before a DR – why don’t you setup checkpoints on the DR replication system for that ?

Then you could revert that DR systems file systems to that two days ago checkpoints and then copy that back to a repaired/replaced production system

Rainer

That's a very good idea. I could propose it to our business (hoping that I don't need so much disk space in order to keep this checkpoint....)

THANKS A LOT RAINER!!!!