THE GIT REPO FOR THIS PORTFOLIO IS: [https://gitlab.stud.idi.ntnu.no/freand/powershell-backup-script](https://gitlab.stud.idi.ntnu.no/freand/powershell-backup-script)
## Project background
Ransomware attacks have become one of the primary threats of a system today. Attacks are becoming increasingly frequent, as The European Union Agency For Cybersecurity notes in their 2020 Ransomware report: "*With the number of incidents growing, it is evident that becoming a victim is not an ‘if’ but rather a ‘when’ hypothesis.*"(Douligeris, Raghimi, Lourenço and Marinos, 2021). Ransomware attacks function by encrypting entire file systems and demanding a ransom in order to decrypt them back. The aftermath of these attacks can be devastating, with large organizations being forced to pay millions of dollars or losing system critical files. The only effective defense against this kind of attack is to make frequent backups of system files.
The goal of this project is to make a script capable of backing up and restoring system files. The script will act as a tool to help with protecting a system, should it be exposed to a ransomware attack.The nature of this task means that the script will be run often and many different backups will be made. For this to be possible, the script will need to fulfill a few criteria:
It needs to be lightweight and efficient, in order to be able to complete backups quickly, without putting to much strain on the system.
It will need to store the completed backups efficiently, taking up as little storage space as possible.
And finally, the restoration process has to be quick, in order to get the affected system back online as quick as possible, should the threat externalize.
## Solution
To fulfill my desired criteria, I decided to use **reverse incremental backup**. A reverse incremental backup works by first backing up the entire system and afterwards only backing up the differences between the system and the last backup. These differences are all applied to the full backup, meaning it's always up to date. Meanwhile, the differences are also saved to smaller incremental backups, should you want to restore to an older backup. Keeping the full backup up to date makes for quick restoration of the most recent backup, compared to a regular incremental backup, where all the changes have to be applied before the backup is ready. By only saving the changes since last backup, the reverse incremental backup uses less storage space than for example a differential backup, avoiding duplication of the same data.
The actual script works by working with three folders: The system folder, the primary backup folder and a "incremental" backup folder. The incremental backup folder is created every time the script runs and is keeps track of the differences between the system and primary backup. First, the full backup is unzipped and its contents compared with the system folder. The script looks at filenames and the files "lastWriteTime" in order to distinguish them. Files only found in the system is copied over to backup, as well as a special folder in the incremental backup. This folder tells the script which files to delete from the full backup when restoring an earlier backup. Files found in the backup folder, but not in the system, are copied to a second special folder in the incremental backup before they are deleted from the full backup. This tells the script which files to restore when restoring to a point before this backup. The full backup folder should now be an identical copy of the system folder. The backup folder is zipped and the backup is complete.
The restore process works by again comparing the difference between the system folder and the backup folder. Only this time, the files found only in backup are copied to the system, while the files found only in the system are deleted. If an earlier backup is desired, then the incremental backups are applied to the full backup by looking through the two special folders and identifying which files to copy over and which to delete.
## Discussion
My primary inspiration for this script was a python program called "rdiff-backup", a reverse incremental backup tool. It works similarly to my script, creating a mirror of the system folder at the backup location as well as storing the differences between backups in incremental backup folders. The program is more feature-rich than my script, for example being able to backup over ssh. One difference between my script and rdiff-backup is that rdiff-backup actually compares the data of the files to back up, only copying the new data instead of the entire file. This makes rdiff-backup superior to my script, being able to backup and restore files more efficiently through less duplicated data.
If I where to make another iteration of this script, I would probably rewrite it from scratch. While I'm happy with what the current script is capable of, it's still fairly lacking in functionality. Currently, the user has to setup a task scheduler of their own in order to have the script create backups regularly. Ideally, the script would also create logfiles, to make it easier to verify backups and see past actions. It also lacks backup management, like deleting old incremental backups or only keeping a certain amount.
I learned a lot of powershell while writing the script, so there is quite a bit of code in the script I now would have written differently. Quite a bit of it could probably be reused with functions, reducing the size of the script.
The current version of the script backs up and restores files indiscriminately, without checking what the result will be. It wont warn the user if the restore will result lots of files getting deleted and requires a little bit of fiddling with parameters to run correctly. As a result, the largest security concern connected to the script is loss of data through user accidents. By restoring to the wrong folder, important data could be deleted or overwritten. As human error is a very common cause of data loss and security breaches, this is a major concern. The script could also end up copying malware files to the backup location if the system already is infected.
## Conclusion
My original plan for the backup script was to simply copy files found in the system which had been edited since the last backup. This was a simple and efficient operation, only needing to look through the system files folder. This worked fine for new files and edited files, however I reached a roadblock once I considered deleted files. How was I to detect files that had been deleted from the system since last backup? The nature of reverse incremental backup meant that these files would never disappear from the full backup folder unless they were deleted. I thus realized I would have to compare the system files with the files that where already backed up.
Overall, I'm happy with script I ended up with. Writing the script went fine, but I vastly underestimated the time it would take to make it work properly. I probably took me three times as long to troubleshoot and fix bugs, than it took to write it originally. My work process consisted of making a quick sketch on paper and then writing the code for it. I originally had ambitions of creating a graphical user interface for the script, in order to simplify setup. However, I realized there would be little use for this for a tool meant to be automated and decided against it. In afterthought, a GUI would probably reduce the risk of accidents through user mistakes, however this would be a band-aid solution to the scripts underlying lack of user feedback.
#### Sources
Douligeris, C.D. (2020) _From January 2019 to April 2020, Ransomware ENISA Threat Landscape_. (978\-92\-9204\-354\-4)_._ Sted: ENISA. Tilgjengelig fra: https://www.enisa.europa.eu/publications/ransomware/ (Hentet: 14.02.2021).
