Behavior in the event of aborted job
The short version:
----------------------
For backing up to zip files, please give the user a configurable option whether or not to delete zip files that have been created in the event of a backup failure.
The back story:
-------------------
I back up to zip files so that I can restore them with any Zip utility if the Backup4All program is not available.
I recently obtained a new laptop at work, and used Backup4All to transfer all of the data from my old laptop to my new one. This ended up being a much bigger pain in the behind than I had planned on. Whether due to a failing hard drive on the old laptop, intermittent drive seek failures on the new one (though SMART on the new drive seems to think the drive is performing acceptably), or an interaction between packet writing and hard drive encryption on one or both laptops, I could not reliably transfer data directly from one laptop to the other.
My Backup4All settings included making a local backup catalog, backing up to independent 4.7GB zip files, and using the alternate zipping method that adds entire compressed files to the zip file.
What would happen is that I would let the job run (overnight in one case, or for 8 hours when I retried with some of the larger files omitted from the job), and it would write some 7 or 8 zip files. Then I would see an alert that the job had been aborted. On reviewing the log, the terminal sequence of events was:
1. Added file <filename>
2. Close catalog file <catalog filename at source location>
3. Error: Backup aborted. Reason:
Cannot add file <another filename> to <zip filename in destination location>.
Zip error:
Seek error
Files skipped: 1
Backup aborted at <timestamp> with 1 error(s), 1 warning(s)
Unfortunately, the other thing that happened was that Backup4All then proceeded to delete all of the zip files that it had created for this job, not just the last one with the seek error.
Tracking down the cause of the error is a whole different issue, but the problem for me was the amount of time spent creating perfectly usable zip files (and I know they were usable, because I was extracting from some of the earlier ones as the backup job was progressing, writing the later ones), only to have them summarily deleted when a single error was encountered at the end of the job.
Adrian suggested that I try checking another setting, to write the zip files to a temporary file before committing them to the destination location, but I didn't have time to try that -
1) I didn't know whether the temp file would be written to the source laptop or to the destination laptop, and there wasn't enough room left on the source laptop's drive.
2) I didn't know if the change was intended to resolve the seek error problem or the "abort the job and delete all of your work in case of error" problem.
3) I didn't know the cause of the seek error problem, or how this configuration change would address it (if that's what it was meant to address).
4) If the problem was related to the encryption software on the laptops (as I suspected, since SMART said the destination drive was fine), I had a low expectation of resolving the seek error problem.
5) I had been using Backup4All to backup parts of my system 5 days a week to a network file share for months, without any problem. The network drives are not encrypted. I thought my best shot at success, though slower, was to backup to the network drive and then restore from the network drive to the new laptop.
To be fair to Adrian, I don't think I told him my laptops both have encrypted hard drives.
So, for the next 3 days, I backed up to the network drive, and the day after that I restored to the new laptop.
And my source laptop filesystem became badly corrupted the same night that the backup finished.
All's well that ends well, I did succeed at getting all of my data onto the new laptop (though with screwed up capitalization on a number of filenames and folder names). However, "disappointed" would not begin describe how I would have felt if that last backup attempt had failed again AND all of the work had been lost in the middle of the night because I didn't have the option to specify to keep the incomplete zip files in the event of backup failure.
Rebeccah
----------------------
For backing up to zip files, please give the user a configurable option whether or not to delete zip files that have been created in the event of a backup failure.
The back story:
-------------------
I back up to zip files so that I can restore them with any Zip utility if the Backup4All program is not available.
I recently obtained a new laptop at work, and used Backup4All to transfer all of the data from my old laptop to my new one. This ended up being a much bigger pain in the behind than I had planned on. Whether due to a failing hard drive on the old laptop, intermittent drive seek failures on the new one (though SMART on the new drive seems to think the drive is performing acceptably), or an interaction between packet writing and hard drive encryption on one or both laptops, I could not reliably transfer data directly from one laptop to the other.
My Backup4All settings included making a local backup catalog, backing up to independent 4.7GB zip files, and using the alternate zipping method that adds entire compressed files to the zip file.
What would happen is that I would let the job run (overnight in one case, or for 8 hours when I retried with some of the larger files omitted from the job), and it would write some 7 or 8 zip files. Then I would see an alert that the job had been aborted. On reviewing the log, the terminal sequence of events was:
1. Added file <filename>
2. Close catalog file <catalog filename at source location>
3. Error: Backup aborted. Reason:
Cannot add file <another filename> to <zip filename in destination location>.
Zip error:
Seek error
Files skipped: 1
Backup aborted at <timestamp> with 1 error(s), 1 warning(s)
Unfortunately, the other thing that happened was that Backup4All then proceeded to delete all of the zip files that it had created for this job, not just the last one with the seek error.
Tracking down the cause of the error is a whole different issue, but the problem for me was the amount of time spent creating perfectly usable zip files (and I know they were usable, because I was extracting from some of the earlier ones as the backup job was progressing, writing the later ones), only to have them summarily deleted when a single error was encountered at the end of the job.
Adrian suggested that I try checking another setting, to write the zip files to a temporary file before committing them to the destination location, but I didn't have time to try that -
1) I didn't know whether the temp file would be written to the source laptop or to the destination laptop, and there wasn't enough room left on the source laptop's drive.
2) I didn't know if the change was intended to resolve the seek error problem or the "abort the job and delete all of your work in case of error" problem.
3) I didn't know the cause of the seek error problem, or how this configuration change would address it (if that's what it was meant to address).
4) If the problem was related to the encryption software on the laptops (as I suspected, since SMART said the destination drive was fine), I had a low expectation of resolving the seek error problem.
5) I had been using Backup4All to backup parts of my system 5 days a week to a network file share for months, without any problem. The network drives are not encrypted. I thought my best shot at success, though slower, was to backup to the network drive and then restore from the network drive to the new laptop.
To be fair to Adrian, I don't think I told him my laptops both have encrypted hard drives.
So, for the next 3 days, I backed up to the network drive, and the day after that I restored to the new laptop.
And my source laptop filesystem became badly corrupted the same night that the backup finished.
All's well that ends well, I did succeed at getting all of my data onto the new laptop (though with screwed up capitalization on a number of filenames and folder names). However, "disappointed" would not begin describe how I would have felt if that last backup attempt had failed again AND all of the work had been lost in the middle of the night because I didn't have the option to specify to keep the incomplete zip files in the event of backup failure.
Rebeccah
-
Adrian (Softland)
- Posts: 1950
- Joined: Wed Dec 16, 2009 12:46 pm
Re: Behavior in the event of aborted job
Hi,
As a zip is corrupted, the backup catalog file would not be able to restore that zip and the entire backup is compromised.
That is why all files were deleted from destination. You won't be able to restore them with Backup4all with no backup catalog.
I created a ticket for our developers to save the catalog without the corrupted zip, while the files from the corrupted zip will be marked as "not backed up".
As a zip is corrupted, the backup catalog file would not be able to restore that zip and the entire backup is compromised.
That is why all files were deleted from destination. You won't be able to restore them with Backup4all with no backup catalog.
I created a ticket for our developers to save the catalog without the corrupted zip, while the files from the corrupted zip will be marked as "not backed up".
Do you know you can monitor your backups remotely with Backup4all Monitor? You can read more here: https://www.backup4all.com/backup4all-monitor.html