If you have a relevant backup plan running your log file will not grow indefinitely. You will probably find that the space within it is mainly unallocated - as blocks of pages in the log get backed up (depending on your backup/recovery model of course, read up on those options if you are unfamiliar with them) they are marked as free to be used again later but are not released to the OS. Next time your big process runs, causes many inserts/updates and so needs a few Gb of log space MSSQL won't need to ask for more space from the OS as it can just use the blocks that are already allocated to the log file but not currently holding anything that can't be written over.
If you are seeing GBytes of extra growth in your log files every time that weekly process is run then you need to check your backup plan as that means SQLServer is not seeing the log pages as reusable either because your backup regime is not correct for the data and activity (or it could be as simple as you are not taking backups up often enough at all).
Growth in the data files is similar: if there is a large chunk of free space in the files then that will get used next time some extra space is needed instead of asking the OS for more to be allocated. One thing to look out for if your data is unexpectedly large is over-indexing - you might find large tables have indexes that are never really used (either they are not needed at all or don't offer much benefit over another index that is also present). Classic examples of this is finding every column in a wide table has its own index (which is usually, though not always, a sign of bad table/index design), or finding an index for "column1 and column2" and one for column1 on its own: the query planner and runner will be able to use the compound index just as well as the simple one for queries based on column1, so there is no need to use space with the extra index. Maintaining indexes that are not useful also has an impact on write performance. This book has a couple of sections covering common index problems if you want to look at the issue more, and is worth a read for all developers and DBAs anyway IMO.
Shrinking files unnecessarily can lead to excess fragmentation within the files, which can harm performance, so take care if you go that route.
Regarding the switch from RAID1 to RAID5: I would not recommend that. RAID5 often has performance problems with write-heavy database work (it is likely to significantly slow down that huge processes that generates GBytes worth of data and transaction log entries) because of the extra-reads-before-any-write-to-update-checksums issue. Rather than adding one drive to go from R1 to R5 I'd go for two extra drives and use R10 - still double the space but without the write performance issue (that is assuming there is room in the server for two extra drives, of course!). What-ever you do in that area, converting from one RAID arrangement to another is likely to involve a large down-time as you backup the data, rebuild the array, and copy the data back on (unless you buy a whole new set of drives and can have both new and old arrays running at the same time, which will reduce the downtime quite a bit). Another option would be to add two drives as a new RAID1 array and then use Windows' dynamic volumes to span over these two arrays (giving you the size of RAID10, but without some of the performance gain that can be gleaned from striping). OR you could keep the two arrays separate, and keep the data files on one and the transaction logs on the other - keeping the data and logs on separate spindles this way can significantly improve the performance of write operations by reducing the head movements required to update both the log and the data file. This last option also has minimal down-time as once the drive are in the rest can be done "live": create new log files on the new volume and tell SQL Server to migrate all active pages to there from the existing files then drop the old files (there will be performance degradation during this operation, but not down-time).