Randy Calvert

As long as you have a plan! Just remember... in order to restore in that case, you have to recover the external server first, then start the restore for the main site. If this is a "when seconds count" type operation, it could add a bunch of time to the restore process. If that's acceptable in terms of timing, that's perfect. 🙂

So here’s an example. Let’s say your rsync run nightly at midnight. What happens if at 11:55pm someone hacks your site and defaces everything? 5 minutes later before you had a chance to catch it, your backup rsync runs and now all of those compromised files are copied over to your backup location. Those files are now useless. If you restore, you only have those compromised files. Instead you want to be able to go back to a set of files from XX days ago.

Correct. That’s why you need something EXTRA to take that copied rsync folder and make a separate version. What OS are you running?

Just make sure you have something to version the rsyncs. If a problem occurs and you have to restore you don’t want your backup to have that problem also. Being able to go back to specific points in time can be very helpful in troubleshooting.

There is some trickery that you can do in htaccess but it’s not elegant. I would just move the entire install up a folder to / and then inside of the old forums issue an auto redirect to the root folder with the same path. If you need help with a sample redirect I can post something when I get home.

You can manually exclude it. It won’t hurt. If you restore, you may have to rebuild your system cache and you’re back in business. Instead of worrying about what is included/excluded, I just gzip the entire user home folder. My SQL backups throws those SQL dumps in a folder just above the document root so they’re in the same tar ball.

If you use S3 for uploads and attachments, those files are not on your server. So your backup scripts won’t ever back them up. But what happens if those files ever get deleted by accident? Even though S3 is 99.999 available it does not prevent issues with deleted files etc. You need to separately arrange for backups of data inside of S3.

The data store folder has session info and such in it. You can technically exclude it, but unless you’re short on space I generally would not. You’ll need to do some manual repair work afterwards in the ACP but it should all be doable without it. You don’t need to do continuous backups or syncs. Just a straight old zip of the document root on a nightly basis is enough. Don’t forget about your database backup. If you don’t have something that automatically backs up database instances, you might want to setup a script to dump the database nightly and have your backup script grab it also. My personal backup policy is to store daily backups for a week, weekly for a month (Sunday’s backup becomes the weekly) and monthly for a year.

I don't believe so. However if this is a VM, is it possible to allocate it more resources? The task processor limits what it can do based on available resources. So upping the resources should help it get more done faster. Once done, drop it back to the normal reservation.

OK. Then use that as your cron user. From root, run: crontab -u www-data -e It will launch a text editor. In the editor, you can add: */3 * * * * followed by the exact text IPS provides you in the admin CP for the path to the cron job. For me it was: */3 * * * * /usr/local/php74/bin/php -d memory_limit=-1 -d max_execution_time=0 /PATH/TO/MY/IPB/applications/core/interface/task/task.php MYMD5HASHKEY >/dev/null 2>&1 Save the changes and you should be set. It should give you a message that the new cron was installed. IPS by default recommends running the cron every minute. I found it choked things a bit when the server had higher loads, so I run it every 3 minutes. You can adjust the frequency as you want.

In general, run cron scripts as whatever user you would generally access the site via FTP with. In most cases, that user will already have permission to the files associated with your website and already operate in a more limited basis than say a super user account. If you don't use user accounts, run it as the same user that Apache is running under. I believe the default account would then just be "apache".

Also... is it possible to provide an SSH key file in place of a password for support staff to use?

Is it possible to get a list of IP addresses used by IPS? I would like to create an ACL for SSH/SFTP/FTP access. This would include whatever IPs are used by support along with the IP addresses I need to allow for the IPS Auto Updater to work. Thanks!

The spirit is willing but the flesh is weak! 🤣

The footer on the private message notifications is as follows, even for this site. Click here to view our privacy policy Invision Community, 901 Jefferson St STE 207, Lynchburg, Virginia, 24504 There is not a link to change subscription settings on the private message template. In the emails that trigger from Commerce, it does have a link. Prefer to stop receiving these emails? Manage Notification Settings. Click here to view our privacy policy >>PHYSICAL ADDRESS HERE<<

I think I managed to answer this myself. I ended up cloning my prod instance into a dev instance and testing there to make sure I did not break my live site. The files look to be indeed orphaned. I took the filenames from the monthly* folder and checked against the Files list in the ACP and none of them matched. And because I'm using Redis as my cache, the css_built and set resources folder were not needed. I was able to remove everything except for the logs folder without negative impact. Again, this only worked because my file storage type for emoticons, reactions, and everything else was set to S3 and that I was using Redis to cache templated files. (I added this disclaimer in case someone else sees this later and think it just safe to randomly delete files in the folder.)

That means you have not even STARTED the search index rebuild yet. It's rebuilding the posts themselves. (It's rewriting old BB code into new format, etc.)

https://blog.cpanel.com/how-to-configure-a-cron-job/ You would write a script to do whatever action you want, and then tell the cron to run it on whatever schedule/frequency you want.

Rebuilding the search index on my site took about 12 hours with the default database search. It was much faster (just under 2 hours) with Elasticsearch. The amount of time it takes depends on the available system resources and how busy your site is. Remember... this is a pretty database intense process and it's competing with your normal site users for resources. IPB tries to limit what it does at one time so as not to completely overwhelm your server and have your site down while it's being worked on.

Hi guys, I've recently moved all of the storage settings from using local files to an AWS S3 bucket. The migration completed without issue and everything is working as expected. (I did have to clear the system cache to fix some skin issues, but that was easy enough.) After the migration, I was looking in my uploads folder and still see a bunch of content that I thought would have migrated. [root@hooboy uploads]# du -h --max-depth=1 1.3M ./monthly_2021_06 1.8M ./set_resources_0 36K ./monthly_2021_07 208K ./monthly_2021_11 48K ./logs 56K ./monthly_2021_08 0 ./emoticons 0 ./monthly_2022_01 192K ./monthly_2021_09 4.0K ./reactions 40K ./monthly_2021_10 672K ./css_built_0 16K ./monthly_2021_12 200K ./monthly_2021_05 Would it be safe to assume the content in the monthly* folders are orphaned and can be removed? It looks like the css_built* and set_resources* are still stored locally even after moving to the S3 bucket?

Just as a side datapoint, I don’t have the biggest community, but our SQL database is 12GB. That does not include the search index as we utilize elasticsearch. The database size itself does not matter much. IPB is written in an efficient manner to handle big amounts of data with well engineered indexes and queries to reduce the amount of overhead associated with finding data. Slowness tends to come from other things such as high CPU load from a high number of concurrent users, an unoptimized MySQL configuration that does not properly get to utilize enough RAM, etc. Ive been able to squeeze absorber 30-40% from my prior setup by focusing on server optimization. (Though your specific results might obviously vary.)

If you think you missed a manual query it should be safe to run them all again. They should come back with 0 rows effected or just match what is already there.

To fix your license key, login to the IPB Client Area and choose Manage Purchases. Find your instance and there should be a section there to change your address. Also… here’s a dumb idea. It’s possible your browser cache is still calling some old URLs. Have you also flushed your browser’s cache?

If you’re typing in the admin CP address and it’s forwarding you to the old address one of two situations is happening: - Your conf_global.php was not updated correctly. (You need to update both the server path AND the domain address in the file) - You have a server/network level redirect in place. Your hosting provider would have to change that if it’s used.