Restore doesn't seem to progress?

[tjeff]

Running Zmanda 4.1 on Windows Server 2008 R2, SP1. We're attempting to complete a restore, but it seems that Zmanda is just hanging while it tells us it's attempting to restore.

I've already ensured the machine name is the same and that it is at the same patch level as the other server, imported the certificate, downloaded the restore catalog, etc. I go to the Restore tab, pick the File Backup I had made, check the radio button to recover to the original location, tell it to overwrite existing files, and then tell it to restore. Initially, it sat at 'Analyzing Metadata' for 2 and a half hours, with AMZS3Controller.exe hammering the CPU to 99%. I cancelled the restore, added a CPU to the VM, then restarted the server and attempted the restore again. Now, it's been sitting at "Checking Archive Consistency" and has been for about 2 and a half hours.

If I open Resource Monitor, I see absolutely no disk or network activity, and I see AMZS3Controller.exe sitting at about 60% usage on one CPU and 70% usage on the other. Is there any real indicator as to the progress? Is this expected? Am I doing something wrong?

Any help would be appreciated.

Thanks!

EDIT: Some additional info: Running on a quad core 2.5GHz machine running CloudStack, and this is the only VM on it at all, so it should be OK from a resource perspective. The full backup set is only about 10GB or so, and we've got an 80MBps pipe (yep, big B), so there should be no bandwidth issues.

[bberenberg]

Hey Tjeff,

This means that ZCB is checking the CRC of the archive, please allow it to run till it either fails on it's own or finishes. The current feedback to the user during the restore process is not the best and we plan to improve it in future versions.

Regards,
Boris

[tjeff]

Hey Tjeff,

This means that ZCB is checking the CRC of the archive, please allow it to run till it either fails on it's own or finishes. The current feedback to the user during the restore process is not the best and we plan to improve it in future versions.

Regards,
Boris

Well, it's been running now for 18 hours and still has no progress -- is this still expected behavior?

[bberenberg]

Well, it's been running now for 18 hours and still has no progress -- is this still expected behavior?

What is the total compressed data size? And what is the uncompressed data size? Are you using encryption? Take a look at the restore directory and check the size of it 10 minutes apart. If it is changing, then let ZCB chug along. If it is not, then you should collect logs from the Help menu and open a case on http://network.zmanda.com and we can look into the issue further.

[tjeff]

What is the total compressed data size? And what is the uncompressed data size? Are you using encryption? Take a look at the restore directory and check the size of it 10 minutes apart. If it is changing, then let ZCB chug along. If it is not, then you should collect logs from the Help menu and open a case on http://network.zmanda.com and we can look into the issue further.

Total compressed data size is 16.5GB. The uncompressed data size is 40GB. We are not using encryption on the image files. The restore directory was actually empty for about 15-18 hours of the restore process -- it wasn't until it actually started downloading at about 18 hours that it started filling that directory. It then completed the download in about an hour and a half and the restore in another 30-45 minutes, however the machine did not boot in a usable state. I'm hoping it was something sporadic with the server, I've removed the instance and restarted from scratch in the hopes of completing a successful test this time. Will update as I attempt the restore again.

EDIT: Apparently it was something sporadic with that specific setup. I recreated the instance from scratch, re-installed Windows, Java, ZManda, downloaded the catalog, then attempted the restore again -- this time it took less than 15 minutes to complete the Analyzing Metadata portion of the restore and has already moved past it to downloading. Not entirely certain what caused it to get stuck in a loop, but whatever it is seems to have disappeared. It's restoring now at a fairly decent speed.

It's worth mention that after restoring the file backup last time, I attempted to restore the system state backup (as detailed in the restore guide as the following step) and when I opened ZManda and pointed it to the system state, the lower pane never populated (regardless of what backup I had selected at the top) and the "Restore" button was never engaged. As I've wiped that server out entirely to start again, I can't really do any further testing against it -- but if that's a common issue or something that happens if I overlooked something, please let me know.

Thanks!

[Eric_R]

Total compressed data size is 16.5GB. The uncompressed data size is 40GB. We are not using encryption on the image files. The restore directory was actually empty for about 15-18 hours of the restore process -- it wasn't until it actually started downloading at about 18 hours that it started filling that directory. It then completed the download in about an hour and a half and the restore in another 30-45 minutes, however the machine did not boot in a usable state. I'm hoping it was something sporadic with the server, I've removed the instance and restarted from scratch in the hopes of completing a successful test this time. Will update as I attempt the restore again.

If you continue to have trouble, please open a support case by clicking Help -> Contact Support. We will be glad to assist you further.

Thanks,
Eric
Zmanda Support

[tjeff]

If you continue to have trouble, please open a support case by clicking Help -> Contact Support. We will be glad to assist you further.

Thanks,
Eric
Zmanda Support

Sure thing. Just to update, the restore proceeded successfully -- not sure why it was a problem before. Restored the file set, then the system state, then the SQL data. Everything works except for the SQL Reporting Services. I didn't find any information in the documentation that would cover any post-backup steps needed to fix SQL Reporting Services, so I'm trying to truck through it now to see if I can fix. I didn't want to open a support case for it because I'm not 100% certain that this is an issue with the backup -- it could be a configuration issue that's causing the erratic behavior. If I can't get it situated shortly, I'll pop in a case.

Thanks much for the help!

[Eric_R]

Hello,

If you're still having trouble, please open a new support case as outlined above.

Thanks,
Eric
Zmanda Support