Lost 2TB of backups after Convert Full?!?!?!
So I have a backup plan that replicates the backup to a 2nd storage node. This storage node is to be used as Offsite Backups. Since I want the offsite storage to contain a point in time backup (yesterday) as opposed to the full history of backups I have on my primary storage node on-site, I used the 'convert full' option on the last backup on the offsite storage.
According to all documentation and information I have, should take that backup and rollup all previous backups into a single full. I should then be able to delete any and all previous backups, keeping only the full that was just created.
Well it didn't quite work that way, and in the process seems to have changed the backups on the PRIMARY storage node also.
The ORIGINAL full backup I had of this server is 3TB in size. I then have monthly differentials and some incrementals. I was expecting the last backup would be around the same size once I used the convert full on it. That is not the case. The new backup is only 1TB in size AND the ORIGINAL FULL dropped to 1.6TB in size. WHAT???
But the real fun part is when I checked the primary storage node, the ORIGINAL FULL backup ALSO dropped to 1.6TB in size. WAIT WHAT?? I didn't do anything on that storage node. Why did that change?!?!?!
Did I just loose 2TB of backups with this operation??
Hello Carl Constantine,
Thank you for using our forum. I understand your problem and I am glad to help you solve your problem.
I want to thank Heiko Helmle for supporting you.
In our online help, you find a good example, how this feature works. Depending on the backup chain, it is possible that the volume of other backups in this chain will change. Big operations take time to finish. You may have to wait for the result. However, this function never deletes any content of your backup.
If you need additional assistance, feel free contacting support. Find more information about available support options in our Customer handbook.
Please let me know if you have additional questions.
Thank you.
But the other thing I'm concerned about is there was a file size change in the primary storage node as well, NOT just the offsite node. If I delete all the other backups in the offsite storage node, and only keep the "new" full, would all the data indeed be there (3TB Worth) that's what concerns me greatly.
And, we're not using DeDupe at all.
Here are some screenshots. One showing the original full backup storage size from a previous backup. (I had exported the original backup from an unmanged vault to a managed vault some months ago).
Then there is the New backup file sizes AND how the backups appear on the off-site storage node where I did the convert full operation.
Does the backup validate?
Can you restore single files from the backup?
Can you export the backup? What size is the export?
Hello Carl Constantine,
Thank you for the quick reply.
I want to thank Heiko Helmle for supporting you.
I understand your concerns very well. I have looked at your screenshots and colleagues showed. However, without an analysis we cannot make any precise statement.
Therefore, I would recommend contacting our support. The colleagues can analyze the situation and determine whether all data is present and whether the change in size is a problem or not. Find more information about available support options in our Customer handbook.
Please let me know if you have additional questions.
Thank you.
I am about to test a restore from the 'converted' full backup to see if I get everything back, but that will take a while as the backup is a couple TB in size and over a 1GB link is going to take a LONG time. I'll keep you posted.
A validate only verifies the integrity of the backup, it doesn't verify that everything I need is there, so I'm not sure how that will help.
ok I have some hard results.
I did a restore of the converted full backup on the replicated storage node to a server where we had some space to use. It took a couple days to restore all the data (almost 2TB total) but it finally completed.
I then used a program called, TreeSize Free by Jam Software (http://www.jam-software.com/freeware/index.shtml) to do a scan of the restored directory, and the actual directory on the file server. What I found is quite interesting.
So, taking into account that the restored full is from Nov 8 and today is Nov 19 (11 days later), it still looks like there is missing data. Exactly how much or where is hard to determine without a LOT of effort, unless someone knows another way to compare directories and file sizes more easily??
I've attached screenshots showing the Treesize of the Restored directory and the original. Note not only the file size difference (60 GB worth or so??) but also the number of files in the directories. While I could possibly see a 60 GB difference easily enough between the dates. I don't see a 100,000 file difference in just 11 days!
I've also attached a standard windows properties of each directory.
is this a file based or image-based backup? On image-based backups this should'nt be possible (unless you have some exclude filters set up)
Could it be possible that some of the files in the tree are excluded by an exclude mask or by some automatic mechanism (exclude hidden/system files). If (for example) Acronis omits every "Thumbs.db" that could be one per subdirectory - and it looks like you have many subdirectories.
for better file system diffing try a good Diff-Tool (Beyond Compare for example) - that should be able to diff across folders - I don't know if it is able to diff over such a large dataset.
Or - for an easy check:
DIR /S /ONG current dir > current.txt
DIR /S /ONG restore dir > restore.txt
and then diff current.txt against restore.txt - this should give you a detailed list of the changes (use either Beyond Compare or kdiff3 or your favourite text compare tool)
This is a file based backup. I have 1 full backup and do incrementals and differentials (weekly). I only keep 1 differential as a monthly instead of doing a monthly full as the data is just too big. This is why I was wondering about the whole 'convert full' option on the secondary storage node.
The dir command is producing long file paths so it's not really going to work correctly. Will take a look at a couple other options you mentioned.
Actually, I stand corrected. I backup an entire hard disk volume in the backups.
I`d love to hear an update on this issue.. I too work with offsite backups, and so far, its been a big PITA.
I haven't found anything that works with such a large dataset to diff with and quite frankly gave up as I had to recover the space on my test server to use for an emergency issue.
I don't think that the convert_full command ON THE OFFSITE VAULT should have affected the dataset in the PRIMARY vault the way it did, and now I question the integrity of the full backup from my primary vault.