VeeamON 2024 - Use Code "COMMUNITY10" for 10% Off!
I work pretty heavily with backups in my current role, and we use your product and another product with some of our clients. The other product has a feature that is incredibly helpful and I think would be an amazing feature to add to Veeam. How feasible would it be to add a “Force Retention” feature? I really believe we need this for situations when we run into low disk space. In Veeam’s current state, if I run into an issue where I need to reclaim disk space, I am forced to break my backup chain and delete data. If I could lower retention on my backup and then force retention, that would effectively eliminate the need for me to have to lose data and break a backup chain. For example: if I am in a situation where I am getting failures due to low disk space, and I have retention on said backup job set to 30 days, if I could cut retention down to, say, 20 days, and force retention, I could maintain my current backup chain and then address the disk space issue accordingly (adding
Thanks for sharing. Veeam’s angle has always been that your retention policy is the minimum amount of restore points to keep, as defined by you, and it’s recommended to set a suitable % alert threshold for when you need to address this as the repository should always have sufficient working space for the backups. Are you using these volumes with something other than Veeam Backup jobs? As if you’re using reverse incremental for example, your chain will automatically truncate after each backup to maintain your retention point. It may be worth looking at a different chain type if it’s more suitable. I’m glad you mentioned that. I am still trying to understand all of the chain types and reverse incremental is one that I am not super familiar with. When you’re in a situation where you have limited disk space and not necessarily a way to get more, would reverse incremental be the way to go? Thank you so much for the replies.
Mhh, this would be a useful function, but I think it is very difficult to realize. When you are doing forward - for example -incremental backups with a retention of 4, then you have up to 7 versions in your repository before an old version is deleted. Theoretically the version from sunday could be deleted on thursday. But the backups from monday to wednesday depend on the full backup from sunday - so it cannot be deleted without invalidating the depending backups and violating the retention of 4. After the backup is done on the next sunday and a new backup chain with 4 versions is complete the complete chain from sunday to wednesday is deleted. To be able to delete a version earlier you would have to migrate one of the incremental into a full or you would habe to change the whole thing into a reverse incremental chain. Both approaches need space in your reporsitory. I could imagine a function you are describing with a file based backup system like Spectrum Protect. There you can
Hello @bp4JC no problem, my beginnings with backup were hard, too VEEAM uses with forward incremantal method backup chains with incremental backups which depends on the last full backup, which is here the odest in the chain. In the picture the backups from sunday to wednesday are one chain. On thursday a new full backup (a synthetic one) is created. This is the fifth restore point in your repository and you could (in theory) delete the point from sunday and you would fulfill your retention of 4 versions. But you cannot delete the restore point from sunday because the incremental backups from monday, tuesday and wednesday depend on the full backup from sunday. Without the full backup the incrementals are useless. In this case you would have only one restore point available (the restore point from thursday). In order to fullfll your retention of 4 you have to wait until the next sunday, then you have a complete chain (Full from thursday and 3 incrementals depending on it). Now the old
Great conversation here! @bp4JC, you can also enter that as a feature request in the Veeam R&D Forums as we don’t ensure all of the FR’s are seen by Veeam Product Management in this community site. Thank you for the heads up on this. I have posted it there as well :)
Just as the message states it is waiting on resources like a Proxy server to complete the backup copy process. Usually, if servers don’t have the resources to process the number of disks in a VM then it has to wait. Thank you for responding! In this situation, I am guessing concurrent tasks are the bottleneck. This error does not usually occur. Does the copyjob not do a retry in this situation? What I don’t understand is this copyjob is set to mirror on a continuous schedule, so I wouldn’t think there’d be a reason for it to error out or give a warning, and that the job would just run until it finished.
This should be no problem. As Chris and Paul already said it is just waiting for the neccessary ressources. In this pictures you see that this VM has waited for 22 minutes and then was processed without any issue… In this environment I see this every day, just don’t have so many cores here... I apologize for my lack of knowledge on this. I received an alert in our ticketing system that the copyjob finished with a warning, and it pointed to this one particular VM. I checked the copyjob and it looked like it wasn’t running, and that particular vm was sitting in a warning status. I was confused because the job is set to run continuously, so I didn’t see a reason for the job to stop and say “Hey. Not enough resources. Better luck next copy interval!” All of the copies are going to the same location. If I am understanding correctly, the job should run until all current restore points are offsite, correct? If that is the case, why would a warning be thrown, rather than the VM just be put in
Hey, this normally means that your time set for syncing within expired before some VMs were copied. If this was an incremental backup copy then it was likely just a transient issue of bandwidth or too large a delta of blocks changed between backups to shift off in time. Depending on your WAN speed it may be worth looking at WAN acceleration if your supplier supports this. I was thinking it may have been a time expiration issue, but I looked at the scheduling and it’s set to continuous run and to run whenever new restore points are available. After I posted this, I had failure notices come in with the same message. It went from a warning to a failure. I have seen errors that said “some vms failed to process during copy interval.” but this one just said “Some restore points were not processed.” It’s very strange. I was able to get a successful “Sync Now” but I am just wondering what happened and what can I do to prevent it? Thanks so much for your answer!
Did all the VMs you backup have a new restore point created? If nothing new was created during the cycle (of which you’re triggering a new one when you sync now) then that would generate the message also I believe so. They’re all part of 1 job that runs every couple of hours. The failure that occurred afteward make sense now that you ask that. When I ran the sync now, I think backups were happening and I didn’t realize it when I ran it. That may have been why the failure appeared. But when the warning initially occurred, all VMs had already backed up successfully (all as part of a single backup job) and that copyjob was running to move those latest restore points over. My understanding is that a warning does not indicate a failure and if I am understanding correctly, even if I had had a disaster recovery scenario, my data would have still be offsite?
@bp4JC, you say the job is running continously. Is it possible that the VMs with the warning do not have a new restore point since the last run of the copy job. I have seen this with continous tape copy jobs. The job gives warnings because there are two jobs included with a weekly schedule. Hey, JMeixner! There should have been new restore points for all of the VMs. They are all part of the same backup job that runs about every two hours. The copyjob is set to kick off whenever new restore points appear. As I type this, the thought occurs to me: is it possible that the copyjob started and finished, but there were still VMs backing up in the backup job and so the copyjob threw a warning because it didn’t copy over everything due to some vms still backing up? With it set to continuous/whenever new restore points appear, is this even possible?
@bp4JC, you say the job is running continously. Is it possible that the VMs with the warning do not have a new restore point since the last run of the copy job. I have seen this with continous tape copy jobs. The job gives warnings because there are two jobs included with a weekly schedule. Hey, JMeixner! There should have been new restore points for all of the VMs. They are all part of the same backup job that runs about every two hours. The copyjob is set to kick off whenever new restore points appear. As I type this, the thought occurs to me: is it possible that the copyjob started and finished, but there were still VMs backing up in the backup job and so the copyjob threw a warning because it didn’t copy over everything due to some vms still backing up? With it set to continuous/whenever new restore points appear, is this even possible? Yep, if you run a report for your backup job then compare the times that should give you an understanding of
Can we still get a t-shirt if we’re already a member? I would love one.
Enjoyed the ransomware session I want to go back and watch the recording on this one!
Can we still get a t-shirt if we’re already a member? I would love one. No, the t-shirt is for new members only. At least up to this time Bummer. I am really wanting to get a hat or t-shirt of some kind.
Enjoyed the ransomware session I want to go back and watch the recording on this one! Why don’t you do it? But I would recommend to wait until the new live sessions are over. Otherwise you have to watch even more sessions as recordings. I was not aware the convention was happening. I joined last minute and am not able to attend everything due to schedule. I really do want to watch it though. I was asked about Veeam’s ransomware protection recently, and I was not sure how to answer the question.
Can we still get a t-shirt if we’re already a member? I would love one. No, the t-shirt is for new members only. At least up to this time Bummer. I am really wanting to get a hat or t-shirt of some kind. Didn’t you get a VeeamOn swag pack? You should have gotten one if you regstered before May 5th... I didn’t register on time. I literally had no idea this was going on until today. I’ll make sure to register early for the next one. I am super bummed. It’s ironic because I was thinking about, this morning, that I would love a Veeam hat or laptop bag or something and I went to the main site to see if there were a product store of some sort, but there is not, and then I found out about the swag pack if you registered early!
Hello @bp4JC , did you see this page? https://helpcenter.veeam.com/docs/agentforwindows/userguide/onedrive.html?ver=50 I assume there is an authorization problem... I’ll take a look at the job. When it was setup, we did sign into their One Drive when we went through the job creation wizard. We were getting successful backups and then they just started erroring out.
Hmm...according to the documentation for VWA, you indeed can backup to OneDrive. It appears you’re not running a Server OS, as I believe the OneDrive option would be greyed out. I assume you set the credentials required for OneDrive? Did you follow the steps here @bp4JC ?? I was able to set the job up successfully and get them authenticated with One Drive during the setup, and we were getting good backups for a while, and then they just started erroring out with the errors I listed.
Further to checking the documentation provided by others and this is just shot in the dark but did the user’s password to OneDrive change? Not sure if relevant and if so ignore this but something basic to possibly check. This is a great suggestion. I don’t think it has, but I’ll double check that.
Hi @bp4JC ..yes, that is correct. Is this a new Copy Job? It’s one that we’ve had running for a while. We have a new server in place and I am running into issues getting the full copied over. I guess at this point it will be an incremental and the needed blocks. If it goes from 4 to 4, what causes the copy interval expiration issues? Wouldn’t it just keep going?
But, you could have an issue copying the full chain of the source backup job you’re referencing. For example, if the source backup job chain you’re copying from is a week long, you would need to expand your interval to 7 or 8 days, or otherwise your interval setting would be out of scope. After your source full chain has been copied, you can set the interval to a lesser period...for example, 1 day. And this is assuming your source backup job runs at least daily. This would ensure you get the most current data from your source job. Let me know if you have further questions...and yes, it is indeed a bit confusing. I’m actually doing a series of posts here on the Community Hub regarding Copy Jobs :) For more info on how Intervals work, review the User Guide here. And, if you wanna read my posts, you can start here. Cheers! If I default my copyjobs to 7 or 8 days and leave them that way, will it hurt anything?
Ok, so then that’s a little different. I assume you probably have the needed chain already copied over. But, if you’re running occasional Active Fulls for GFS retention options (wkly, mthly, yrly), then even if the Interval isn’t long enough to complete the Full being copied over, the Interval will automatically be extended until it completes (see description here). Other Copy runs should be Increments...and they should be able (hopefully) to get copied over in a day’s time. I made the change to the job and I made it 10 days. I told it no when it asked me if I wanted to restart the job. I don’t want to interrupt what’s already happening.
“If I default my copyjobs to 7 or 8 days and leave them that way, will it hurt anything?” You probably don’t need to. I think you can find the answer to your question from the Interval link I provided above. It states what happens if your Copy doesn’t complete in the configured Interval time. I’ll check them out. Thank you so much for your answers!
Check your copy interval and raise it up. Some times you need to play with this to tweak it. See here - https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_name.html?ver=110 Hi, Chris! These jobs are set to immediate copy mode. Would a copy interval still be in play? Weirdly, I do get RPO alerts for said jobs and the runtime can be accurate in terms of days, in those alerts.
Hi @bp4JC , if you implement immediate copy jobs, then it will copy new restore points as soon as they are available in the backup-job itself (works differently then periodic copy jobs). A best practice is that the copy-jobs is set to continuously. I prefer that way and use throttling if the job should impact your network during business hours. At what frequency are your primary backups scheduled? When it is not possible for the copy-job to copy between 2 restore-points in the primary backup job, it tries to catch up if possible. What speed are you having in your copy-job? What is the bottleneck showing? Hi, Nico They are set to run whenever a new restore point is available to copy over, 24 hours a day. It is immediate copy with 24 hour schedule. I am not seeing a bottle neck listed when I view the backup, but I imagine it will probably be the backup server itself. Speed-wise, one is about 57MB/s, and the other is showing 405KB/s. I am not sure if that is accurate on that one. I see i
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
