-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when medium is running out of space? #78
Comments
A precheck is not a bad idea. When things crash, there often are remnants and if it crashes, there won't be of course email sent. |
Below the email I received when I cleaned up the backup medium and restarted the backup again. I don't know Python but in my C# and C++ code I wrap all functions into a
|
Yes, python has a try/except construct that could be used to that extent. Note that cleanup does take place if an old attempted backup is found using process_backup_dir(tmp_vm_backup_dir) and the embedded function get_last_backup_dir_that_failed, so this does get cleaned up, but not until the next run. The issue is currently that if the script fails or is killed off by someone, any pre-cleanup may not be caught in time to act upon, hence the checking for failed backups when the script is launched afresh. In part, it's a matter of philosophy of approach. This check is done both for VDI and full VM backups. |
As to a precheck, what might be useful: A warning if the available space is over 90% full? If the backup fails, the nature of the failure would have to be understood (such as the lack of disk space). I don't think the script would be clever enough to trap the condition that caused the failure., and usually if something happens with a VM, it typically is desirable to go ahead with the others, assuming the error only affected the one VM. |
I think 90% is just a number and in my situation it wouldn't help as you can see from the above email. SBS needs 60% of the total space of all VMs. As I mentioned before adding the possibility to remove the oldest version FIRST would solve this problem. Yes, it is my logical mistake that I didn't consider this when I created the iSCSI storage for the backup. The point is that now the NAS is almost full and it is not that trivial to reorganize it because then I have to change all storage assignments. |
Could maybe do this: Look for the largest existing backup for a VM and see if there is at least that much space still available (+10% or so) before starting a backup series on a particular VM? Would have to handle both NFS and CIFS storage. |
While I ran into #77 I think these issues exist:
May be you find time to check it out.
Thank you
The text was updated successfully, but these errors were encountered: