# Latest

New documentation (HTML and PDF) by Stefan Huebner. Nice job!

- Hugo, 08/26/2002

New snapshot, hacked by a user. Looks good.

- Hugo, 08/01/2002

To report a bug, please go to the Bugzilla page. (Nice work, KP!)

- Hugo, 06/21/2002

Latest Monitas tarball is available here. Use it in conjunction with the latest daily snapshot. It lets you backup, compare and restore archives over a network.

- Hugo, 06/19/2002

Latest Monitas tarball is available here. It is alpha-quality code but it works. I can backup, compare and restore over a network. It doesn't nuke yet but it works fine on a live filesystem. (It restores to /mnt/TESTING as a precaution.)

Monitas-server (daemon) is 25% complete.

Monitas-client (daemon) is 40% complete.

The CLI's, the GUI's and the start/stop wrappers are still in my head. :)

- Hugo, 06/14/2002

<enderAWAY> hugo: so, I made a new list for monitas.
<enderAWAY> monitas-list@j2solutions.net
<enderAWAY> send an email to monitas-list-subscribe@j2solutions.net to subscribe.

Folks, you heard it here first... ;-)

-Hugo, 05/07/2002

## FAQ

Q: What is Monitas?

A: It isn't ready for public consumption yet but it will be by 02/Q4. It will backup and restore over a network. It will let the sysadm backup, restore, wipe, and even prep from bare metal the PCs residing on the network, all from the comfort of the sysadm's console. Data backup/restoration may be requested by the client application. Data may be restored without the client having to lift a finger. The sysadm can run the show from the server.

I'm going to use this web page as a place where the plan can crystallize. Over time, this page will grow into a logical explanation of the inner workings of Monitas. This will make it easier for others to contribute. It will also help me: I can't write half of what Monitas requires :) but I am a quick study and I prefer to study in small chunks.

Q: Will Monitas be Open Source?

A: Yes. The server and client are made available under the GNU Public License.

Q: Are you crazy? How can you write good software and give it away?

A: Well, I hope someone will see Monitas (and Mondo and Mindi) and hire me. I am a UK citizen (technically, a 'subject' because we have a monarchy but no-one pays much attention to them nowadays) dating a Texan. It is very hard to find a job if you do not have a Green Card. It would be immoral to ask Michelle to marry me for any reason other than love. Therefore, I am looking high and low for any means to support myself while I date her. We shall eventually marry and remain in the States but in the meantime, I am having to watch my expenditure carefully.

Why does this affect you? Well, if you use my software regularly but don't pay for it, then eventually I'll have to stop developing it. Of course, you'll probably find another $0 program to replace mine, so you won't care, but I would rather keep Mondo going for you and the tens of thousands of users like you, who rely on Mondo.

Monitas will be better than Mondo. Monitas will use Mondo but for client/server network backup and maintenance. If you work for a company which uses my software on a regular basis, please consider contributing to the project financially or with source patches. How else can the project keep going?

So, yes, I'm crazy. :-) I actually believe people are willing to support projects like this one, especially if they are using it daily anyway.

Q: Why should commercial users pay for Monitas?

A: If you don't support the project, you can't expect me to offer you 1-to-1 technical support.

## Progress

The client is coming along nicely. So is the server. It'll be September before beta-testing commences but the alpha code is already available.

### Server

The server will come in three parts - the daemon, the CLI (command-line interface), and the GUI. The server will keep an SQL database of backup information, so that the sysadm can orchestrate the smooth backup/restore of data over the network.

The daemon will check its schedule once a minute. (The schedule will be a simple text file, to avoid the need to interrogate the SQL database 60 times an hour.) If a backup is due to commence now, the daemon sends a signal to the client, asking it to begin archiving and submitting data for storage. The daemon then receives the data, stores it, labels it and indexes it in the SQL database.

If a restore event is requested by the sysadm (or if it is scheduled), the daemon tells the client to prepare to receive data. The daemon then sends the data and tells the client to reboot if necessary (before or after is determined by the nature of the scheduled/requested event).

The CLI allows the sysadm to schedule and request events. It will be a no-frills interface to the SQL database (and the text file containing the backup schedule). Because the daemon is controlled by one text file and an SQL database, it is easy to write a client for it. So, a GUI should be no problem. I could even write an interface in PHP... :^)

