Start a Conversation

Unsolved

This post is more than 5 years old

A

681

May 1st, 2007 21:00

Regular file size change

We have a Solaris backup server & Windows client all using NW 732 Jumbo 11.

We backup full once a week and incremental daily. Last week we wanted to restore Thursday's backup but were not able to browse through Wednesday & Thursday's backup. All older backups are visible for recovery but no these two.

The daemon & savegrp etc. show that backups were 100% successful. nsrinfo, mminfo etc. show the contents but recovery interfaces like nwrecover, save set recover or recover command do show this backups.

Support has run some commands and found out that on Thursday night when backups were on 749 files were backed up of which 747 files grew in byte size during the backups. We do not have an anti-virus there. No RAID rebuilding was on so we are not able to find out the possible reason for almost all files growing in byte size during the backups.

Any suggestions would be well appreciated.

14.3K Posts

May 2nd, 2007 01:00

If that happened I assume there would me message about is (usually this is recorded in logs). So I assume this is what support found too. The next question is what are these files. And the magic question is can you browse and restore at least 2 files that didn't change? I didn't do the test, but I assume if you can't restore something because its size has changes then that should not be visible via nsrinfo. I also remember I did backup in past files which did grew in size and was able to restore it (hopefully my memory is correct).

2K Posts

May 2nd, 2007 06:00

No, we cannot browse or restore those two files as well but those entries in the output are for d:\ & /.

Normally we also restore files that grew in size during backups so this should not have been a problem.

System/Application logs have no specific entry and these are just data files form a file server..MS Office etc. types.

14.3K Posts

May 3rd, 2007 04:00

Somehow I do not buy explanation you have received :D Ask for more details on why and how - and what about those two files? I guess proving that you can restore file which changed in size is simple so make that test too.

2K Posts

May 8th, 2007 11:00

We even made a clone of the save set to a adv. file type device but even now when we restore using various scanner options, we are not successful.

If we recover indexes using scanner -i and then recover files, we still get file with same names but funny characters. The data recovered is not usable.

14.3K Posts

May 8th, 2007 12:00

Are you trying to confuse me? :D How did you make a clone of something you can't scan?

To me it sounds as backup you are after has been corrupted - now question is if backup just did save of already corrupted or something else is going on. If you check with nsrinfo what you have in index and that doesn't match silly thing you get via restore you have good case against support.

2K Posts

May 8th, 2007 22:00

Support asked me to make a clone to a file type and send it to them for them to try restoration in their Lab.

The data on disk is not corrupted as it is available for restoration before & after these two dates for which it is behaving like this.

nsrinfo etc. did not work for these and for this reason support wanted me to make a clone and test. Noiw, we have realized we made a clone on AFTD which has mixed up the things further.

14.3K Posts

May 9th, 2007 01:00

It should not matter if your clone is on file, AFTD or tape. The only difference is that for support is much easier to troubleshoot tape ssids on file device than on AFTD.
No Events found!

Top