Delete files older than 60 days script check

[thomas.duane]

Hi folks, I'm wondering if I could get someone to give this script a sanity check for any syntax errors.

Code: Select all

<#
                .NOTES
                ===========================================================================
     SYNOPSIS  : Unstructured Data Automation
     Created with:                    Powershell ISE
                Created on:           08-Dec-2024
     Adjusted on :       09/Dec/2024
                Created by:            Name
                Organization:      Company
                Filename:           ClearFiles.ps1                ( Use Ps File Name here )
     Application Name:   Unstructured Data Automation
     Additions:         
============================================================================================
                .DESCRIPTION
                                A description of the file.
#>
 
 
#==========================================================================================
$col = @()
$Comp = Get-Content env:computername
$Date = (Get-Date -format "MM-dd-yyyy")
$datetoday = (get-date)
 
#[Date]$Time = Get-Date -format hh:mm:ss 
$CurrUser = GC env:UserName
 
$AppName = "Unstructured Data Automation"
 
$Logname1 = "UnstructuredDataLog_"+$Date
$logFilePath = "C:\West\log\$Logname1.log"
 
#Add-Content $logfile $Comp  $Date > $appname - is now created -PassThru
 
 
function Write-ToLog {
    param (
        [string]$message
    )
   
    # Step 3: Prepare the log entry with timestamp
    $timestamp = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss")
    $logEntry = "$timestamp - $message"
   
    # Step 4: Check if the log file exists
    if (Test-Path -Path $logFilePath) {
        # If the file exists, append to it
        $logEntry | Add-Content -Path $logFilePath
    }
    else {
        # If the file does not exist, create it and write the entry
        $logEntry | Set-Content -Path $logFilePath
    }
}
 
 
Write-ToLog -message "////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////"
Write-ToLog -message "///////////////////-------------------------$AppName - PS Script has started----------------------------------////////////////////////"
Write-ToLog -message "///////////////// --------------------------The current user is ----- $currUser -----------------------------------/////////////////"
 
$col = @()
$jobstatus = (Get-VBRjob -Name  FileShare3_UDataTest).GetLastResult()
if ($jobstatus -Like "Success") {
 
    Write-ToLog -message "Last Backup job is Successful.. ";
   
    Write-ToLog -message "Proceeding with the old files deletion based on the age criteria provided"
                ## List and capture file information in the share
    $files = Get-ChildItem "\\lnvmon03\ECS\Batches\2242048521" -File -Recurse
    $flcount = $files.count
    $limit = [datetime]::Now.AddDays(-15)
    foreach($file in $files) {
 
   $row= "" | Select Folder, File, LastModified
  
 
    if ($file.LastWriteTime -lt $limit) {
       
        $file
        $fldr = $file.Directory.Name
        $row.Folder = $fldr
        $row.File = $file.Name
        $row.LastModified = Get-Date $file.LastWriteTime -Format MM-dd-yyyy
        #Remove-item -Path "\\lnvmon03\ecs\Batches\"
        Write-ToLog -message "The file '$($file)' has been deleted from the folder '$($fldr)'"
        $col+=$row
    }
   
 
    
}
 
    Write-ToLog -message "There are '$($flcount)' files found in the folder '$($fldr)'"
 
   $col | Export-csv -NoTypeInformation C:\West\Log\FilesPartofDeletion.txt
 
}

[Moderator] Added code block for the script

[david.domask]

Hi Tom,

I gave a quick look at the script, and I would strongly advise AGAINST putting this into production as regrettably there are some nuances that could make this very dangerous and also just plain not work.

1. Manual deletion scripts are not really recommended ever.

This is more personal thing, but you have to be really careful about delete scripts (especially with the -Force parameter) as the script will follow the logic exactly, and sometimes the logic may result in undesirable conclusions. (Read: deleting a bunch of stuff because an edge-case met the script delete logic unintentionally) There are a lot of checks that should be done IMO before issuing a delete script, I've seen way too many cases where a script similar to this resulted in weeks long investigations regarding "where are my backup files?", there's just too much business logic that gets missed.


2. Script uses VBR cmdlets, so it must be run from VBR Server/Remote console

Main issue with this is that because you rely on the job session data, script needs to be run from either VBR server or Remote Console to use the Veeam Powershell Module -- if VBR itself doesn't have direct access to the share (requires a different gateway), script just plain won't work. Even in scenarios where it does work, Powershell + SMB is always a bit finnicky and slow, I think the script processing will take a very long time for even a relatively petite network share for a business, and the networking may be quite tricky/problematic

3. Result = Success has some caveats with Unstructured Data Backup

Depending on what the has been Configured for Step 6, a session with "Success" EResult may in fact have done nothing at all during the job run. This will lead to a false-positive in your script logic and delete files that haven't been backed up. This goes back to point 1 about being very cautious with delete scripts, as the logic can be pretty tricky

I do have more syntax and design related comments, but for me the above points would stop me from using this. The script will undoubtedly work in some scenarios, but there will be a lot of fairly common scenarios where the script will delete data that isn't meant to be deleted.

Let's discuss elsewhere (I will DM you) and let's see if there's a better way to approach this.

[thomas.duane]

That makes sense I didn't realize a success may mean a false positive in this case, but I understand what you are getting at. I'll follow up with you directly.