The CLI and GUI are really not that hard. The daemon is the hard part. In theory, I could Open the CLI and GUI, just for the heck of it. The daemon, no way.

### Client

The client will respond to triggers sent by the server. It will backup and restore noninteractively over the network. Like the server, the client will come in three parts - the daemon, the CLI, and the GUI.

The daemon will wait until it is asked to backup/restore. Then, it backs up / restores. Simple.

The CLI will interrogate the daemon. It will permit the client's user to place a request with the syadm for a backup/restore operation. If/when the sysadm okays it then the backup/restore will proceed.

The GUI will do a prettier job than the CLI. That's about it. The client is pretty much a self-cleaning oven.

## How it started

Here is the original e-mail, sent to the Mondo mailing list on April 26th, 2002:-

We've been kicking some ideas around in #mondo (irc.openprojects.net). Here is what we have come up with.

Think, "Client/server backup with an attitude". This will be Linux-only for now but we could port to Windows in future, in theory.

Mondo Server (hereafter, "MS") will:-

- accept requests to backup Mondo Clients (hereafter, "MCs")

- accept requests to restore live to MCs
- send Reboot&Restore trigger to MCs
- send "backup to me" triggers to MCs
- send "restore live from me" triggers to MCs
- keep a database of ISOs and their info, in a format which makes it easy for the sysadm to figure out:-
  - when was _this_ MC last backed up?
  - how old is our most recent backup of /home/hugo/personal/letter-to-girlfriend.doc (or whatever)?
  - when is _this_ MC next due to be backed up?
  - ...etc.
- store MCs' backups on device (tape, CD, hard disks, etc.) controlled by MS, not the MCs

Mondo Client (daemon running on the 'client', a workstation PC) will:-

- receive triggers from MS

- backup PC in response to MS's trigger
- send ISO's to MS
- restore live data streamed from MS to local PC, in response to trigger from MS
- reboot&restore from bare metal noninteractively in response to request from MS; restore data from MS to MC
- send request to MS, asking for a particular directory to be restored to MC (or for a bare-metal restore, if desired)

If you invoke mondoserver (the server program) with -d then it will run in daemon mode. It will trigger backups in accordance with its configuration. I expect that the MS will be configured to start mondoserver at boot-time and to shut it down on reboot/shutdown.

If you invoke mondoclient (the client program) with -d then it will run in daemon mode. It will respond to triggers received from the MS. I expect that the MCs will be configured to start mondoclient at boot-time, etc.

If you run mondoserver without parameters then it will give you a warm, friendly interface with which to configure your MS.

If you run mondoclient without parameters then it will give you a warm, friendly interface to let you watch what mondoclient (the daemon) is doing to your MC. You may push a button to request that your MC be backed up. The MS will decide whether to give you what you want. (The request will probably sit in a special "The user asked for this" queue, where the sysadm can see how often you've requested it, whether you should have it, etc.)

Here are the bits I know how to do:-

- [MS] store MCs' backups on device (tape, CD, hard disks, etc.) controlled by MS, not the MCs

- [MC] backup the local PC in response to MS's trigger
- [MC] reboot&restore from bare metal (without a floppy or a CD) over a network

I haven't figured out these bits yet:-

- [MS] send triggers to MCs

- [MC] receive triggers from MS
- [MS] keep a database of ISOs and their info, in a format which makes it easy for the sysadm to track backups
- [MC/MS] send data back & forth (the backups themselves, I mean) <--- netcat?

Basically, I know very little about networking but I can learn. I also don't own any networked PC's (well, I do but they're 3000 miles away). So, I have to do some serious thinking. I can buy some cheap, used PC's and network them; use them as testbeds/clients; buy a slightly more expensive PC as a server; then I can go from there. I expect to do it for <$1500. My apartment hasn't sold yet, so I can't start the heavy coding until then. I expect to start within a month, though.

I _think_ I can do this by the end of the year. If I'm lucky, I can have most of this running reliably by August/September.

I know there are some fairly big companies which use Mondo. I know some of their employees are on this list. If you think you know someone who would be interested in sponsoring the client/server phase of Mondo, please let me know.

There are 3 or 4 hardcore developers waiting to get this done. >:-D

-Hugo, 04/26/2002