On Thu, Jun 23, 2011 at 7:07 AM, Stefan Folkerts <stefan.folke...@gmail.com> wrote:
> The trick is that the backup in TSM IS the migrated version of the file, so > when you migrate you backup. > It's been awhile since I've used HSM on Unix, but (unless something has changed) I disagree with this statement. In Unix HSM (which is the only one I've used), migrated files and backed up files are not the same thing. a migrated file is still at risk of loss. Migrated files use different rules than backed up files, and as such need a separate backup in order to ensure you're protected. The most prudent way to do this safely is to ensure that you have TSM set to require a file be backed up prior to being migrated (set MIGREQUIRESBACKUP in mgmt class that you're using for HSM). This defines that a file will not be migrated until it has previously been backed up. HSM data is independent of backup data, can be kept in differing storage pools if desired, and do indeed take up their own space. As long as you have this set, and run regular incremental backups, you'll have a good backup of the data in the event the migrated file gets deleted/corrupted/lost. You won't need to worry about the migrated state of your files - TSM will keep the full file backed up, regardless if it is resident or migrated. regards, Paul This is different in Windows where a backup and a migrated file are two > different things because HSM for Windows is archive based and therefor not > as nice. > HSM for Unix rocks! > > On Thu, Jun 23, 2011 at 2:05 PM, Mehdi Salehi <ezzo...@gmail.com> wrote: > > > Hi, > > I have two HSM questions: > > - Is HSM for Unix included in TSM b/a client? > > - What is the way to backup an HSM-managed filesystem? The illusion for > me > > is that HSM data is not fixed, some of it might be on tape today, but > based > > on the configurations and actually the need for data, at another time the > > contents of the filesystem would be totally different. How to > > protect/backup > > the data? > > > > Thank you, > > Mehdi > > >