Son-Father-Grandfather rotation suggestion

[foggy]

but is there a way not to have the same VIBs/ VRBs to come in the monthly and yearly jobs i run, since i already have them in the daily.

Only if you have them on a deduplication storage.

[zak2011]

Thats good..
Now to understand the forward incrementals clearly-
when i use forward incrementals on a deduplication storage...and if i have only one job ( containing forward incrementals with one active full every month) with 120 restore points..the earliest restore point will not be taken isnt it. Will it be random..that is any vbk or vib/vrb will be overwritten.
Thanks

[foggy]

Arun, have you reviewed this thread? Contains perfect explanation of forward incrementals.

[zak2011]

Excellent explanation. Thanks a lot foggy..its pretty clear about the forward incrementals.
However i didnt understand about the synthetic fulls.
"Be aware, when you run your synthetic fulls you must schedule them to run on a day when you run backups or they never happen. For example, in the above scenario, if you scheduled backups to occur on M-F..but checked the box for a Saturday synthetic full, since the job won't launch on Saturday, the synethetic fulls never get created. Thus, you end up with tons of incrementals...which can never clear out as you cannot delete the very fist Full..which all subsequent incrementals depend upon".
I never knew about this and i was doing the synthetics on non backup days!!!!
Why would the synthetic not be able to run on a day other than the usual backup days?

[foggy]

This was so prior to v6.1. Synthetic never comes alone without incremental run. On a synthetic full day, Veeam B&R performs incremental backup as usual and then, at the end of the backup job, creates synthetic full. If the job was not scheduled to run on that day, synthetic (in contrast to the active full) would not be created. However, in 6.1 any type of full backup will run on the day it is scheduled at.

Arun, please keep in mind that all these questions are well documented in the user guides and existing forum threads. Kindly please use search before asking. And please do not mix up unrelated questions into the same topic, as it makes the content really hard to consume for future readers.

[zak2011]

Thanks for explaining the last part. Sorry ..didn't realize the question was from a different topic... point noted.
So maybe i could send you a PM in future!
Thanks!

[zak2011]

Just to add to your point Ben. I am a customer just implelemeted Veeam officially a month ago. I have been really frustrated with my previous backup product and thats why we switched to Veeam.
True there are some challenges for us who have various retension period requirements.
My honest opinion about VBR6.1 is it is a very well thought of product to address the different challenges we as end users face.
I am truly grateful to the Veeam think tank and their team..because they constantly strive to enhance their product and make it really easier and sensible for end users like us.
So i am sure the product is going to get really cool day by day.

[Gostev]

And this is only possible because we have the best and smartest customers in the industry, who provides us valuable feedback and valid feature requests. Unfortunately, some features take longer to implement because of priorities driven by both tactical and strategical factors.

But I want to make it very clear - we never ignore a single valid feature request. For example, this specific (pretty old) feature request for SFG rotation has simply been waiting for another, bigger feature that it will become integral part of. It just did not make sense to implement without that other feature from R&D perspective (due to having to re-implement soon). What you are seeing as customer and partners, is just a tip of the planning iceberg, so please just trust me - we are not ignoring your feedback, and it is as important as ever that you keep providing one, even if some of your previously requested features have not been implemented yet.

[Tijz]

Hi,

We are currently backing up to a deduplication appliance.
We are getting great dedupe ratio's on the weekly fulls, but the daily inc's only dedupe/compress to 1.8 : 1

I would like to keep my fulls for about 12 weeks.
But I would like to delete my daily incrementals after two weeks, to save space.

How would I do that in Veeam?

Or should I just write a script to delete the .vibs files older than two weeks? But that the catalogue in Veeam is not updated. Is that going to be a problem?

[Vitaliy S.]

Or should I just write a script to delete the .vibs files older than two weeks?

Yes, you may want to use a script that would retain only VBK files on your target repository.

But that the catalogue in Veeam is not updated. Is that going to be a problem?

No, it won't be a problem.

[zak2011]

I totally agree with bbricker the suggestion about the retension policies features. It would be useful if this feature was in Veeam too!

[Yuki]

Same here...asking for this feature to be added into a future release.

[webstyler]

Hello

Any tutorial, link, kb or suggest about how to realize anything as (for example):
- daily backup (not full)
- weekly backup
- monthly backup
- external backup

best way is powershell with single job, or more job ?

you prefer work on restore point (14/21/30) or set more job*

*es.
job daily : any day - 7 restore point - retention : last week - cover 7 days
job weekly : any monday - 4 restore point - retention : last 4 weeks - cover 1 month
job monthly : any 1st of month - 3 restore point - retention : last 3 month

--

any suggest is welcome

Thanks

[meeyou]

I would like to configure a job to run an Active Full backup monthly, with incrementals in between.

I want to keep at least one month of daily restore points available (I know that I'll be looking at somewhere between 1month and 2months of them online due to dependencies, that's fine)

Here's the part that doesn't seem to be supported out the box with Veeam: I'd like to keep 12 active fulls online at any given time.

It's a pretty standard father-son style backup scheme but I'm not sure how it can be accomplished in Veeam. Anyone had any success with this sort of setup?

[Yuki]

There is no capability in current version to prune and keep backups outside of the active schedule (father-son type). You need to do one of two things:
1) schedule several jobs (lets say 1 with a single full + 30 days of incrementals) and second monthly that consists of fulls only for as many months as you want
2) use script to copy full backup files to another location after it is created by Veeam.

A number of people has asked for such feature to be added to future release and I believe Veeam is looking at getting this implemented.

your post is likely to be added to this thread since it deals with the same question/request

