add database prune sql script

backup.md

@@ -0,0 +1,30 @@
+This is the script I use for routine backups of a pleroma server where I don't have access to the hypervisor.  We need a few things:
+- The pgsql database dumped to a file
+- The contents of /opt/pleroma, mostly the uploads directory
+- And it doesn't hurt to grab all of /etc to make sure we've got the latest nginx config and anything else that could make restoring to a new server easier.
+
+```
+#!/bin/bash
+cd /opt/pleroma
+echo Backup started at $(date)
+sudo -Hu postgres pg_dump -d pleroma --format=custom -f /var/tmp/pleroma.pgsql
+rsync -e "ssh -i $HOME/.ssh/backup_rsa -p 22" -avzh /opt/pleroma /etc /var/tmp/pleroma.pgsql  pleroma-backup@server.example.com:/data
+rm -f /var/tmp/pleroma.pgsql
+```
+
+For restoring the database and files, the easiest way I've found to do so is installing a fresh copy of pleroma of the same or later version and then restoring the backed up copy over top of it.
+
+```
+sudo -Hu pleroma git clone -b develop https://git.pleroma.social/pleroma/pleroma /opt/pleroma
+sudo -Hu pleroma mix deps.get
+sudo -Hu pleroma MIX_ENV=prod mix pleroma.instance gen
+sudo -Hu postgres psql -c 'DROP DATABASE pleroma;';
+sudo -Hu postgres psql -c 'DROP USER pleroma;'
+sudo -Hu postgres psql -f config/setup_db.psql
+sudo -Hu postgres pg_restore -d pleroma -v /opt/pleroma/backup.pgsql -j 5
+sudo -Hu pleroma MIX_ENV=prod mix ecto.migrate
+sudo -Hu postgres vacuumdb --all --analyze-in-stages
+sudo -Hu pleroma MIX_ENV=prod mix pleroma.frontend install pleroma-fe
+systemctl start pleroma
+```
+After that, the uploads directory, custom emoji, and theme will need to go back in place, but it should be 99% working.

database_prune.sql

@@ -0,0 +1,39 @@
+\c pleroma
+do $$
+declare
+maxA integer := (SELECT count(*) from activities WHERE inserted_at < now() - interval '4 months');
+maxO integer := (SELECT count(*) from objects WHERE inserted_at < now() - interval '4 months');
+maxN integer := (SELECT count(*) from notifications WHERE inserted_at < now() - interval '4 months');
+counter integer := 0;
+begin
+RAISE NOTICE 'Marked for deletion: % activities', maxA;
+while counter < maxA loop
+DELETE FROM activities WHERE id = any (array(SELECT id FROM activities WHERE inserted_at < now() - interval '4 months' LIMIT 1000));
+COMMIT;
+PERFORM pg_sleep(3);
+counter := counter + 1000;
+end loop;
+RAISE NOTICE 'Marked for deletion: % objects', maxO;
+counter := 0;
+while counter < maxO loop
+DELETE FROM deliveries WHERE object_id = any (array(SELECT id FROM objects WHERE inserted_at < now() - interval '4 months' LIMIT 10000));
+COMMIT;
+PERFORM pg_sleep(3);
+counter := counter + 1000;
+end loop;
+counter := 0;
+while counter < maxO loop
+DELETE FROM objects WHERE id = any (array(SELECT id FROM objects WHERE inserted_at < now() - interval '4 months' LIMIT 1000));
+COMMIT;
+PERFORM pg_sleep(3);
+counter := counter + 1000;
+end loop;
+RAISE NOTICE 'Marked for deletion: % notifications', maxN;
+counter := 0;
+while counter < maxO loop
+DELETE FROM notifications WHERE id = any (array(SELECT id FROM notifications WHERE inserted_at < now() - interval '4 months' LIMIT 1000));
+COMMIT;
+PERFORM pg_sleep(3);
+counter := counter + 1000;
+end loop;
+end$$;

deletes.md

@@ -1,4 +1,4 @@
-Deletes are the danger zone, deleting activities from the table can and will introduce weird problems.  For example, when a new activity federates in referencing a deleted activity, it'll cause notifications to temporarily break for the affected user(s).  Pleroma will look in the table for the activity it's referencing, that'll time out, and the request to load notifications into pleroma-fe will 502 and they'll just be blank.
+Deletes are the danger zone, deleting activities from the table can and will introduce weird problems.  For example, when a new activity federates in referencing a deleted activity, it'll cause notifications to temporarily break for the affected user(s).  Pleroma will look in the table for the activity it's referencing, that'll fail, and users will see one or more 500 errors on screen.
 
 But if it's a choice between killing the instance entirely due to storage constraints or deleting activities and accepting the risk of errors, we can delete them.  Before you delete anything, take a look at how to clean up pg_repack remnants [here](https://git.yandere.love/skylar/pleromer-stuff/src/branch/main/repack.md).
 
@@ -52,3 +52,11 @@ counter := counter + 1;
 end loop;
 end$$;
 ```
+
+To prune the database on a recurring basis, adjust this [SQL file](https://git.yandere.love/skylar/pleromer-stuff/src/branch/main/database_prune.sql) to your desired retention period for activities, objects, and notifications, then execute it with:
+
+```
+sudo -Hu postgres psql -f /path/to/database_prune.sql
+```
+
+If you've named your database something other than "pleroma", that will need to be changed as well.