How often do I need a full backup?

[dstreufe]

I see that the FAQ says this is possible, but what is the best practice around how often I need to take a full backup? Due to the type of storage I am using a synthetic full takes a LONG time, and an actual full takes about 35 hours. Instead of doing this once per week, I would like to do it once per month or less.

How far apart can I stretch the interval between full backups before I am flirting with trouble?

Thanks,
Dan

[Gostev]

Hi Dan, recommended values are as follows:

For incremental backup mode:
• Synthetic full weekly (UI will not allow you to schedule synthetic less often for performance reasons), OR
• Active full monthly (driven primarily by retention policy and disk space considerations - unlike with reversed incremental backup, older restore points cannot be deleted immediately, until the new full backup is created)

For reversed incremental backup mode:
• Active full once every 1-3 months (this backup mode is specifically designed for long incremental chains, but Active Full is still good for the purpose of defragmenting and reducing full backup size).

That's what I am seeing other customers doing typically. Internally at Veeam are not using active fulls at all, but effectively they still happen once every half-year or so because of various job re-arrangements, Veeam B&R upgrades etc.

Thanks!

[1-0-1]

What happens if the incremental backup chain is broken. Do I just loose that point in time backup or loose the whole chain from the faulty incremental?

[Gostev]

The latter, of course. "That point only" would require differential backup to be performed, which is not reasonable on image level (backup time and size considerations).

[dstreufe]

Gostev,

Thanks for the info. We will go with monthly active fulls. If we had plenty of disk space to, say, go with a longer interval such as quarterly, would there be other reasons to avoid this?

Thanks,
--Dan

[tsightler]

Honestly, performance starts to be noticeably worse with very long incremental chains. Importing a long incremental chain takes MUCH longer than a short one, and the dead time (the time between when you start a restore and when the transfer of data actually starts) also increases quite significantly. Because of this, I always suggest at least monthly fulls if using an incremental policy. This also helps mitigate the likelyhood of a single bad incremental file causing you to loose weeks, or even months, of backups.

These issues are less noticeable for reverse incremental. Even very long chains seem to have only minimal performance impact. I think this has something to do with the way metadata is stored as, with forward incremental, each file has to be read to process the metadata (previous files are never touched), while, for reverse incremental the most recent VBK contains all of the required metadata. V6 will likely minimize this issue as there are significant changes to metadata handling coming with V6.

[Daveyd]

Honestly, performance starts to be noticeably worse with very long incremental chains. Importing a long incremental chain takes MUCH longer than a short one, and the dead time (the time between when you start a restore and when the transfer of data actually starts) also increases quite significantly. Because of this, I always suggest at least monthly fulls if using an incremental policy. This also helps mitigate the likelyhood of a single bad incremental file causing you to loose weeks, or even months, of backups.

These issues are less noticeable for reverse incremental. Even very long chains seem to have only minimal performance impact. I think this has something to do with the way metadata is stored as, with forward incremental, each file has to be read to process the metadata (previous files are never touched), while, for reverse incremental the most recent VBK contains all of the required metadata. V6 will likely minimize this issue as there are significant changes to metadata handling coming with V6.

If you are only doing monthly fulls, how many rollbacks do you keep?

[tsightler]

We had various servers that required various retention periods. We tailored our backups jobs to use the mode that provided a balance between space, retention, and performance. For example, for servers that had fairly low changes rates and long (180 day) retention requirements, we just used reverse incrementals.

However, we had quite a few servers that had 90 day retention of daily backups, and multi-year retention for monthly backups. These servers also had a moderate change rate. Monthly "real" fulls were perfect for this case. We archived the monthly's to tape for the long term retention requirements and had 90 days online.

[brupnick]

If I'm doing traditional incrementals on week days (M-F) with active fulls on say the first of the month and I want to keep 2 months worth of restore points (call it 40, 20 points per month), does this mean that I'll need enough space to keep 3 full backups? Based on Gostev's comment that "older restore points cannot be deleted immediately, until the new full backup is created," the first full will also be the 41st restore point, meaning that it will be the first file targeted to roll off. But since that full is needed for all of the subsequent incrementals for that month, am I correct that it cannot be deleted until all of the incrementals that rely on it also exceed the retention period (or a new full is run manually)?

[foggy]

Yes, that's correct. You will need enough space to store 3 full backups.

[davidb1234]

If the option to transform all previous full backup chains to a reversed incremental backup sequence is chosen will that eliminate the need to store 3 full backups in Brupnick's case(since his question also applies to me, we want to do forward incremental and hold 3 months of data but we would rather only keep one full backup on disk and have 3 months worth of reverse incrementals.) We need forward incremental so we can offload to tape nightly but would like to transform these to reverse incremental after synthetic fulls so we don't have to keep so many fulls on disk and can store more data.

In this case would we also be able to go back to a vm point in time and recreate a full VM in the past from the most current synthetic full and the transformed reverse incremental backup chain?

[foggy]

Yes, correct. With transformation into rollbacks you will always have one VBK file stored and will be able to restore to any restore point kept according to your retention policy.

[Daveyd]

I have several jobs that I have configured to keep 7 restore points and do weekly fulls on Saturday with daily incrementals M-F. Looking at my destination storage, my chain look like this...

Full
Inc
Inc
Inc
Inc
Inc
Inc
Full
Inc
Inc
Inc
Inc
Inc
Inc

So basically 6 incrementials per Full. If I decided to keep the 7 restore points the same and change to Monthly Fulls, what would my chain look like?

