Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
stodorovski
Participant

Free space for upgrade to R81

We are planning upgrade our devices (5600) from R80.20 to R81

Based on documentation for upgrade process we'll need at least 20G free space in root and 10G free space in /var/log.

The point is that we don't have it and we'll have to delete some files.

Our current situation (df -k):

 root available/var/log available
cpgw12062534440789092
   
cpgw21877485652872796
   
cpmgmt110602686061220

 

And with LVM Manager Storage overview in attachment.

Until now I didn't have issues with free space during upgrades but here they comes and I don't want to end up with deleting something important. It's production HA ClusterXL and I'm not expecting some issues during upgrade process (one by one with CPUSE) but need to make sure that the process will start at first place.

 In attachment I've extract all files in / with size of  +10000 using following command:

find / -type f -size +10000 -exec ls -lh {} \; 2> /dev/null | awk '{ print $NF ": " $5 }' | sort -nk 2,2

Can I get advice which files will be save to delete in order to free up some space?

I will really appreciate it.

Thanks in advanced,

0 Kudos
9 Replies
PhoneBoy
Admin
Admin

The access logs are the larger bit of this (in $FWDIR/log).
Interesting that one of your gateways has some as they should be on the management.
You can remove these files (and associated .logptr files) if you don't want/need them, otherwise you might want to archive them on a separate system.

You should also go into CPUSE and remove the downloads for the various packages you've installed

stodorovski
Participant

Thanks for fast answer. I'm quite new in CP world so I might ask stupid questions. For logs you are talking about those I suppose:

/var/log/opt/CPsuite-R80.20/fw1/log/2021-11-03_180256_1.log: 2.0G
/var/log/opt/CPsuite-R80.20/fw1/log/2021-11-03_182829_2.log: 2.0G
/var/log/opt/CPsuite-R80.20/fw1/log/2021-11-03_184745_3.log: 2.0G
/var/log/opt/CPsuite-R80.20/fw1/log/2021-11-03_191308_4.log: 2.0G
/var/log/opt/CPsuite-R80.20/fw1/log/2021-11-03_201226_5.log: 2.0G

It is strange but they seems to be old and I don't know the history. I will delete them for sure but it will free space from /var/log and for fw1 I need to free some space from root. Or maybe I'm wrong?

On fw2 there are some other files that I think it's safe to be deleted but they are also in /vat/log except maybe  newkerneldebug.txt

/var/log/CPView_history/CPViewDB_1563451952.dat: 1.1G
/var/log/CPView_history/CPViewDB_1579032199.dat: 1.1G
/var/log/CPView_history/CPViewDB.dat: 1.2G
/home/admin/newkerneldebug.txt: 1.7G

 For management srv if I delete following maybe I'll delete my recent logs but it might not be a problem.

/var/log/opt/CPsuite-R80.20/fw1/log/2022-01-03_000000.log: 1.1G
/var/log/opt/CPsuite-R80.20/fw1/log/2022-01-04_000000.log: 1.1G
/var/log/opt/CPsuite-R80.20/fw1/log/2022-01-09_000000.log: 1.1G

....

That will solve my issue but only for /var/logs again.

Except some snapshots if there are any, what else can I delete to free space for root?

Or maybe to expand lv_current and lv_log as from vlm_manager I can see that there is some free space on both units and manager or it's not good idea?

 

0 Kudos
the_rock
Legend
Legend

Just be cautious here not to delete any database files. If its .log or cpview related, should be fine to remove them. You certainly dont need the debug txt file, appears that may had been generated for TAC case perhaps?

Andy

0 Kudos
the_rock
Legend
Legend

Those space requirements, in my personal opinion, can be debated. I will tell you though, from my personal experience, its definitely important to have at least 10-15 GB free in root dir and as far as /var/log, from what I observed during many upgrades, I would say 7 GB free is minimum you should have. Below is command I always give to people. Say you wish to search for files bigger than 200 MB in /var/log dir, just use:

find /var/log -size +200000000c (same method is applied for different dir or file size).

As @PhoneBoy , it would be good idea to go to CPUSE and remove what you installed before.

0 Kudos
stodorovski
Participant

Suppose if "verify update" process pass, there should be no problem or that process is not checking for free space?

By the book, recommended method for gateways upgrade is via SmartConsole (Central Deployment available in SmartConsole). I've done few upgrades in my lab but via CPUSE one by one. In that case I feels like I have more control over the process. Do you have some experience with central deployment upgrade that I should be worried about or you advice me to go with CPUSE?

And one more question about snapshots. Do I need them before upgrade to major version or only backup is fine?

0 Kudos
Boaz_Orshav
Employee
Employee

Hi

  1. Verify indeed checks also for disk space so it should block your upgrade if the machine does not has sufficient free disk space.

  2. Central Deployment is using CPUSE to perform the actual upgrade. It simplify the process since you can upload the file only to the management (one time), then on one operation it will install the standby member, perform failover and install the other member (and will also take care of things like changing the management cluster version). Same CPUSE just making the process simple and easy to use

  3. CPUSE shall create a snapshot during the upgrade process. You can check in your lab at the snapshot manager and you will see a snapshot with a name like "Autosnap....." and a description that this was created during the upgrade

Please let me know if tehre are more questions and would be glad to get feedback regarding the Smart Console usage for upgrades (boazo@checkpoint.com)

 

stodorovski
Participant

Hi,

Few more questions regarding CD upgrade via SmartConsole:

1. In case upgrade verification passed and even that something goes wrong, as CD via SmartConsole upgrade starts from backup one, does it mean that it will stop there and will revert automatically or it will continue?

2. As CD is upgrading one by one, does the process in background performs some checks for HA status and on first place switch the roles smoothly OR it continue and the roles actually are switched at the time when comes the moment to stop services and restart the active one (rude way)?

3. And based on your experience what are the odds something to went wrong when we have successful verification upgrade check?

Thanks in advanced, I really appreciate. I'm quite new to CP world 🙂

0 Kudos
the_rock
Legend
Legend

@Boaz_Orshav is right...verification process via CPUSE would verify the space 100%. I personally never used CDT for upgrades, I prefer CPUSE, as I never had any issues with it. And yes, it takes automatic snapshots, so in case anything was to happen, it would revert to original version. 

stodorovski
Participant

Hi,

When we are doing CPUSE upgrade one by one, we start with backup one. When it's ready and we want to switch the active role to upgraded GW, is it enough to go with "clusterXL_admin down" before upgrade start, or there is some other way to switch active role to upgraded node?

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events