Alright, got a strange issue with Toucan. I plopped it on my domain controller, a Server 2003 box, and set it to run as a task, as administrator, and backup a second hard-drive in the system to an external HDD after hours when nothing is in use. I chose differential and it seems to work, but the problem occurs down the road. What I noticed is that the base file is created and works (will open in 7-Zip), and the first differential file works, but the third backup and beyond do NOT work. For example, I create a new base file every Sunday. This file works. Monday it creates a differential file. This file works. Tuesday it creates another differential file, and this won't open at all. Not only that, but upon logging into the server, I get the crash dialog stating that Toucan.exe has had to close. No idea why this happens, but it has something to do with the third backup. Every time like clock-work it fails on the third backup day. What's possibly wrong here?
I'll take a look at this, no-one else has reported so as for as I know there are no issues!
Can I ask how big the file is? Also what variable you are using for the file name? Are you backing up to zip or 7zip? Thanks
I am using 7-Zip. The base file is around 20GB~25GB. The differentials vary in size from a few megabytes to a few gigabytes based on how much data has changed or been added to our server. I am using default compression, nothing fancy. The system has two AMD Athlon MP 2800 processors and 3GB of ECC RAM. It should be more than enough to run Toucan to backup a drive containing 48.9GB of data. Oh and we do this an hour after we leave, so nobody is in QuickBooks or anything. All file handles are closed to that drive at this point in the day.
As for the filename, your differential backup doesn't ask for one. Remember, it has you select a folder to backup to, and nothing more. The backup location is "B:\Drive-D". I am backing up our D: drive, and Toucan runs from our C: drive. One thing I have noticed however, is that Toucan seems to be quirky with the backup location for differentials. On our two other servers (one 2003, one 2008), I had to select "B:\Drive-D\" by manually adding the trailing slash or it would backup directly to "B:\". On this 2003 machine however, I simply browsed for the directory "B:\Drive-D" and it works fine without the trailing slash. That seems ODD to me. It's like on some systems you have to add a trailing slash and others you don't.
Any update on this subject? I must admit that my other Server 2003 box has been using this for over a month and it works wonderfully, so I'm starting to wonder if this server has some software on it that is causing Toucan to crash. Both run Symantec Endpoint Protection, both run IIS, both run DHCP and DNS, and both run AD. However, this one runs a Quickbooks server and I am beginning to believe it may be the problem. Is there any way that I can enable some advanced logging in Toucan to see what happens when it crashes?
Found this in the event log after it failed at 1:16 this morning. Nothing was running at that time. I am beginning to think that Toucan and Server 2003 don't like each other.
Faulting application Toucan.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.4455, fault address 0x0001bd02.
The application, C:\Program Files\Toucan\App\toucan\Toucan.exe, generated an application error The error occurred on 03/26/2010 @ 01:16:20.468 The exception generated was c0000005 at address 7C81BD02 (ntdll!ExpInterlockedPopEntrySListFault)
thanks for all this feedback, I am hoping to work on this in time for the next Toucan 3 Development Test, thanks again
Well it's good to see that the information is being reviewed. The odd thing is that sometimes it works and then other times crashes. I logged in this morning and remoted into our server to get a warm greeting by two reports of Toucan.exe crashing. One happened Friday about an hour after the backup process started, and the other happened Saturday about five or six hours into the creation of a new base file. In other words, it crashed every night this past week so I have an entire week of data that is not backed up.
I did do some testing however. I wrote a script to kill off all processes we don't need during the backup, such as the Quickbooks online backup stuff that runs right after the close of business each day. I also have a script in place that reboots the server every morning at 6am, so uptime shouldn't be an issue.
Not sure why it's doing this but if you need any specific information, let me know. As it stands, I am running it on a server that has the following configuration.
Dual AMD Athlon MP 2600+ (2.00GHz)
3.0GB ECC DDR 266MHz
100Mbps NIC onboard
PCI eSATA card for backup HDDs
40GB ATA133 C:
500GB ATA133 D:
Server 2003 Standard, x86, all updates
The external HDD is a 500GB SATA drive labeled "Backup" and it gets mounted as "B:". This is where Toucan backs up data to. Sometimes it backs up perfectly all week, sometimes it crashes every night and I am left with .tmp files. The server is a domain controller, hosts a few shares, hosts one printer for all users, and acts as a DHCP and DNS server. Nothing special. It does host Endpoint Protection Manager as well, and as such has IIS installed, but it hosts no sites.
Oh and one final note. The scheduled task to run Toucan runs it as the domain administrator so the process has full access to everything on the system.
Well the last time Toucan ran through to completion was the third of April. The funny thing however, is that it runs fine on all of our other servers. I have reformatted, reinstalled, and retweaked this system and even the event logs don't log errors and warnings. The only error that ever gets logged is when Toucan crashes. It runs as admin and I even wrote a short VBScript that has all other apps on the server close prior to it running, and no go. My last attempt is to tell it not to backup "System Volume Information" and "Recycler". If that doesn't fix it I either need a solution or I may have to look at another backup program, which I don't want to do because I like Toucan. FBackup is also free and has more support for features of XP and beyond, such as shadow copies, but it is limited in comparison of backup/sync features. If anybody can think of anything that might cause Toucan to crash, please tell me! I would like to point out that Toucan only seems to get as far as making that "Includes.txt" file. It also creates a "Basefile.7z.tmp" file in the correct backup location, but obviously it is no good.
there have been a vast number of changes for the Toucan 3.0 release could you try the pre-release availiable here. Hopefully because there is more error checking we should get a better idea of what is going on! I am also compiling an extra-debug version of that for you right now that might help too, I will add a link to this post in the next hour
EDIT: Uploaded now as toucan-debug.zip here. You'll need to extract it over an existing copy of the 3.0 Pre-Release into the App/toucan folder. Hopefully it will give us some more feedback on this and sorry for being so slow on this.
I just grabbed both the pre-release and the extra debug you built. I'll run the extra debug build for now and pray it gives us some insight into the problem. If I didn't work so dang much I'd fire up Visual Studio 2005 and help (I own my own software company aside from working here) but I work LONG hours normally and I generally don't have the mental capacity during the week.
Anyway, I'll install the debug build in a few minutes. Do I need to remove the other version completely first, or will it use the existing jobs and rules?
use existing jobs and rules just fine, scripts on the other hand will need to be rewritten.
Alright I just renamed my 2.x install folder and installed clean, created the jobs (I like GZip support, being a Linux geek and all) and rules from scratch. There is a "scripts" folder in "Data", but it is empty.
Also, if I replace "App\Toucan\Toucan.exe" with the debug version you gave me, it will not run at all, telling me that the configuration is incorrect. Currently I have it using the pre-release version, but we won't know if it works until tomorrow since it starts backing up at 7:00 PM EDT and runs through the night. It has until 7:00 AM when another task reboots the server. I have had to add the reboot due to a bunch of "7za.exe" processes being left in memory from the 2.x version of Toucan after it completed, the few times it did complete.
I will say that I'm planning on staying with Toucan even if it doesn't work for the time being just because I am able to get help and work with the developers like this. Most commercial apps and even other free ones will always blame your system(s) and leave it at that.
you use the extra-debug version with the pre-release stuff? Otherwise this seems to be another slightly worrying thing that works for me and not you!
The debug issue is that it's looking for a bunch of Visual Studio libraries not found on the server since it is a server. A live, production server hosting our DHCP, a caching DNS server, AD, and more. Event log info follows:
Dependent Assembly Microsoft.VC90.DebugCRT could not be found and Last Error was The referenced assembly is not installed on your system.
Resolve Partial Assembly failed for Microsoft.VC90.DebugCRT. Reference error message: The referenced assembly is not installed on your system.
Generate Activation Context failed for C:\Program Files\Toucan\App\toucan\Toucan.exe. Reference error message: The referenced assembly is not installed on your system.
This happened a dozen times, once for each time I tried running the debug build.
I have uploaded another set of files, after a bit of work with Dependency Walker and a clean copy of XP (which is as close to 2003 as I have right now) I think this bundle should work, just drop it into the same place as before
Alright, apparently version 3 doesn't run jobs with "toucan.exe jobname". How do I run a job I created in the GUI from the command-line so that Task Manager can run it? I'll grab those files this afternoon. I do have a clean Server 2003 Standard machine at the house (two, actually) that I can test on for you, if you want. Get to know me a tad more and I may give you VPN/Remote Desktop. I'm cautious though, because the box acts as my home networking center, connecting three separate networks and hosting my domain!
I forgot that, you can use
for now, I still need to get that tidied up for the final release!
As for Server operating systems I just checked out what I can get from the MSDN Academic Alliance and when I get back to uni next week if this is still not solved I will grab a copy of Server 2003 Standard and put it in a virtual machine
Debug now says it can't find a specified program.
C:\Program Files\Toucan\App\Toucan>toucan --script="backup([[Backup-Drive-D]])"
The system cannot execute the specified program.
The regular version 3 works fine however and will start backing up. I have that version in place for the backup tonight. Also, how is it you can get a copy of Server 2K3? I can assure you it doesn't come cheap!
Odd problem. The program apparently started, but never ran or crashed. It created a 22,256k "Includes.txt" file, and that was it. This is with the normal 3.0 you linked, since the other one wouldn't run. I got no crash report upon login, and I don't see any warnings or errors in my event logs. It's as if it started, created the file list, and chose to terminate. I'll try running the task manually now and check it in a few hours.
Alright Toucan 3 (not the debug version since that won't run at all) doesn't seem to work. I started the backup job manually this morning and just now checked it, five hours later. It created a new 22,256k includes file, and is sitting in my process list using 316k of RAM and 0% CPU. No 7za.exe processes are listed. I believe that it created the list as it should have, but then died instead of start the zipping process. Output from the terminal follows.
Toucan 3.0 Pre-Release 1 09:26:22
Operating System: Windows Server 2003 (build 3790, Service Pack 2)
Creating file list, this may take some time.
I am going to download server 2003 in the morning and try and hunt this down I can get it either form Dreamspark, or from MSDN courtesy of my ACM subscription..
the plot thickens! I installer 2003 and it worked, all of it, without fail. Could you tell me what roles you have set up? Thanks
This machine runs a DHCP server, DNS server, AD (domain), IIS (needed for Endpoint Protection Manager, we don't host sites on the box), print server (2 shared printers), and file server (various shared folders that get mapped at login based on your group memberships). Nothing special. This is the only server on our entire network, so no worries about issues from another controller.
Alright, I found a bug while creating a test job to test Toucan3 on a small backup job (backup just the admin account in Docs&Set). Under "C:\Documents and Settings" I see two folders called "Administrator". This is incorrect. One is "Administrator" which is the local, disabled account and one is "Administrator.ServerName", which is the admin account for the domain. For some reason, Toucan3 cannot see anything after the period (or the period itself) in folder names.
Using the GUI Toucan successfully backed up the 587MB domain admin directory. I am running the backup job now as a task in the scheduler. We'll see if it works as well.
Doesn't work as a task. Also, doesn't work if I issue the command from a command-prompt or the "Run..." dialog. Toucan creates the file list, but it NEVER calls 7za.exe! That's the problem. It must be something with not using the GUI. The command for the test job is listed below.
"C:\Program Files\Toucan\Toucan.exe" --script="backup([[Test Job]])"
Mind you this is what you gave me to pass so it would run the backup job in Toucan3. Did I possibly get it wrong?
It is definitely using a command-line to start Toucan that is the problem. Even if I rename the job or create another job with the name "Test" (spaces don't seem to matter) it will sit and create the list of files, then hang and never spawn a 7za.exe process.
is so strange. So it works in the GUI but not the command line, I have added an easier command line options called --job="testjobname" in the next pre-release, I'll try and get something uploaded in the next day or so, I'll also check into the working directory as it sounds like that could be what is causing the issue.
I also thought of that and edited the path to include "C:\Program Files\Toucan\App\Toucan" and it still didn't spawn a 7za.exe process. Not sure if it's a path/work directory issue now. I am thinking that there may be some piece of code in there somewhere that fails to start the process when run from the command-line.
Alright I started the GUI yesterday, selected my job, and at 5:30 I clicked "Run". I then disconnected my remote desktop session (left everything running) and came back this morning. I just now logged in and Toucan is still sitting there, no 7za processes, and no backup file. Upon closing Toucan and checking the data directory, no "Includes.txt" file either. It's as if it just sat there all night pretending to build the file list.
think I will add some more debug statements to this so we can see what it is doing, I'll try and put up a release tomorrow to have a go with.
Found another bug in the pre-release! When I started Toucan this afternoon in preparation for a manual backup, I selected my backup job and expanded the D: drive, which is what I backup here. Upon expanding it, I had two copies of the directory-tree! One under the other, identical to each other. I then dropped-down my rules box and reselected the only rule set that I have, which was already selected, and the duplicate tree went away. Odd, and possibly a reason as to why it isn't working.
ok, I'll see if I can reproduce this. I have uploaded another version with more debugging statements in it as we can't get the true debug version to work, I warn you output will be a bit heavy though.
I just plopped the 4.6MB version (I think I grabbed the right one) into my toucan/app/toucan directory and ran "toucan.exe --job="test"" and sure enough it started and counted the four files to compress, but it never spawned a 7za.exe process. Output copied right from the command-prompt:
Toucan 3.0 Pre-Release 1 14:23:07
Operating System: Windows Server 2003 (build 3790, Service Pack 2)
Creating file list, this may take some time.
Setting working directory C:\
Then it stayed there until I killed it using control-c after several minutes of no 7za.exe process. Note the working directory of C:\ even though I was in "C:\Program Files\Toucan"...
Found another bug. I created another test job and added one of the two admin accounts to the backup, but realized that I had added the domain admin instead of the local one. I selected the admin directory on the right pane and clicked the minus button and made it disappear, but after saving and re-selecting the job, it was back. I could not delete it. This may be because Toucan sees "Administrator" instead of "Administrator.Domain".
* In "Documents and Settings" domain names are not shown after account names, separated by the period
* Working directory is somehow defaulting to C:\
* 7za.exe never starts, probably due to the working directory
* Cannot delete a domain account directory from the backup pane due to not seeing the domain name or something
* Selecting an existing job after Toucan starts results in showing the directories and such to be backed up twice
setting of C:\ as the working directory is right if the full path to those files is C:\Inetpub\AdminScripts\adsutil.vbs etc, that is the way 7-Zip works.
Thanks for the list, I'll try and work through it and then we can try again
Thanks as always for sticking with this.
So why isn't 7za.exe spawning then, if the working path is correct? It runs fine from the GUI. In fact I did a fresh differential Monday, and last night I started the same job again and it correctly created a 51MB differential. It works properly from the GUI, but hanging around until the last minute and starting it is a pain. The new "--job" parameter does work as far as creating the file list and all though. It just won't spawn the 7za.exe process to compress everything.
think the latest build has finally fixed this, fingers crossed.
Great! Just post a link once you have it up and I'll let you know if it solves my dilemma!
I wasn't very clear, the latest build on http://drop.io/toucantest should do it
I ran the normal backup manually from a command-prompt using "toucan --job="Backup-Drive-D"" and it created a 22MB text file (includes), spawned 7za, and is now eating away at my second CPU, but no 7z.tmp file yet. I assume 7za is figuring out which files have changed to backup only those. Tonight will be the real test though, when I turn on the task and let it run automatically.
After a few minutes it created a 7z file, added the changed files, and terminated without crashing. Seems to work wonderfully now. Again, tonight will be the REAL test...
That did it, the jobs now run on a schedule once again. Oh and unlike with Toucan2, this one doesn't seem to crash for no reason! I'll go through and get screenshots of the few bugs I have found now, if you want, and email them to you with a detailed description of how to reproduce each.
would be great, thanks slamerton (at) acm (dot) org is the best address.