yes, they will be backed up every time, but only the blocks that have changed, thats why I specified subfile.....
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 10/12/2007 03:03:53 PM: > Might work... if only I had time to work on such a thing and test it > out... Wouldn't the 1GB files be backed up everytime, since the > timestamp will have changed? > > At 07:40 PM 12/9/2007, you wrote: > >Well Paul it looks like you need a low tech solution > > > >I assume Vista has some sort of NTBACKUP equivalent? > > > >Run your NTBACKUP of the systemstate as a precommand and put it through the > >GNU split utility to give you files of say 1GB in size. do it as a script > >and add a sleep at the end to give VSS time to quiesce before the TSM > >backup starts. > > > >Exclude systemstate from the TSM backup (or maybe put it in a class with > >freq of 14) , but turn on subfile backup for the split backup files. > > > >Voila - poor man's dedup. > > > >Regards > > > >Steve > > > >Steven Harris > >TSM Admin - Sydney Australia > > > > > > > > > > > > > > Paul Zarnowski > > <[EMAIL PROTECTED] > > > To > > Sent by: "ADSM: ADSM-L@VM.MARIST.EDU > > Dist Stor cc > > Manager" > > <[EMAIL PROTECTED] Subject > > .EDU> Re: [ADSM-L] Vista oddness > > > > > > 08/12/2007 10:32 > > AM > > > > > > Please respond to > > "ADSM: Dist Stor > > Manager" > > <[EMAIL PROTECTED] > > .EDU> > > > > > > > > > > > > > >Joanne, > > > >Thanks very much for the detailed response. We really need relief on > >this. We have a couple of thousand Windows systems, and they will > >eventually be upgrading to Vista. As they do so, they will uncover > >this huge problem; A problem for them, in that their backups will > >run longer and they will be storing much more data than they need; > >and also a problem for the TSM server administrators as they put an > >increasingly huge load on the network and TSM server infrastructure. > > > >This solution, as it is now, is virtually unworkable for us. The > >clock is ticking, and we need relieve ASAP. Waiting for the next > >major release is too long, IMHO. It would have been nice if this > >were addressed with the initial support for Vista in TSM, but that's > >water over the dam now. > > > >Thanks for listening. > > > >..Paul > > > >At 11:40 AM 12/7/2007, Joanne T Nguyen wrote: > > >David, > > > > > >You are seeing the correct behavior. If you have the default domain > > >backup, system state will be part of the backup. On Vista, system state > > >is in GB because we're backing up the windows\winsxs and > > >system32\driverstore folder. Please see the link below where MS describes > > >in-box writers. System state consists of all the bootable system state > >and > > >system services writers. Though 8GB seems high. Our testing > > >shows about 5GB. > > > > > >http://msdn2.microsoft.com/en-us/library/aa819131.aspx > > > > > >For Windows 2003, TSM implements a way to back up the system files > > >component of the system state only if something is changed. So it > > >is possible to backup only about 30-40 files the 2nd time and thereafter > >if > > >no fixes or SP were applied after the initial system state backup. > > >During Vista development, we noticed some files were always changed so > > >instead of spending the cycle to compare each file. which are > > >in 30,000-40,000 files now, we decided to backup all the time. This is > >one > > >area we will revisit. > > > > > >If you have vshadow tool from the MS VSS SDK, you can do "vshadow -wm2" to > > >see all the files that should be part of the backup. Please > > >let me know if you have further questions. > > > > > >Regards, > > >Joanne Nguyen > > >TSM Client Development > > > > > > > > > > > > > > > > > > "Tyree, David" > > > <[EMAIL PROTECTED] > > > .ORG> > >To > > > Sent by: "ADSM: ADSM-L@VM.MARIST.EDU > > > Dist Stor > >cc > > > Manager" > > > <[EMAIL PROTECTED] > >Subject > > > .EDU> Re: Vista oddness > > > > > > > > > 12/07/2007 06:47 > > > AM > > > > > > > > > Please respond to > > > "ADSM: Dist Stor > > > Manager" > > > <[EMAIL PROTECTED] > > > .EDU> > > > > > > > > > > > > > > > > > > > > >I did a backup using the GUI and selected system state along with the C: > > >drive. The backup was 8 gig when it finished. > > > > > >I went back and did a C: drive only and it was only a few hundred meg. > > >Then I did a system state only and got the 8 gig again. > > > > > >That system state in Vista is just crazy. I need to go back and really > > >look at some of my servers and see just how big the system state backups > > >are. I'll also take a close look at a few Win XP Pro desktops that I'm > > >backing up and see what the numbers look like. > > > > > > > > >-----Original Message----- > > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > > >Wanda Prather > > >Sent: Friday, December 07, 2007 2:35 AM > > >To: ADSM-L@VM.MARIST.EDU > > >Subject: Re: [ADSM-L] Vista oddness > > > > > >Don't know myself, but someone else posted a while back that the System > > >State on Vista is many GB. > > > > > >That is consistent with what you are seeing - a scheduled backup will do > > >the > > >System State, whether things have changed or not. And selecting the C: > > >drive will not do the system state. > > > > > >As a test, try your backup from thh GUI again, but this time select > > >System > > >STate as well as the C: drive, see if the results change... > > > > > >And please post back the results! > > > > > > > > > > > >On 12/6/07, Tyree, David <[EMAIL PROTECTED]> wrote: > > > > > > > > We are testing Vista and I'm seeing something odd. TSM > > >seems > > > > to want to do almost a full backup every time it runs automatically. > > > > > > > > I'm running the 5.5.0 client on a VMware (6.0) Vista > > > > Ultimate box that is talking to a TSM server running 5.4.1 on Windows. > > > > > > > > The backup on the Vista machine is automated using the > > > > DSMCAD service. The incremental backup kicks off at the correct time, > > > > but it ends up doing a full backup. > > > > > > > > I've looked through the dsmsched log on the Vista machine > > > > and I'm seeing where it has contacted the TSM server and picked up the > > > > schedule name and the action. The schedule name is correct and the > > > > action is set to incremental. And several lines in the dsmsched log > > > > mention "Incremental backup of '\\is-vista-test-d\c$' finished". > > > > > > > > The log shows everything just like what I would expect to > > > > say, the issue is that it ends up backing up almost 8 gigs of files > > >each > > > > time the backup runs. I've run scheduled incremental backups almost > > >back > > > > to back on the machine and it picks up 8 gigs each time. The machine > > >is > > > > just sitting there between backups; I'm not doing anything on the > > > > machine in between. > > > > > > > > If I open the GUI and tag the c drive for incremental > > >backup > > > > it goes out and looks at all the files on the drive and backs up a few > > > > dozen files and it done. Just like I would expect it to. > > > > > > > > If I go to the baclient folder and run "dsmc incr" from the > > > > command line it ends up doing what looks like a full backup. > > > > > > > > > > > > > > > > In the last couple of hours I had a scheduled backup run > > > > that moved about 8 gigs worth of files. Right after that finished I > > >did > > > > a c drive backup from the GUI. It moved a few hundred megs of files. > > > > Right behind that I did the "dsmc incr". So far it's moved over 4 gig > > >of > > > > files and is still running. > > > > > > > > > > > > > > > > Anybody got a idea what's going on here? > > > > > > > > > > > > > > > > > > > > > > > > PS, Vista looks good. Except most of our software doesn't > > > > run. The UAC (User Account Control) is a real piece of work. And they > > > > have moved everything around so you can't find what you're looking > > >for. > > > > But at least it looks good.... > > > > > > > > David Tyree > > > > Interface Analyst > > > > South Georgia Medical Center > > > > 229.333.1155 > > > > > > > > Confidential Notice: This e-mail message, including any attachments, > > >is > > > > for the sole use of the intended recipient(s) and may contain > > > > > confidential and privileged information. Any unauthorized review, > > >use, > > > > disclosure or distribution is prohibited. If you are not the intended > > > > recipient, please contact the sender by reply e-mail and destroy all > > > > copies of the original message. > > > > > > > > > > > > > > > > > >-- > >Paul Zarnowski Ph: 607-255-4757 > >Manager, Storage Services Fx: 607-255-8521 > >719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED] > > > -- > Paul Zarnowski Ph: 607-255-4757 > Manager, Storage Services Fx: 607-255-8521 > 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]