DaveWatkins wrote:per VM chains is a repository setting, so applies to all backups stored on the repo.
I'd be inclined to create a new job and copy all the default settings into your old job unless there is a reason not too. That way you'll pick up any new settings that will help
DaveWatkins wrote:That's about as slow as possible . I assume you have RAID5 or RAID6 running as well (slowing them down ever more). I wouldn't be surprised if the maintenance defrag task took more than 24 hours on a backup that large. You won't know until you try obviously but that's the primary reason all my really big VM's are using forever forward still and not reverse incremental
DaveWatkins wrote:Personally I'd use forever forward unless you have _really_ fast disks. Running a maintenance task to defrag and compact a reverse incremental of that size would take a long time. Other than that, I'm not sure any of the new features would really benefit other than per VM chains on the repo to keep the file sizes manageable.
Stripe size at 256k assuming the Storage Optimization setting is set to LAN Target and allocation size of 64k, format it with /L in case you want to use dedup later when Windows 2016 comes out, 2012R2 likely wouldn't like the large files. No idea how big your repo is but if you think you'll want to enable dedup in 2016 keep the LUN sizes less that 64TB
Users browsing this forum: Google [Bot] and 51 guests