Frequent (15 min) backups: danger to the system through VSS?


Author
Message
q9q
q9q
New Member
New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)
Group: Forum Members
Posts: 19, Visits: 62
Hello,

I am using synthetic file and folder backup to backup my documents and pictures every 15 minutes. These folders have large structues (20 GB and as lot of document files and pictures etc.), but usually hardly any changes. I would like to know what exactly happens to the system when VSS is used by Macrium: Is VSS used to copy ALL files, or only locked files? Will the VSS copy operation put strain or deterioration to the system (ware, overload, masses of data written) that could have a significant effect on hard drive longevity etc.? Note that I am NOT referring to the destination. Can the load be quantified? The destination is a replaceable, redundant drive that does not require special care.

Thank you!



jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
I wrote an explainer post on VSS over here a while ago.  Reflect's VSS snapshots are temporary, so they get purged after the backup job that requested them finishes.  VSS is a snapshot of the entire volume, but that does NOT mean that creating a snapshot involves copying all data on the volume.  As I wrote in the post I just linked, the only data that gets copied for VSS is the original data blocks (not even entire files) of any data blocks that you overwrite on your system while the snapshot exists.  I would not consider this to be a meaningful detriment to hard drive longevity, although even if it were, if you've decided that 15-minute backups are worthwhile for your use case, then I would consider that the cost of doing business, so to speak.  It wouldn't really make sense to me to say, "I'd like backups every 15 minutes, but since VSS would increase wear on my source disk, I'll back down."  If you're backing up every 15 minutes, I'm thinking your time is valuable, and if that's the case, then the cost of replacing a storage device earlier is probably less than the cost of losing time due to less frequent backups.  But again, I wouldn't consider VSS to be a major contributor to premature wear here.  Hopefully that post I linked is helpful.

q9q
q9q
New Member
New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)
Group: Forum Members
Posts: 19, Visits: 62
Thank you a lot, that was helpful. So I would think to calculate the additional wear, is it correct that one would calculate:

WARNING: this is wrong (I am additng this warning, signed q91 :-)
(time that snapshot exists // interval time) = percentage during which snapshot exists.
This percentage is the additional wear to the SDD.



Edited 7 October 2021 2:29 PM by q9q
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
Happy to help, but that would not be an accurate summary.  I'm also not sure what "interval time" even means.  If you create a VSS snapshot and there's no write activity while the snapshot exists, then the write activity is nothing beyond some baseline activity to set up the snapshot.  If you create a VSS snapshot and only write NEW data without overwriting any existing data, then once again you won't have write activity beyond the creation of the snapshot.  You only see write activity when overwriting existing data while a snapshot exists.  And if you're looking at an SSD, the only "concern" is write activity, not read.  And the reason I put that in quotes back there is because the concern over SSD write endurance is vastly overblown for typical use cases.  On my primary, daily use laptop, my Samsung 970 Evo Plus 1 TB SSD is rated for 600 TBW (terabytes written).  I've had it for two years now, and based on the amount of data written to it over the last two years, my SSD's write endurance would last me 80 years.  I'm pretty sure I won't need to write to this SSD that long.

Bottom line: Just use your system the way you want to. You'll be fine.

Edited 7 October 2021 2:06 PM by jphughan
q9q
q9q
New Member
New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)New Member (29 reputation)
Group: Forum Members
Posts: 19, Visits: 62
Hello, you are right about the SSD wear and that it's nothing to be concerned about in most use cases (there are some videos on GB written to SSD on  M1 Macbooks which CAN accumulate to quite some amount that could get somewhat relevant after a few years, and also even small things like constant writing (every few seconds) of the current tab set (if user habitually has 500 tabs open) of a browser for crash recovery can amount to quite some GB per day, so I am making extra sure to find out what VSS actually does).

by "interval", I meant the schedule of when backups are made, such as "15" minutes. I am correcting my calculation:

(warning: the following calculation is tentative, do not reference this, it might be wrong)

(average time that snapshot exists DIVIDED BY user-defined time between scheduled backup starts) = percentage of time during which snapshot exists = PST
(average data written per day that overrides existing files DIVIDED BY average total data written per day) = percentage of overriding data written = POD

PST multiplied by POD = estimation of the percentage that is the additional wear to the SDD.

example:
snapshop every 30 minutes
average time of snapshot existence = 3 minutes
PST = 0,1 (10%)

average overriding data = 1 GB
average total data = 20 GB
POD = 0,05 (5%)

0,1*0,05=0,005 = 0,5% additional wear.





Edited 7 October 2021 2:31 PM by q9q
JK
JK
Master
Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)Master (1.8K reputation)
Group: Forum Members
Posts: 1.2K, Visits: 4.4K
I don't think OP's proposed formula seems that off the mark as a conservative estimate.  Assuming "Interval Time" means the interval between snapshots (e.g., T = 15 min), and "Time that Snapshot Exists" is exactly what it sounds like, and essentially equivalent to backup time (let's assume B = 5 min), then averaged over a long time period (to be able to assume the rate of disk writing is approximately constant over time) it would probably be accurate to say that the wear & tear on the source drive increases by a percentage less than or equal to the ratio R = B/T.

If, on average, the fraction of write operations that produce only new data (and do not overwrite snapshotted data) is N, then the fractional increase in write operations on the source drive would be R = (1-N)B/T.  Thus, OP's estimate is true in the worst case scenario (N = 0), but is an overestimate if N > 0.

The absolute worst case scenario is N=0 and B=T (because Reflect will not start a new backup unless the previousl one is finished).  In this case, R = 1, which means a 100% increase -- or in other words, the write activity is effectively doubled, meaning the drive lifespan is cut in half.  So, based on JP's use case, the drive might last 40 years instead of 80 years. 

Edited to Add: OP posted their follow-up response at the same time that I was composing the above, but it seems like we came to the same conclusion.

                                
Edited 7 October 2021 2:38 PM by JK
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search