File naming and time stamps

[seapro220]

Hello all. I have a curious thing going on and wonder if others do as well. Here's what I mean -

I have a full job which runs on friday pm. It creates a naming schema of "server-backup-job2013-03-23T230100.vbk". Although this job started on the 23rd at night, it's modified times tamp is on 3-24 at 4:27pm. Ok - I get that. What I don't understand is that the previous job - named "server-backup-job2013-03-16T110053.vbk" which completed the following day, 3-17 - now shows a modified date of 3-23-2013. Is the modified date now reflecting the 'new' date, based on the 'latest' Full.vbk file to run? This would make some sense, as whenever the 'newest' job ran, it had to 'roll-up' some data from last weeks full.vbk file - but just not sure. I seem to see this on all my full.vbk jobs.
This also potentially compounds some thoughts as I start to archive off quarter backups. For instance, if I archive my backups from this weekend, and use the 'date' of 3-31-2013 as my 'quarter-1' backups - then they will have dates ranging from 3-28 to 3-31. However, next weeks that I keep 'in-house' will also show 2 different naming/date schemas - like "this weeks name in the file name, but last weeks time stamp" info.

thoughts ??

mark

[dellock6]

Maybe are you using synthetic full, so the previous full backup is read when doing the next iteration of the full, even if the next backup is again a full one?
Old VBK files should not be touched if running active full...

Luca.

[seapro220]

I forgot to mention that the backup methodology is ...forward incrementals, 30-day history, synthetic fulls and the 'full' runs every saturday.
I agree that the previous backup should be read, to calculate/determine where it's 'left off' - but wouldn't expect it to modify the date - and possibly the data within it. Seeing that the file date has been modified leads me to believe that there has been some data/delta changes within it and that's why I'm curious if anyone else is experiencing the same type of info.

mark

[dellock6]

Wait, are you saying you flagged both synthetic full and active full in the same job? Check this carefully, maybe this is the reason leading to have two full VBK files at the end...

Luca.

[seapro220]

Yes. the full settings of this pictular job are as follows -
'production' servers - most of them
incremental - daily at 9pm
enable synthetic fulls
run on saturday
transform previous full
30-day files.

From what I understand from these settings the following should be happening -

run a daily job at 9pm, keep 30 days of incremental changes (not reversed incrementals), run a full on saturday and roll-up the past changes so that the 'full' is now on saturday - with the past 30 days of incremental changes. Basically, 1 full vbk file - with 30 days of incremental backups.

mark

[dellock6]

Wait wait, you listed also transform! The complete text is "transform previous full chains", this means once you create the new full once per week, all the previous incrementals are transformed into VRB files like in a reverse incremental, the previous files should be VRB, not VIB...

Luca.

[foggy]

Mark, could you please clarify whether you have active fulls enabled for this job?

[seapro220]

Active full is not selected. I'm not wanting to create 'another' full backup (periodicfally created) to have on the system, just having the full created 1 time a week, and transforming or rolling-up the previous 30 days into 'that' full - so i can archive it as a quarter backup - or whatever I want to do with it. Isn't this correct? In my directory I only have 3 file types - .vrb, .vbk, and .vib. If I understand the naming convention correctly they are for this process -

vrb - variable roll backup file - ?? unknown what's in this file.
vib - variable incremental backup file - changes from previous daily backup file
vbk - full backup file

mark

[seapro220]

also - of those file listings, the following is true -
2 vbk files
2 vib files
the balance are vrb files.

[dellock6]

Syntethic fuld DOES NOT sums up a full chain into a single VBK file, that VBK file is related to the point-in-time backup of the day it is created, from its content point-of-view, there is no difference between an active full and a synthetic full. On day X the vbk contains backup info at that day. You still need to have previous backup, beeing them vrb (reverse increments) or vib (forward increments) to restore previous days.
Transform take previous forward incremental chains (vib file) and transform them into vrb files (reverse) so you can delete old full vbk files and save on space.

The user guide explains it with some helpful schemas.

Luca.

[seapro220]

For what I need, which is a full.vbk file, in which I can store offsite as a point-in-time for quarterly backup - I'm fine with this method. I keep 30 days of incrementals so if i have to do any type of restores, post 29-days after the quarter backup..i'm ok with that.

[foggy]

So, back to your previous question about backup file date change - are you still positive that the previous VBK file date is changed after creating synthetic full? My another assumption is that you just were looking at the VRB file, not VBK and this one indeed should have the date stamp of the day when synthetic full was performed.