Skip to main content

Backup Time Stamp

Thread needs solution

We have a schedule to backup the entire machine daily.  The backup are placed in our NAS and it will synchronize to another NAS.  We found that the previous backup time stamp will be modified if a new backup is running.  Hence our NAS will synchronize both file each time and it consumed lot of time and bandwidth.  Can it be correct?

 

Thanks

 

0 Users found this helpful
frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 250
Comments: 7092

Hello Andrew,

thank you for your posting! Would you mind sharing more details on your setup? What archive format is used(12 or legacy)? What are the settings in the backup scheme and replication schedule?  A couple of screenshots would be helpful. And could you also attach some screenshots that illustrate the issue. What is being replicated and where you see the wrong behavior.

Thank you in advance. 

We are using 12.5 with latest updated.  Attached are screenshots.  It is a daily full backup.  From the backup1.png, the backup file 009 time is 2018-08-14 09:25:05.  From the backup2.png, the file 009 time is changed to 2018-08-15 09:29:55.  It always change the previous backup file time stamp.  BTW, In the backup console, it only shows 2 backups available in this week.  However we should have 3 backups (backup3.png).

Thanks,

 

Attachment Size
457903-150802.png 16.82 KB
457903-150805.png 18.68 KB
457903-150806.png 80.57 KB
frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 0
Comments: 82

Hello Andrew, 

thank you for your posting! I will be happy to help you. 

This is expected behaviour, as each time you do a new backup, the software first checks the previous version and tracks the changes made since then. The date modified will change inevitably. 

We're planning on a feature to add more variables to the backup archive names, including date and time stamps. This feature is under development, its internal ID is ABR-131367. Unfortunately, there is no ETA so far. 

For now, I would suggest you use a replication feature that will recreate the backups to your second NAS, so that you will not have any duplicates. 

I hope this information could be helpful to you. If you have any questions, please do not hesitate to contact us again. 

Hello Elizaveta,
I was also amazed about that behaviour and please let me allow some comments:

This is expected behaviour, as each time you do a new backup, the software first checks the previous version and tracks the changes made since then.

--> The check should be a pure read access or am I wrong ?
And if this is correct, why is then

The date modified will change inevitably. 

valid?

A pure read access never changes the modification date.

So my question is:
Why does Acronis write in a file of a previous backup and which data is written there?

If an existing file is really changed, the task of validation is lead to absurdity as this write access may damage the backup chain.
The recovery of this recovery point may fail only because a later (!) execution of the backup plan has damaged it ?
I hope that is not really true....

Regards
Sven

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 250
Comments: 7092

Hello Sven,

when we open a previous archive for reading, this fact is also logged in the archive, this is needed for the archive consistency. 

Hello Ekaterina,

sorry, but honestly spoken I´m slightly shocked about this information.
Is this something special with SQL as the threadopener shows in his screenshots ?

But even if it would be something SQL specific:

Why is there a need to check for changes if you do a FULL backup ?
There is no need in my eyes as a full backup has no dependencies on file changes.
Just put everything in it and done.

 

But from my point of view thsi must be something specific for the thread opener and/or SQL.

If I look on my NAS the modification date is exactly the date when the file was created.
So I cannot see the described behaviour on my system.

And this is valid for all my archives.
I have more than 15 plans with different schemes (Full-Diff-Inc, Full-Inc. only Full...) and different retention rules.
All have 12.5 format.
System is Windows.

So no changes in tiemstams of tibx here.

Honestly spoken this would be a kind of NoGo for me if a check, whether there are changes and therefore data must be stored in the new backup  would end in a write access to the OLD backup.

Why?

Several reasons:
- Is the file consistency still intact ? A write acces may damage the file, so a new validation is needed ?!
- Who guarantees me if only metainfo is written and that all the user data remains intact?
- If I must prov the content of a file for a specicfic date every lawyer would grill me if I take the file from a backup with a modification date from last week although I state "well your Honor, this is something specific with the backup software, you must believe me that this is the backup fro 2 years ago".

and last but not least:

- As the thread opener states, some people use low bandwith connections to a remote location and if then each file must be trasferred each day....no way.
 

Regards
Sven

Hello SvenT

I see what you mean. Archives (format 12) are not immutable and subject to changes. We change the “last date modified” to make sure the backups are consistent. So, when the software has to create a new archive, it first opens the previous one, makes an entry which points to the new archive and creates that new archive.  The previous file is not changed – what we change is the meta information to make backup restorable and to preserve the links between archives. 

By the way, we published a KB article on that https://kb.acronis.com/content/62736

I hope I could help you here. If you have further questions, please let me know.