-
- Novice
- Posts: 4
- Liked: never
- Joined: Nov 15, 2009 4:20 pm
- Full Name: Ollie Tansley
- Contact:
Enable full backup on these days
Hi all,
Can someone please tell me what the benefit (if any) is to performing a full backup on X day instead of performing constant incremental backups? We are new to Veeam but are starting to roll it out to quite a few of our clients. So far we are really pleased with it .
TIA
Can someone please tell me what the benefit (if any) is to performing a full backup on X day instead of performing constant incremental backups? We are new to Veeam but are starting to roll it out to quite a few of our clients. So far we are really pleased with it .
TIA
-
- VP, Product Management
- Posts: 27368
- Liked: 2798 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Enable full backup on these days
Hello Ollie,
There are lots of cases where due to internal backup policy you have to do Full Backups only, that's what first comes to my mind.
There are lots of cases where due to internal backup policy you have to do Full Backups only, that's what first comes to my mind.
-
- Chief Product Officer
- Posts: 31792
- Liked: 7295 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Enable full backup on these days
Regulatory compliance is pretty much the only reason to do periodic full backups. Some customers have requirements to perform full backups every day, basically this option is for them.
But for most customers, it is not needed. Forever-incremental is way to go - which is why it is disabled by default. We did not even have this option until v4, to start with
Manually initiated full backup is what may come handy sometimes, for example after changing job content settings and removing some VMs from the job.
But for most customers, it is not needed. Forever-incremental is way to go - which is why it is disabled by default. We did not even have this option until v4, to start with
Manually initiated full backup is what may come handy sometimes, for example after changing job content settings and removing some VMs from the job.
-
- Novice
- Posts: 3
- Liked: never
- Joined: Apr 29, 2010 12:32 am
- Full Name: Fabian Moreno
- Contact:
Re: Enable full backup on these days
I just wonder if I activate this option, is still necesary activate the schedule check box determining at what time?
-
- Chief Product Officer
- Posts: 31792
- Liked: 7295 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Enable full backup on these days
Yes, you still need to enable "main" schedule checkbox, or the job will not run automatically.
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Enable full backup on these days
Actually, there are many reasons to preform a full backup every now and then. Here's a few of my reasons:
1. Data Integrity/Safety -- While I generally trust the integrity of Veeam's backup files, when running "incremental forever" this increases the possibility that a single error in the "main" file can actually cause all previous backup to be "non-restorable". The cause of this corruption may or may not be the fault of Veeam itself. For example, the recent issue with CBT where a corner case could potentially cause all future incrementals to be invalid. Other scenarios might be a backup server or storage system crash that corrupts the "main" vbk. If you lose that single VBK file, all previous rollbacks are of no use.
2. Data Optimization/Removal -- At least with current generation Veeam products, if a VM is removed, it remains forever listed in your backup file, the only way to remove it is by running a full. This can happen even if a VM simply changes it's UID, which might happen if it's restored from backup or moved to a new cluster. We've also found that VBK files have a tendency to "grow forever" and running a full every so often generally results in a fresh VBK that's 5-10% smaller than the original.
3. Data Retention -- We've found that running a full backup can really be leveraged for data retention policies. Many companies like us have requirements to keep "monthly" backups for some period of time, and yearly backups for another period of time. For example, we generally keep 12 monthly backups and 3 yearly backups. We leverage our "full backups" to keep these monthly and yearly retentions by using a simple Linux script that is triggered from the Veeam backups which creates a "hardlink" of the file in a "Retention" folder. Veeam goes about it's normal retention policies and removes the full after 30 days, however, since there's a "hardlink" the file actually stays in the "Retention" folder. If we need to restore it we simply import it into Veeam. This way we don't have to have separate "monthly" and "yearly" jobs, and we never have to copy our VBK files around either.
1. Data Integrity/Safety -- While I generally trust the integrity of Veeam's backup files, when running "incremental forever" this increases the possibility that a single error in the "main" file can actually cause all previous backup to be "non-restorable". The cause of this corruption may or may not be the fault of Veeam itself. For example, the recent issue with CBT where a corner case could potentially cause all future incrementals to be invalid. Other scenarios might be a backup server or storage system crash that corrupts the "main" vbk. If you lose that single VBK file, all previous rollbacks are of no use.
2. Data Optimization/Removal -- At least with current generation Veeam products, if a VM is removed, it remains forever listed in your backup file, the only way to remove it is by running a full. This can happen even if a VM simply changes it's UID, which might happen if it's restored from backup or moved to a new cluster. We've also found that VBK files have a tendency to "grow forever" and running a full every so often generally results in a fresh VBK that's 5-10% smaller than the original.
3. Data Retention -- We've found that running a full backup can really be leveraged for data retention policies. Many companies like us have requirements to keep "monthly" backups for some period of time, and yearly backups for another period of time. For example, we generally keep 12 monthly backups and 3 yearly backups. We leverage our "full backups" to keep these monthly and yearly retentions by using a simple Linux script that is triggered from the Veeam backups which creates a "hardlink" of the file in a "Retention" folder. Veeam goes about it's normal retention policies and removes the full after 30 days, however, since there's a "hardlink" the file actually stays in the "Retention" folder. If we need to restore it we simply import it into Veeam. This way we don't have to have separate "monthly" and "yearly" jobs, and we never have to copy our VBK files around either.
Who is online
Users browsing this forum: alex.lyss, CaptainTightPants, mattskalecki and 87 guests