http://forums.veeam.com/viewtopic.php?f ... her#p61869

[bbricker]

Not to be rude, but how much longer are we going to continue to see questions about this merged into a thread that is over a year old before it's actually implemented? It is one of the most viewed threads on this forum at almost 7000 reads. Thanks

[Gostev]

I am sorry, but we do not publish the roadmap.

[Yuki]

Considering how much of a welcome change this would be and how much the scheduling/maintenance engine would have to change to accomodate for this (plus all the testing, since this is a new feature and not a bug) i would say it is slated for v7, but probably not sooner.

Given the previous release schedule below, i bet v7 is on a map for release in fall of 2013 (most likely) or possibly closer to the new year.

6.5 October-2012
6.0 November-2011
5.0 October-2010
4.1 February-2010

[jim3cantos]

They say a picture is worth a thousand words, and I got to thinking about this screen back from when I was playing with VMware VDR. This is the kind of thing (although maybe with more options, such as a box for "daily" instead of "recent") that would be great to see in Veeam, at least as an optional alternative to the standard scheduling:

+1

[JasonJoel]

OOPS. I see there are a number of threads on this topic already. Sorry.

Instead of Veeam just saying the current behavior is 'by design', I think they should consider putting this change in a future version. As there are at least 4-5 threads on this, it is obviously something the customers want.

Original Message:
It would be nice if when creating a backup job you could specify the backup retention in TIME units instead of # OF RESTORE POINTS.

Not a huge deal, but most backup retention standards I've used specify retention in # of days, not # of backups. Being able to specify the time directly would make it a little easier to set up the jobs, and more obvious to the auditors what the true configured retention time is.

Thanks for your consideration,
Jason

[lorengordon]

I'd like to go ahead and +1 this as a feature request. Since somewhere in the thread it was mentioned that this wasn't a highly requested feature, the more people that speak up the better! I'd also like to have the option of de-staging each generation to a different repository. For instance, I'd like to keep daily backups on a decent DAS/NAS device that works well with the Surebackup random-read requirements, while keeping weekly and monthly backups on a de-duplicating device. It would be most preferable to do this while keeping the backup chain intact (at least in the UI), as well. Thanks!

[sergei.sokolov]

I would also like to vote for the implementation of this SFG rotation feature in VBR.
Many of our SLA clients were asking if that is currently supported at some degree. At this time there are only workarounds.

For me it definitely would be the best new feature VBR could possibly get.

[wayne]

Need quality job scheduling without having to use home grown scripting to guarantee long-term retention.
When it comes to a backup schedule I understand there are many ways to approach this. The cleanest long term way with this product I see is to not have a server be in multiple jobs if at all possible. No duplication of work if a quarterly full backup coincides around a monthly full or even with a weekly full backup. If you know what your long-term goal is you almost build your schedule backwards with retention in mind. Some like to keep a fiscal or calendar yearly long term. For us prior to using the VEEAM product we found keeping Quarterly full backups long term was much better. While building out the long term set it once and done pattern we instead of keeping weekly fulls we found a mid-month full and end of month full kept the duplication of work to a minimum. Those are kept for one quarter or three months in our case. For other that could be six months. In between all those full backups we run incremental backups which we kept for 20 days in our case. In our case this gives us twenty granular days of dailies to figure out you have an issue, then a little less granular for three months. Anything after three months has aged to long-term kept more for legal purposes. The frequency should somehow be reflected in the file name.
Long term could mean forever, 7 years, minimally whatever the legal requirement.

[djmeyerkc]

I have been using Veeam for a little over a year now and generally find it a very good product but the one thing I miss from my Backup Exec days is the scheduling. At eond on month we need to have a different schedule. If I could exempt specific days I couold then setup a second schedule for the eom jobs. I am getting aroung it with scheduler but it would be nice to have it within the product

[JosVerhallen]

Hi,

we are facing the following problem with planning / implementing a VEEAM sollution for 1 of our customers
the customer has specific retention needs for their backup data which are required by law. Due to this requirement we are looking for a way to 'archive' our backup data to a secondary storage repository with cheaper disks
we are looking for a way to provide this customer with the following retention period:
daily = 5 weeks
weekly = 5 weeks
monthly = 3 months
quarterly = 12 months
yearly = 20 years

our idea was to keep at least 1 week worth of back-up data on our primary backup repository which consists of very fast storage so the customer will be able to do fast restores from that week and are able to boot VM's from this set of backup data without major performance loss. the rest of the recovery points should be stored on the secondary storage repository which has cheaper/slower disks.

how do we set this up without having the need to use scripts or 3rd party software? our customer really wants an out of the box sollution for this which is easy to manage.

Kind regards,

Jos Verhallen

[wayne]

Jos has anyone attempted to contact you or is this a black hole.

[foggy]

Wayne, believe me, your requests are not ignored. Your and Jos's posts have been merged to this existing thread as referring to the functionality that has been requested before (we try to keep all similar requests together for consistency). You can treat this Anton's post above as an official answer.

[wayne]

I go into meetings were people ask about progress. I suspect others do also. When I say there has been no response, it reflects on me. When I say there has been no response since talking to the sales person during the trail that says right now it’s not available but were talking about. It reflects on the vendor. Discussions move out of company meetings into user group meetings hopeful to find future change. Can we just read it here? We hope to have something in place in V8, V9 or V10? No information is harder to deal with than that is going to take 6 months, a year or longer, we are not working on it.

[foggy]

As you can read above, we do not share the roadmap of our future releases. Though reading through this discussion, you can also conclude that this feature has been on our radar for a long time.

[Gostev]

You can expect this feature sooner rather than later.