[dstamen]

We are currently doing daily incrementals with a synthetic full once a week transforming the previous full into rollbacks.

Which seems like a better solution?

Inc
Inc
Inc
Inc
Inc
Inc
Inc+transform previous full

or should we go
Full
Inc
Inc
Inc
Inc
Inc
Inc
Full

what has worked out best for most of you?

[foggy]

Daveyd, you will have somewhat from 6 to 34 (or 35, depending on the month) incrementals and 1 or 2 fulls. Here is a couple of threads with good explanations of the incremental mode: one and two.

[Daveyd]

Daveyd, you will have somewhat from 6 to 34 (or 35, depending on the month) incrementals and 1 or 2 fulls. Here is a couple of threads with good explanations of the incremental mode: one and two.

Since we are backing up to a dedupe appliance (Exagrid),would Monthly fulls with that many incrementals seem like a logical choice since so many incrementals are kept and cannot really be deduped much by the Exagrid appliance?

[Vitaliy S.]

Dave, If you configure your backup jobs to store 30 restore points with full backups scheduled to run on monthly basis, you would have 1-2 full backup (VBK files) plus from 30 to 60 incremental points on your dedupe device. That said, I don't believe that it would save you much space. Besides long chain of incremental backups (without fulls at least once a month) increases the risk of losing backups completely due to corruption of single incremental file due to storage corruption.

Just my 2 cents.

[foggy]

What could really save you space here is reversed incremental backup mode - with it you will always have a single full at each given moment with the permanent number of incrementals (6 according to your "keep 7 restore points" retention policy).

[foggy]

dstamen, please refer to the following Excel document (cited in the sticky FAQ topic) for pros and cons of each backup mode. Basically, it's all about your disk space consumption requirements and backup window size.

[Daveyd]

What could really save you space here is reversed incremental backup mode - with it you will always have a single full at each given moment with the permanent number of incrementals (6 according to your "keep 7 restore points" retention policy).

I was using that method before backing up to the Exagrid, however, from my previous posts on here and reading best practices regarding backups to dedupe devices, reversed incrementals are not recommended.

[tsightler]

I was using that method before backing up to the Exagrid, however, from my previous posts on here and reading best practices regarding backups to dedupe devices, reversed incrementals are not recommended.

This is true, but it's primarily due to performance. Many dedupe devices are not well optimized for the random RW I/O required for reverse incremental. It also doesn't scale very well with 10's of jobs hitting same dedupe appliance at the same time since it generally requires 3x the I/O as simply writing an incremental. If you find the performance acceptable in your environment, then I don't personally think there's anything wrong with it, and it keeps you from running full backups, which is always a win.

I'm also convinced that some vendors suggest this method simply because it makes their dedupe numbers higher, which generates less complaints from their customers about poor dedupe rates (this may not be true, but anecdotal evidence suggest it might be). Certainly a dedupe appliance will see much higher dedupe with 4 weekly full backups, than with 1 weekly and 30 reversed incrementals, but which of those options actually saves the most space?

[cparker4486]

Hello,

Since the latest backup, with Reversed Incremental, is always a full backup what is the use case for "Perform active full backups periodically"? I can't think of a reason why I would want that to tick that box but I also don't want to miss out on any useful functionality.


Thanks!

[OWTech]

What would be the implication of using reverse incremental jobs to a NAS and never performing an active full backup. As it's a synthetic full I would have thought the risks were minimal. It's a test environment and we're only keeping three restore points.

[eheiger]

We've been debating how long we should rely on a reverse incremental without an active full backup. Compared to a real full backup of a vm, is a synthetic full just as reliable? We've settled in on an active full once a month, but does anyone go longer in between active fulls? It makes me a little nervous to do so, however replica's only do a full once then all delta's forever. Does the synthetic full start over from the most recent active full or does it continue on forever from the first original full?

Thanks,
Ed

[Vitaliy S.]

Does the synthetic full start over from the most recent active full or does it continue on forever from the first original full?

It's the first variant. Also to get answers to your other questions, please review this topic.

[dellock6]

Just to give peace of mind to Ed, we had in some customers reverse incremental almost 1 year old, without any active full in between, and we have been able to correctly restore VMs without any problem.

Luca.

[tuscani]

Just want to confiurm.. with reverse incs there is no need to run periodic active fulls correct?

[foggy]

Justin, please review this thread for recommendations on periodic active fulls for reverse incremental mode. Additionally, this topic might also be a good reading for you.

[rawtaz]

For reversed incremental backup mode:
• Active full once every 1-3 months (backup mode is specifically designed for long incremental chains)

Is this still recommended, with VBR 6.5 (and the upcoming v7)? If yes, how do people normally deal with this when they're sending a reverse incremental backups offsite? Presumably they're not doing periodic full backups to such a repository.

I wasn't aware that this was a recommendation given reverse incremental, I thought Veeam had such integrity checks that it could verify that the latest/full copy in the chain is always correct. Assuming the underlying storage is solid, of course.

I think the best I can do is to do active full on the onsite backup, but hardly the offsite one :/

Danke!

[infused]

I do incremental with 30 day retention to hold 4 full backups. The reason I do this is I've had servers crash when a fullbackup is happening with other products (symantec) and it screws the full backup, leaving you without backups (if they are all rolled in to one). I think it's far safer having more than one full backup.

In saying that, I don't know how Veeam behaves when this sort of issue occurs... What If the veeam server dies mid way through a full backup? If you only have one backup, is that backup now corrupt?