Help with maintenance strategy I have a rather atypical database situation, so am finding researching it a bit difficult.

The question first: what kind of maintenance strategy do I need to put in place?

The setup:


The whole system is mounted on a vehicle, so at the end of the shift, everything gets turned off (so no scheduling jobs 'during the night').
However, we can ask the user to regularly click on a button somewhere to invoke a maintenance 'job' if necessary.
It is used for recording data (lots of) while the vehicle is moving (currently pumping IObservable data through a queued implementation of IDataReader into an SqlBulkCopy - one set for each table).
Having thought about this quite a lot, I think that we don't need Full Recovery: if anything goes pear-shaped, it's going to take more time to restore a backup than it would to just go and record again.
It is installed on the other side of the world, in a different time zone, and the users aren't DBAs.


My main concern is the log file: will it grow uncontrollably, or become 'fragmented' (or whatever the right term is).
What kind of maintenance strategy do I need to put in place?


Frankly this is something I have not worked on but if I were in your place I would take some time before closing the system and devote that time to maintenance activity. Depending on fragmentation suppose you plan is to perform the maintenance task weekly. So on Friday or weekends(as you like it) before closing the system why not give couple of hour  to the SQL Server and within that hour perform maintenance task. 


  My main concern is the log file: will it grow uncontrollably, or become 'fragmented' (or whatever the right term is).


Yes if database is in full recovery mode and NO proper transaction log backup is in place or no transaction log backup is taken at all the log file can grow huge and can grow greater than data file. In full recovery mode ONLY transaction log backup can truncate the logs and make them reusable. This is how circular nature of transaction Log works. The working of transaction log is quite nicely explained in Logging And Recovery In SQL Server.

Full recovery model is ONLY suggested when point in time recovery is required. If you don't need point in time recovery and you are OK with some data loss change the recovery model to simple. In simple recovery model log truncation happen automatically after checkpoint hapens or when log file grows 70% of its size, only exception is if long running transaction requires a portion of log file then it wont be truncated. So you can see in simple recovery log truncation is managed by database engine. You cannot take transaction log backup in simple recovery mode.