File: debianize_backup_docs.diff

package info (click to toggle)
request-tracker5 5.0.7%2Bdfsg-4
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 80,216 kB
  • sloc: javascript: 191,898; perl: 87,146; sh: 1,412; makefile: 487; python: 37; php: 15
file content (135 lines) | stat: -rw-r--r-- 5,235 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
From 3906c80b98c9202e66e70c1f1f41c80f32bb45fb Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves <dom@earth.li>
Date: Wed, 27 Mar 2013 23:36:30 +0000
Subject: Customise backup docs for Debian

Forwarded: not-needed
Patch-Name: debianize_backup_docs.diff
---
 docs/system_administration/database.pod | 60 +++++++++++++++++--------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/docs/system_administration/database.pod b/docs/system_administration/database.pod
index 2e3f64fb..2de7666e 100644
--- a/docs/system_administration/database.pod
+++ b/docs/system_administration/database.pod
@@ -24,7 +24,14 @@ Test your backups regularly to discover any unknown problems B<before> they
 become an issue.  You don't want to discover problems with your backups while
 tensely restoring from them in a critical data loss situation.
 
-=head2 Database
+This documentation has been modified by the Debian maintainers to be more
+specific to file locations in Debian. It removes the upstream recommendation
+to back up the distributed code, as this should be reinstalled via the
+Debian packaging system. However, this means it is important not to
+modify files in /usr/share directly (a good general rule) as those changes
+will be lost in the event of having to restore.
+
+=head2 DATABASE
 
 You should backup the entire RT database, although for improved speed and space
 you can ignore the I<data> in the C<sessions> table.  Make sure you still get
@@ -162,7 +169,13 @@ can run C<analyze verbose>.
 
 =back
 
-=head2 Filesystem
+=head2 PACKAGE LISTS
+
+This will help you decide which packages to reinstall.
+
+    dpkg --get-selections > rt-get-selections-`date +%Y%M%d`
+
+=head2 FILESYSTEM
 
 Although this section is mostly about database backups, there are other
 files on the filesystem you should back up to capture the state of your RT.
@@ -170,19 +183,27 @@ You will want to back up, at the very least, the following directories and files
 
 =over 4
 
-=item /opt/rt5
+=item /var/lib/request-tracker5
+
+Miscellaneous data, including GPG data, if it exists.
 
-RT's source code, configuration, GPG data, and plugins.  Your install location
-may be different, of course.
+You can omit F</var/lib/request-tracker5/mason_data> and
+F</var/lib/request-tracker5/session_data> if you'd like since
+those are temporary caches.  Don't omit all of F</var/lib/request-tracker5/>
+however as it may contain important GPG data.
 
-You can omit F<var/mason_data> and F<var/session_data> if you'd like since
-those are temporary caches.  Don't omit all of F<var/> however as it may
-contain important GPG data.
+=item /etc/request-tracker5
+
+RT configuration files.
+
+=item /usr/local/share/request-tracker5
+
+Local code customisations and plugins.
 
 =item Webserver configuration
 
-Often F</etc/httpd> or F</etc/apache2>.  This will depend on your OS, web
-server, and internal configuration standards.
+If you're using Apache, as per the Debian default, this is in
+F</etc/apache2>.
 
 =item /etc/aliases
 
@@ -200,9 +221,12 @@ The location of these files is highly dependent on what software you're using.
 
 =item Crontab containing RT's cronjobs
 
-This may be F</etc/crontab>, F</etc/cron.d/rt>, a user-specific crontab file
-(C<crontab -l $USER>), or some other file altogether.  Even if you only have
-the default cronjobs in place, it's one less piece to forget during a restore.
+As installed by Debian, this is F</etc/cron.d/request-tracker5> but
+you may have used additional files.
+
+Even if you only have the default cronjobs in place, it's one less piece
+to forget during a restore.
+
 If you have custom L<< C<rt-crontool> >> invocations, you don't want to have to
 recreate those.
 
@@ -223,7 +247,7 @@ regarding backups.
 
 Simply saving a tarball should be sufficient, with something like:
 
-    tar czvpf rt-backup-`date +%Y%m%d`.tar.gz /opt/rt5 /etc/aliases /etc/httpd ...
+    tar czvpf rt-backup-`date +%Y%M%d`.tar.gz /var/lib/request-tracker5 /etc/aliases /etc/httpd ...
 
 Be sure to include all the directories and files you enumerated above!
 
@@ -262,8 +286,8 @@ The documentation contains additional information on available flags.
 It's also a good idea to run the L<rt-validator> tool to detect and resolve
 any errors in your database before starting:
 
-    /opt/rt5/sbin/rt-validator --check (and maybe --resolve)
-    /opt/rt5/sbin/rt-serializer --clone --directory /path/to/serialized/data
+    rt-validator-5 --check (and maybe --resolve)
+    rt-serializer-5 --clone --directory /path/to/serialized/data
 
 =item Setup New Database
 
@@ -278,14 +302,14 @@ If you are running the import in the same RT installation, you will need to
 update your database options in C<RT_SiteConfig.pm> to point to the new database
 before running this step.
 
-    /opt/rt5/sbin/rt-setup-database --action create,schema,acl
+    rt-setup-database-5 --action create,schema,acl
 
 =item Import Data
 
 Once you have your new database set up, you can then use L<rt-importer>
 to insert the serialized data:
 
-    /opt/rt5/sbin/rt-importer /path/to/serialized/data
+    rt-importer-5 /path/to/serialized/data
 
 As with the serializer step, this will take time proportionate to the size of
 your database.