Unsolved
This post is more than 5 years old
19 Posts
0
7946
October 15th, 2010 04:00
Problem with Celera NDMP over IP backup.
Hi All,
Hope I can get a help here. I have a problem last 3 days with NDMP backup one of 2 directory.
BackUp software Symantec BackUpExec 2010, last OK backup 10 OCT 2010. All backUp later finished with error
Backup set #60 on storage media #20
NDMP Log Message: Medium error
NDMP Log Message: Write failed on archive volume 1
NDMP Log Message: server_archive: emctar vol 1, 1097662 files, 0 bytes read, 1344562659328 bytes written
NDMP Data Halted: Internal Error
NDMP Log Message: Mover: Data connection socket read error.
NDMP Mover Halted: Internal Error
================ NDMP ENVIRONMENT ================
FILESYSTEM=/Dept
LEVEL=0
DUMP_DATE=-1
UPDATE=Y
HIST=Y
SNAPSURE=Y
TYPE=dump
=============== NDMP ENVIRONMENT END ===============
I have secondary File System /Users in this Job with the same param and this FS backuped ok without any errors.
0 events found
Andrey_ALexeev
19 Posts
0
October 18th, 2010 23:00
Hi Rainer, thanks you very for all of your answers and clarification. Currently I undestand my mistake, then I moved all 2/5 tb data, i just create daily checkpoint schedule on every 3 hours and than run dedupe. So I need to stop all proceses now, delete all ckpts and dedupe, run dedupe, finis it and run ckpt.
Thats clear.
"
And do a reasonable savvol sizing – there is no free lunch – if you want to keep x days at y% daily change rate then you need x times y% space
"
Could you please to clarifu your formula. I am not clear understand it. I have 2.5 tb data and I need to keep daily ckpt MTWTF every 5 hours and keep 5 ckpt and + 1 more schedule MTWTF every 21-00 and keep 10 ckpt. How many gb should be alocated for savvol, every day changes is near 600-900GB
Rainer_EMC
6 Operator
•
8.6K Posts
0
October 19th, 2010 06:00
I would suggest with the number of days that your “oldest” checkpoint is times the daily change rate
Or look at your backups and add up the incrementals size for all these days
Rainer
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
October 19th, 2010 20:00
Umm ..ok. So i enable dedupe on a file system with existing checkpoints and all of a sudden my savvol is 30% bigger and you are saying dedupe is not the cause. Until EMC comes up with a way to separate savvol from primary file system this is going to be a problem. I give my customers a file system with checkpoints enabled, over a couple of days they dump a few terabytes and start using it. In the mean team dedupe is running and my savvol keeps getting bigger and bigger.
Peter_EMC
674 Posts
0
October 20th, 2010 06:00
If you are doing the following:
1.) create a FS
2.) fill it with data, test around, delete all the data.
3.) create a checkpoint
4.) migrate production data into the FS
doing it like this, the checkpoint savvol will be nearly as big as the filesystem data.
Thinking about dedup, every file dedup is changing (most of them will be compressed) is rewritten into the FS and the original is deleted.
When the blocks in the FS where the original file was located are reused (and a checkpoint exists), then these blocks need to be copied into the checkpoint savvol or else the checkpoint functionality would no longer work!
Dedupe is doing a massive change in a FS, in order to undo these changes (this is what a checkpoint is for) all the orginal data needs to be preserved in the savvol
Btw, there are other processes which are working similar.
Think about a FS with DHSM and checkpoints. If during the first run of the DHSM policy engine maybe 30 % of the files will be migrated and replaced by stubs and later the new empty space will be filled up with new or updated data, then the original data needs als to be copied into the checkpoint savvol.